Диагностика при ошибках.

← →
Pavelkq (2004-07-13 09:10) [0]

Здравствуйте. Имею цикл из огромных чисел. Иногда программы вылетает по переполнению стека. Как при остановке программы по ошибке посмотреть состояние переменных, наподобие преднамеренной остановки программы по метке или паузе (наведение курсора на переменную дает ее значение)?

← →
Anatoly Podgoretsky © (2004-07-13 09:26) [1]

Цикл на стек не влияет

← →
Алхимик © (2004-07-13 09:30) [2]

Поищи статейку "Силовая отладка" или что то в этом духе.

← →
Pavelkq (2004-07-13 09:38) [3]

Вот отрывок кода
for i1:=0 to i2-1 do begin ProgressBar.Position:=i1; s:=A[i1]; count:=FindWID(PChar(s),@Uid); if count>0 then begin rc:=GetBid(uid.ids[0].lnk,uid.ids[0].en,false,false,@WData); if rc>=0 then begin strcopy(cstr,CTS(WData.inlex[0].cid)); strcopy(vstr,VTS(WData.inlex[0].cid,WData.inlex[0].vid)); s1:=StrPas(WData.inlex[0].anword); end; end else A[i1]:=""; end;
i2 в данном случае = 226966. Интересно, что ПрограссБар нормально отображает ход выполнения примерно на 1/5 всего процесса, а потом переполнение стека.
Так же интересно, что при малых i2 все работает стабильно.

← →
Digitman © (2004-07-13 09:39) [4]

> цикл из огромных чисел

это как - "из огромных чисел" ? в смысле огромное количество итераций цикла ?

> Иногда программы вылетает по переполнению стека

ищи рекурсию

← →
Алхимик © (2004-07-13 09:44) [5]

if i1 = <число итераций без AV> then begin ShowMessage("А теперь трассируем и смотрим значения переменных"); end;

← →
Pavelkq (2004-07-13 10:11) [6]

Не, ну, огромные я имел в виду именно 226966 итераций. В принципе, программе-то все равно сколько их там.
Рекурсию искал, не могу найти.
А что значит <число итераций без AV>? Я как раз и хотел бы узнать на каком значение i1 происходит сбой, чтобы дальше проанализировать содержимое массива А.

← →
Digitman © (2004-07-13 10:25) [7]

try
for i1:=0 to i2-1 do
begin
...
end;
except
on e:exception do
showmessage(e.classname + " " + e.message + " " + "i1 = " + inttostr(i1))
end;

← →
Pavelkq (2004-07-13 10:29) [8]

Я тоже около этого вертелся, но до on e:exception do не дошел:-) Сейчас проверю...

← →
Семен Сорокин © (2004-07-13 10:34) [9]

> Pavelkq (13.07.04 09:38) [3]
> i2 в данном случае = 226966. Интересно, что ПрограссБар
> нормально отображает ход выполнения примерно на 1/5 всего
> процесса, а потом переполнение стека.

Вы про операции div и mod что-нибудь слышали?
А Если цикл действительно большой - то его надо выностить в доп. поток (TThread).

← →
han_malign © (2004-07-13 10:38) [10]

логи надо писать...

З.Ы. Нигде stdcall или cdecl не пропустил? А то по параметрам функции очень на си-шные похожи, и наверняка из DLL...

← →
han_malign © (2004-07-13 10:47) [11]

и судя по всему как раз cdecl, насколько я помню именно там стек по завершении функции вычищается.

← →
Pavelkq (2004-07-13 15:56) [12]

Да, именно из Си-шного DLL-а. Вас, ребята, не проведешь:-) Нет, не пропустил, но только stdcall. Думаете, dll не корректно работает, не вычищая за собой мусор? Мне тоже так кажется. Это не мой dll, как он устроен я не в курсе. Но с разработчиком связь имеется. Могу уточнить если что.
[7] - не проканала:-( Все одно оборвалось все на ошибке переполнения стека.

> не проканала

и не должно было "проканать" .. просто были некие сомнения насчет именно SO-исключения... теперь стало все понятно ...

> из Си-шного DLL

момент здесь сложный .. без разработчика (за неимением навыков дизассемблирования и анализа асм-текста) лучше не дергаться ...

при cdecl ответственность за баланс с стека берет на себя вызываЮЩАЯ п/программа (сразу после CALL она корректирует значение указателя вершины стека в ESP на суммарный размер переданных через стек при вызове параметров)

при stdcall ответственность за баланс с стека берет на себя вызываЕМАЯ п/программа (вызовом RET N она корректирует значение указателя вершины стека в ESP на суммарный размер N переданных через стек при вызове параметров)

неверно указанное соглашение о вызове вполне может привести к такой вот плачевной ситуации, когда - итерация за итерацией - стек не балансируется

>но только stdcall
- учитывая, что стек переполняется, а если не переполняется - то и не разрушается(восстанавливаясь, по выходу из вызывающей функции, из EBP(С-шная функция тоже должна восстанавливать все регистры кроме EAX,EDX,ECX)) - то должно быть как раз cdecl

>момент здесь сложный .. без разработчика... лучше не дергаться ...
- а что тут дергаться - метод последовательных итераций(научного тыка) - еще никогда не подводил... :))

← →
Pavelkq (2004-07-14 13:21) [15]

Ребята, вы гении! Заменил во всех функциях stcall на cdecl и все зашуршало, как по маслу. Кстати, метод научного тыка, тоже пригодился при анализе:-)

> i2 в данном случае = 226966. Интересно, что ПрограссБар
> нормально отображает ход выполнения примерно на 1/5 всего
> процесса

Интересно, а в какой момент происходит отрисовка?

>Интересно, а в какой момент происходит отрисовка?
procedure TProgressBar.SetPosition(Value: Integer); begin if not F32BitMode and ((Value < 0) or (Value > Limit16)) then ProgressLimitError; if HandleAllocated then SendMessage(Handle, PBM_SETPOS, Value, 0) else FPosition := Value; end;
- так что, если в отдельном потоке - все путем...

Диагностика при ошибках. Найти похожие ветки