Access violation at address

← →
Германн © (2009-11-20 01:33) [0]

Может ли кто что-то ещё подсказать по моему топику на Королевстве:
http://www.delphikingdom.com/asp/answer.asp?IDAnswer=74207
?

Уже отправил запрос автору Эврики. Надеюсь он во-первых поймет мой английский, а во-вторых что-то ответит.

← →
0x00FF00 (2009-11-20 09:26) [1]

Насколько мне кажется, это банальные "ножницы" в стэке (сиречь, подпрограмма берёт из него не столько, сколько туда положила).
Эксепшен выпрыгивает сразу после RET.
Т.е. RET функция отработала, но управление вернулось не туда, куда нужно.

Судя по тому, что сбоящий адрес принадлежит Thread.Synchronize, могу допустить, что потоковая процедура мусорит в чужом кадре стэка. Однако на более быстрых машинах это скрадывается из-за скорости выполнения.
А здесь поток, получив в распоряжение свой квант времени, вдруг решил поизговнякать кадр — ан его прежнего уже и нету, и на его месте расположены чьи-нибудь совсем другие локальные переменные. А то и задевает адреса возврата...

← →
oxffff © (2009-11-20 09:33) [2]

> Германн © (20.11.09 01:33)

Stack frames присутствуют?

← →
oxffff © (2009-11-20 09:46) [3]

http://blog.eurekalog.com/how-to-read-bug-reports/

The next thing: you should be aware of the method used for building call stack.

There are two methods available: frame-based tracing and raw tracing methods. First one (frame-based) builds call stack by using sequence of frames, which are added to the stack on call of most routines. Usually this method gives acceptable results (if you don’t have too many very short routines). You can increase it’s effectiveness by enabling “Stack Frames” option. This method is quite precise and fast as it looks only for “registered” calls. It don’t scan the entire stack – just walks by sequence of frames, where every call frame points to another.

Raw tracing method works differently: it just scan the whole stack, trying to find return addresses. Really: the frames may be or may be not present in the stack. But return addresses are always here. The problem is that there is no 100% way to find them. So, raw method takes every integer in stack and tries to guess: does it look like return address? For this reason, the raw tracing methods can be used only with some heuristic algorithm. Created call stacks may differ significantly, depending on quality of the heuristic.

Why am I telling all this stuff? That’s because reading of a call stack may depend on the method, which was used to create the call stack.

P.S. Есть ли возможность брякнуть на LEA и посмотреть стек откуда туда попали?

← →
0x00FF00 (2009-11-20 09:57) [4]

> P.S. Есть ли возможность брякнуть на LEA и посмотреть стек
> откуда туда попали?

Имхо, всё же выполнился предыдущий RET, и Эврика встала.
Подумал так, потому что LEA не имеет касательства к указанным в крэш-дампе адресам.
Здесь это всего лишь мусорная инструкция присвоения аккумуляторного регистра себе же.
Если предыдущая (т.е. вызвавшая эксепшен) инструкция была прыжком, то неоткуда браться эксепшену.
А если бы баг был в другом потоке, то встало бы на нём, а не здесь...

сугубо имхо.

> P.S. Есть ли возможность брякнуть на LEA и посмотреть стек
> откуда туда попали?

Никакой возможности для отладки нет.

Access violation at address Найти похожие ветки