Still problems with snoop
Uwe Bonnes
bon at elektron.ikp.physik.tu-darmstadt.de
Mon Jul 23 12:25:17 CDT 2001
>>>>> "Francois" == Francois Gouget <fgouget at free.fr> writes:
Francois> On Mon, 23 Jul 2001, Uwe Bonnes wrote:
>> Hallo,
>>
>> some days ago I reported early crashes when running with the snoop
>> debug option. E.g. vc98 msedv.exe is a good example. Running with
>> "+snoop" crashes early. Running with "-snoop=devshl" lets the program
>> succeed much further. Running without snoop gets even substancial
>> further.
>>
>> So I think there must be something wrong with snoop. I tried to look
>> hard at relay32/snoop.c, but didn't see anything fishy. So perhaps
>> somebody else has some idea what's going wrong.
Francois> Some time ago I found that we would crash in SNOOP_PrintArg
Francois> when x==-1, eventhough it's all in a try/catch. I didn't get
Francois> time to investigate in detail. You can try to see if this
Francois> patch makes things better (the traces are there for debug in
Francois> case you remove the -1 test):
Francois,
thanks for your help. However the crash happens miles away from an snoop
entry or exit in an MFC42 function, so the patch doesn't help:
080672b0:CALL mfc42.5163: ?OnWndMsg at CWnd@@MAEHIIJPAJ at Z(00000081,00000000,405f5ad4,405f5728) ret=5f447664
^^^^^^^^^^^^^^
080672b0:CALL msvcrt.67: _EH_prolog(40f9007d,00000081,00000000,405f5ad4,405f5728,00000081,40a96dc0,40
400c48,00000000,405f5748,40f90064,00000081,00000000,405f5ad4,40a96dc0,40a96dc0, ...) ret=5f4476a4
080672b0:RET msvcrt.67: _EH_prolog() retval = 40f90096 ret=5f4476a4
080672b0:CALL msvcrt.74: __CxxFrameHandler(<unknown, check return>) ret=4006bc87
080672b0:RET msvcrt.74: __CxxFrameHandler() retval = 00000001 ret=4006bc87
...
080672b0:RET msvcrt.74: __CxxFrameHandler() retval = 00000001 ret=4006bc87
080672b0:CALL msvcrt.203: _except_handler3(<unknown, check return>) ret=4006bc87
080672b0:CALL msvcrt.73: _XcptFilter(<unknown, check return>) ret=0040175d
fixme:pthread_kill_other_threads_np
WineDbg starting... on pid 8068990
No debug information in 32bit DLL '<Debugged process>' (0x00400000)
Loaded debug information from ELF 'wine' (0x00000000)
Breakpoint 1 at 0x4000da00 (_end+0x37fc1284)
Loaded debug information from ELF '/spare/bon/wine/dlls/libntdll.so' (0x40026000)
...
=>0 0x5f4475da (?AfxFindMessageEntry@@YGPBUAFX_MSGMAP_ENTRY@@PBU1 at III@Z+0x10 in C:\NT4SP5G\SYSTEM32\MFC42.DLL) (ebp=405f567c)
1 0x5f44780a (?OnWndMsg at CWnd@@MAEHIIJPAJ at Z+0x170 in C:\NT4SP5G\SYSTEM32\MFC42.DLL) (ebp=405f5704)
^^^^^^^^^^^^^
2 0x40f9007d (_end+0x2a1edd) (ebp=405f572c)
3 0x40f90064 (_end+0x2a1ec4) (ebp=405f5748)
4 0x50301f1f (DEVPRJ.PKG..text+0xf1f in C:\PROGRAMME\MICROSOFT VISUAL STUDIO\COMMON\MSDEV98\BIN\DEVPRJ.PKG) (ebp=405f5764)
For me it seems, that at some point we get different arguments back from a
dll when run with snoop versus running without snoop. I don't expect subtile
timing problems, as the crash happens deterministic.
Bye
--
Uwe Bonnes bon at elektron.ikp.physik.tu-darmstadt.de
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
More information about the wine-devel
mailing list