Hallo,
some application (gcprevue version 9 from http://www.graphicode.com)
crashes in a call to X:
Call gdi32.115:
BitBlt(00004438,00000000,00000000,00000090,0000012e,00000910,00000000,00000000,00cc0020)
ret=0048d1e6 fs=0247
trace:bitblt:BitBlt hdcSrc=0910 0,0 24 bpp->hdcDest=4438 0,0 144x302x24 rop=cc0020
trace:bitblt:BITBLT_InternalStretchBlt vportdst=0,0-1,1 wnddst=0,0-1,1
trace:bitblt:BITBLT_InternalStretchBlt rectdst=0,0-144,302 orgdst=0,0
trace:bitblt:BITBLT_InternalStretchBlt vportsrc=0,0-1,1 wndsrc=0,0-1,1
trace:bitblt:BITBLT_InternalStretchBlt rectsrc=2,280-144,302 orgsrc=2,280
trace:bitblt:BITBLT_InternalStretchBlt vissrc=2,280-146,582 visdst=0,0-144,302
fixme:seh:EXC_RtlRaiseException BON:Stack 0xbffff67c invalid
fixme:seh:EXC_RtlRaiseException BON:signal_stack 0x40b41000 0x40b45000
err:seh:EXC_DefaultHandling Exception frame is not in stack limits => unable to
dispatch exception.
err:win32:EnterCriticalSection Critical section 0x4025d150 wait timed out, retrying
(60 sec)
err:win32:EnterCriticalSection Critical section 0x4025d150 wait timed out, retrying (5
min)
Even after 5 min the wine debugger isn't entered.
As this call to BitBlt is the only one with a width of 0x90, I can
intercept this call and return False without further processing. This
fake makes the application usable. My guess is that the application
gets the arguments to BitBlt wrong even under WinXX, but WinXX somehow
recovers from these arguments.
So my questions:
- What is missing that the debugger can at least give a backtrace in
that situation?
- What is missing that we can use SEH with the calls with the large
stack?
Bye
Uwe Bonnes [EMAIL PROTECTED]
Free Software: If you contribute nothing, expect nothing
--
