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,
--
gmt
"If ye love wealth better than liberty, the tranquility
of servitude better than the animating contest of freedom,
go home from us in peace. We ask not your counsels or your
arms. Crouch down and lick the hands, which feed you. May
your chains set lightly upon you, and may posterity forget
that ye were our countrymen."
-Samuel Adams
On Tuesday 01 October 2002 09:35 pm, Greg Turner wrote:
> 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:
[snip]
> 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
[snip]
> .
> .
> .
> 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.
