"DebugLog и память" или "юзаем аккуратно".
На создание этой заметки меня сподвиг факт существования культа авторитета и культа мнения большинства. Или как называл эти тормозящие процесс познания явления Френсис Бэкон: призраки рынка и призраки театра. Но не будем вдаваться в подробности поиска метода познания в период Нового Времени и вернёмся к b3d. Помнится многие рьяно уверяли меня в том, что b3d адекватно отображает кирилический текст произвольной длины командой Text... Пока Morpher и Tormoz не подтвердили этот обидный недостаток... Часто проблема обнаружения уязвимости заключается в сложности провоцирования ошибки. На этот раз сбой при выполнении команды Debuglog. К сожалению чётко сформулировать условия сбоя пока не удалось, но происходит он при многократном вызове функций ( в т.ч. рекурсивно) и юзании конструкций типа: Код:
Function a(x) Собственно, сам пример: В примере набо функций и тип для выичсления определителя кв.матрицы произвольного ограниченного размера. Конкретно считается вот такой определитель: Нетрудно заметить пропорциональность строк, на основании чего сделать вывод - матрица имеет нулевой детерминант. Вот b3d реализация: Код:
Graphics 800,600 Запустите его в ___ОТЛАДОЧНОМ____ режиме. И понаблюдайте - сколько раз из 25 b3d докажет что 0<>0. Теперь отключите отладку и сравните результаты. =) Положив 2 часа на отладку полностью рабочего кода ( постоянно добавляя отладочные команды - чем ещё более усугублял совё положение) я перепробовал различные версии b3d - все подвержены данной ошибке, которая, судя по всему, заключается в затирании уже используемых пространств памяти. |
гы... когда я услышал по скайпу ответ b3d этой матрицы (за минуту до этого проверил формулы написанные Импером) я почти упал со стула!
будьте осторожны! |
Цитата:
К сожалению, это не баг, а всего лишь неграмотное применение отладчика в примере, который привел Impersonalis. Отлачик в функции TMatrix_Determinant рекурсивно вызывает эту же функцию, что, естественно, неизбежно вызывает исчерпание стека (хорошо еще, что встроенные отладчики имеют свою стековую машину, а то бы вообще все рунуло). Правильно делать так: Код:
Function TMatrix_Determinant#(M.TMatrix) В нормальном режиме и дебаггера достаточно ресурсов для своей работы. Собственно, DebugLog предназначен для формирования строки вывода и имеет буфер строки более 16 Кбайт, это легко проверить с помощью Код:
a$="" В Help-файле написано, что аргументом DebugLog может быть текстовая переменная, строка, числовое значение. К сожалению, структура справки в целом нечеткая, поэтому трудно судить, запрещалось ли изначально в ней вычисление выражения. Но я пытался без рекурсии свалить стек, но при корректных вычислениях у меня не получилось. Но в любом случае, для вычисления выражений в приведенном Impersonalisom примере ограничивается стековое пространство при рекурсии. Но есть программы, которые ведут себя странно со включенным Debug , причем DebugLog вообще там не используется, например партикловая система Lotus. |
Ну в общем то целью заметки было предотвратить неосторожное юзание debuglog.
Ведь это сложнонаходимо. Если переполнить стек программы она либо закрешится, либо молча зкроется - а тут всё считается.. но не правильно. То что код так не пишут я знаю =) Это пример. В любом случае - спибо за автороитетное мнение и уточнение деталей. |
Цитата:
DebugLog можно и нужно использовать. :super: 2)Насчет сложнонаходимо - у меня это заняло 1 минуту с проверкой. А для того, чтобы потренироваться со стеком - надо на Форте попробовать попрограммировать - там одновременно несколько стеков используется, вот где раздолье! :bravo: 3)Во-первых тут стек не программы, а отладчика. Отладчик работает, как вариант, сохраняя кадр программы и переключая регистр BP на другую область стека. А во-вторых, так как DebugLog чисто информационный, из-за переполнения стека может быть получен только недостоверный результат, поскольку вычисление функции может прерваться в любом месте, но при этом происходит восстановление кадра программы (всех регистров, стека и флагов). То есть краха программы не будет. :P Поэтому считается все правильно, только в последней рекурсии, на которой выделенный стек загнулся, вычисление обрывается с итоговым неправильным состоянием регистров микропроцессора, которое выдаст в неправильный результат DET. :wallbash: |
P.S. Естественно, под BP подразумевается EBP или RBP.
|
Имеется в виду, что ESP юзается обычно в связки с EPB. Вообщем, это уже не Бейсик.
Что-то я размазался по трем постам.... Зарегиться, что ли, чтобы править можно было... :) |
Цитата:
давно ждём, столь опытного кодера в своих рядах ;) |
Часовой пояс GMT +4, время: 06:10. |
vBulletin® Version 3.6.5.
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Перевод: zCarot