Eric Pouech wrote:
- kernel send a trap signal
- wine's ntdll catches it, and queue the information as a debug event in the wineserver
- the debugger (msvcmon in your case) get notified of the trap while waiting for a debug event
I understand.
I made a log of what happens when I single step with the debugger:
I see the debugger waking up
001b: *wakeup* signaled=258 cookie=0x2f9ce4
then, a little further it get the exception status
001b: get_exception_status() = 0 {status=65538,context={flags=00010007,...,eflags=00210346,...}}
and then the same thread has a lot of lines in the log with the same message
001b: *signal* signal=5
until the message
001b:warn:seh:setup_exception exception outside of stack limits in thread 001b eip 002b448d esp 019b12ec stack 0x19b0000-0x1ab0000
It clearly looks like a recursive call, or an infinite loop.
Any idea of what can trigger such a behaviour ?
Another question that could be related is the status of the trace flag in EFlags (0x100). It looks like wine clears it in some of its code (raise_trap_exception and the handler for SIGTRAP in signal_i386.c). Shouldn't it be the debugger responsibilty ?
Thanks
David Hemmo
PS: I hope I am clear enough. Don't hesitate to contact me if anything is missing, or not clear.
