I'm trying to run StarTeam Client, which used to work as recently as earlier this month. Nowadays, I get infinite recursion in the exception handlers, caused by various NULL pointer deferences within dlls/msvcrt/cppexcept.c. Any ideas? Looks like stack corruption to me... Here's some +seh output:
trace:seh:EXC_RtlRaiseException code=e06d7363 flags=1 addr=0x401060f4 trace:seh:EXC_RtlRaiseException info[0]=19930520 trace:seh:EXC_RtlRaiseException info[1]=406f17f0 trace:seh:EXC_RtlRaiseException info[2]=41108f80 trace:seh:EXC_CallHandler calling handler at 0x411075e6 code=e06d7363 flags=1 trace:seh:EXC_CallHandler handler returned 1 trace:seh:EXC_CallHandler calling handler at 0x411074b4 code=e06d7363 flags=1 trace:seh:cxx_frame_handler handling C++ exception rec 0x406f1750 frame 0x406f186c trylevel 0 descr 0x41108c20 exception type: flags 0 destr (nil) handler (nil) type info 0x41108f68 0: flags 1 type 0x4110d400 ((nil) .PAVCStCommandExceptionDetected@@) offset 0 vbase -1,0 size 4 copy ctor (nil) 1: flags 1 type 0x4110d3e0 ((nil) .PAVCException@@) offset 0 vbase -1,0 size 4 copy ctor (nil) 2: flags 1 type 0x4110d440 ((nil) .PAVCObject@@) offset 0 vbase -1,0 size 4 copy ctor (nil) 3: flags 1 type 0x4110d430 ((nil) .PAX) offset 0 vbase -1,0 size 4 copy ctor (nil) function descr: magic 19930520 unwind table: 0x41108c40 4 0: prev -1 func (nil) 1: prev -1 func (nil) 2: prev 1 func (nil) 3: prev 1 func (nil) try table: 0x41108c60 2 0: start 2 end 2 catchlevel 3 catch 0x41108c88 1 0: flags 0 offset -28 handler 0x410fbb63 type 0x4110d3e0 ((nil) .PAVCException@@) 1: start 0 end 0 catchlevel 3 catch 0x41108c98 2 0: flags 0 offset -24 handler 0x410fbb36 type 0x4110d400 ((nil) .PAVCStCommandExceptionDetected@@) 1: flags 0 offset 0 handler 0x410fbb52 type (nil) trace:seh:call_catch_block matched type 0x41108f48 in tryblock 1 catchblock 0 trace:seh:EXC_RtlUnwind code=e06d7363 flags=3 trace:seh:EXC_CallHandler calling handler at 0x4010c310 code=e06d7363 flags=3 trace:seh:EXC_CallHandler handler returned 1 trace:seh:EXC_CallHandler calling handler at 0x411075e6 code=e06d7363 flags=3 trace:seh:EXC_CallHandler handler returned 1 trace:seh:call_catch_block calling catch block 0x41108c98 for type 0x41108f48 addr 0x410fbb36 ebp 0x406f1878 trace:seh:EXC_RtlRaiseException code=e06d7363 flags=1 addr=0x401060f4 trace:seh:EXC_RtlRaiseException info[0]=19930520 trace:seh:EXC_RtlRaiseException info[1]=406f0e6c trace:seh:EXC_RtlRaiseException info[2]=41108df8 trace:seh:EXC_CallHandler calling handler at 0x411074e6 code=e06d7363 flags=1 trace:seh:EXC_CallHandler handler returned 1 trace:seh:EXC_CallHandler calling handler at 0x411074b4 code=e06d7363 flags=1 trace:seh:cxx_frame_handler handling C++ exception rec 0x406f0dd4 frame 0x406f186c trylevel 1 descr 0x41108c20 exception type: flags 0 destr (nil) handler (nil) type info 0x41108de0 0: flags 1 type 0x4110d478 ((nil) .PAVCStBaseServerException@@) offset 0 vbase -1,0 size 4 copy ctor (nil) 1: flags 1 type 0x4110d458 ((nil) .PAVCStException@@) offset 0 vbase -1,0 size 4 copy ctor (nil) 2: flags 1 type 0x4110d3e0 ((nil) .PAVCException@@) offset 0 vbase -1,0 size 4 copy ctor (nil) 3: flags 1 type 0x4110d440 ((nil) .PAVCObject@@) offset 0 vbase -1,0 size 4 copy ctor (nil) 4: flags 1 type 0x4110d430 ((nil) .PAX) offset 0 vbase -1,0 size 4 copy ctor (nil) function descr: magic 19930520 unwind table: 0x41108c40 4 0: prev -1 func (nil) 1: prev -1 func (nil) 2: prev 1 func (nil) 3: prev 1 func (nil) try table: 0x41108c60 2 0: start 2 end 2 catchlevel 3 catch 0x41108c88 1 0: flags 0 offset -28 handler 0x410fbb63 type 0x4110d3e0 ((nil) .PAVCException@@) 1: start 0 end 0 catchlevel 3 catch 0x41108c98 2 0: flags 0 offset -24 handler 0x410fbb36 type 0x4110d400 ((nil) .PAVCStCommandExceptionDetected@@) 1: flags 0 offset 0 handler 0x410fbb52 type (nil) trace:seh:EXC_CallHandler handler returned 1 trace:seh:EXC_CallHandler calling handler at 0x410ceadd code=e06d7363 flags=1 trace:seh:cxx_frame_handler handling C++ exception rec 0x406f0dd4 frame 0x406f19ac trylevel 1 descr 0x410d43f8 exception type: flags 0 destr (nil) handler (nil) type info 0x41108de0 0: flags 1 type 0x4110d478 ((nil) .PAVCStBaseServerException@@) offset 0 vbase -1,0 size 4 copy ctor (nil) 1: flags 1 type 0x4110d458 ((nil) .PAVCStException@@) offset 0 vbase -1,0 size 4 copy ctor (nil) 2: flags 1 type 0x4110d3e0 ((nil) .PAVCException@@) offset 0 vbase -1,0 size 4 copy ctor (nil) 3: flags 1 type 0x4110d440 ((nil) .PAVCObject@@) offset 0 vbase -1,0 size 4 copy ctor (nil) 4: flags 1 type 0x4110d430 ((nil) .PAX) offset 0 vbase -1,0 size 4 copy ctor (nil) function descr: magic 19930520 unwind table: 0x410d4418 7 0: prev -1 func (nil) 1: prev 0 func (nil) 2: prev 1 func 0x410ceabd 3: prev 2 func 0x410ceac6 4: prev 3 func 0x410ceacf 5: prev 0 func (nil) 6: prev -1 func (nil) try table: 0x410d4450 2 0: start 1 end 4 catchlevel 5 catch 0x410d4478 2 0: flags 0 offset -80 handler 0x410abe43 type 0x410de070 ((nil) .PAVCException@@) 1: flags 0 offset 0 handler 0x410abe6d type (nil) 1: start 0 end 5 catchlevel 6 catch 0x410d4498 2 0: flags 0 offset -84 handler 0x410abe9c type 0x410de070 ((nil) .PAVCException@@) 1: flags 0 offset 0 handler 0x410abeb9 type (nil) trace:seh:call_catch_block matched type 0x41108d80 in tryblock 0 catchblock 0 trace:seh:EXC_RtlUnwind code=e06d7363 flags=3 trace:seh:EXC_CallHandler calling handler at 0x4010c310 code=e06d7363 flags=3 trace:seh:EXC_CallHandler handler returned 1 trace:seh:EXC_CallHandler calling handler at 0x411074e6 code=e06d7363 flags=3 trace:seh:EXC_CallHandler handler returned 1 trace:seh:EXC_CallHandler calling handler at 0x411074b4 code=e06d7363 flags=3 trace:seh:EXC_CallHandler handler returned 1 trace:seh:call_catch_block calling catch block 0x410d4478 for type 0x41108d80 addr 0x410abe43 ebp 0x406f19b8 trace:seh:EXC_RtlRaiseException code=e06d7363 flags=1 addr=0x401060f4 trace:seh:EXC_RtlRaiseException info[0]=19930520 trace:seh:EXC_RtlRaiseException info[1]=00000000 trace:seh:EXC_RtlRaiseException info[2]=00000000 trace:seh:EXC_CallHandler calling handler at 0x410ceadd code=e06d7363 flags=1 trace:seh:EXC_RtlRaiseException code=c0000005 flags=0 addr=0x40f3e9a3 trace:seh:EXC_RtlRaiseException info[0]=00000000 trace:seh:EXC_RtlRaiseException info[1]=00000008 trace:seh:EXC_CallHandler calling handler at 0x4010c310 code=c0000005 flags=0 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x410ceadd code=c0000005 flags=10 trace:seh:cxx_frame_handler handling C++ exception rec 0x405e09d8 frame 0x406f19ac trylevel 5 descr 0x410d43f8 exception type: trace:seh:EXC_RtlRaiseException code=c0000005 flags=0 addr=0x40f3e1f5 trace:seh:EXC_RtlRaiseException info[0]=00000000 trace:seh:EXC_RtlRaiseException info[1]=0000000c trace:seh:EXC_CallHandler calling handler at 0x4010c310 code=c0000005 flags=0 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4010c310 code=c0000005 flags=10 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x410ceadd code=c0000005 flags=10 trace:seh:cxx_frame_handler handling C++ exception rec 0x405dfe98 frame 0x406f19ac trylevel 5 descr 0x410d43f8 exception type: trace:seh:EXC_RtlRaiseException code=c0000005 flags=0 addr=0x40f3e1f5 trace:seh:EXC_RtlRaiseException info[0]=00000000 trace:seh:EXC_RtlRaiseException info[1]=0000000c trace:seh:EXC_CallHandler calling handler at 0x4010c310 code=c0000005 flags=0 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4010c310 code=c0000005 flags=10 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4010c310 code=c0000005 flags=10 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x410ceadd code=c0000005 flags=10 . . . and so on, forever.
The experience in a debugger is that the exception type becomes NULL and is passed around like that until it gets deferenced. Then all hell breaks loose. I don't understand where __wine_call_from_32_regs lives in the source, and lose track of what's going on in there, thwarting my debugging efforts.
The only "obvious" explanation I can imagine for this is that something broke during the recent changes involving ntddk.h/winternal.h. Early this month it was working like a charm.
BTW, I think this is a case where an exception is raised within an exception handler, but... that doesn't seem too exotic anyhow... The latest %ebp patch doesn't seem to affect the problem.
Anyone got any advice at all for me? All this assembly code is really making my eyes bleed. Any ideas how I could at least build an example program or produce a more meaningful trace?
It's almost definitely a wine bug. "args[2]" becomes nil, get's deferenced, and once the SIGSEGV handler starts running, it never gets back to any native dll's -- that is to say, the infinite recursion happens entirely within the wine codebase... SIGSEGV invokes wine handlers which then cause /another/ SIGSEGV, and so on.... shouldn't be possible, right?
Is the exception handling WIP right now? Should I just be patient and worry about more simple things and expect that this will get fixed eventually?
Surely, if I start drawing pictures of ram, stack, reg's, etc., and basically get /real/ anal about this, I could find the bug, but I'm pretty rusty on my asm to begin with, and it would basically be a big pain in the ass. So... here I am, being lazy, hoping somebody has a clue so I don't have to...
bummed,
I think it can be possible.
One month ago I notice that winedbg has problems when reading the process memory it tries to acess. Let me show the problem I encounter : - the windows program launched causes some error; - winedbg launches; - it tries to read a memory that is out of bounds; - a 2nd winedbg launches, trying to debug the first; - same error occurs (out of bound read); - a 3d winedbg launches, being successfull to read the memory of the 2nd.
Conclusion: Only wine code is used. (I defined all dll's built-in, and only advapi32 is loaded when using winedbg)
It's almost definitely a wine bug. "args[2]" becomes nil, get's deferenced, and once the SIGSEGV handler starts running, it never gets back to any native dll's -- that is to say, the infinite recursion happens
entirely within the wine codebase... SIGSEGV invokes wine handlers which then cause /another/ SIGSEGV, and so on.... shouldn't be possible, right?
___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
On Thursday 03 October 2002 09:27 am, Sylvain Petreolle wrote:
I think it can be possible.
yes, well, this much is for sure: it /is/ possible ;)
-
Greg Turner -
Sylvain Petreolle