Still problems with snoop

[Uwe Bonnes]

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.

Bye

[Francois Gouget]

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.

Some time ago I found that we would crash in SNOOP_PrintArg when
x==-1, eventhough it's all in a try/catch. I didn't get time to
investigate in detail. You can try to see if this patch makes things
better (the traces are there for debug in case you remove the -1 test):

--- cut here ---
Index: relay32/snoop.c
===================================================================
RCS file: /home/wine/wine/relay32/snoop.c,v
retrieving revision 1.44
diff -u -r1.44 snoop.c
--- relay32/snoop.c	2001/07/18 20:00:06	1.44
+++ relay32/snoop.c	2001/07/20 23:31:02
@@ -212,7 +214,7 @@
    int		i,nostring;
    char * volatile ret=0;

-	if ( !HIWORD(x) ) { /* trivial reject to avoid faults */
+	if ( !HIWORD(x) || x==-1 ) { /* trivial reject to avoid faults
*/
        sprintf(buf,"%08lx",x);
        return buf;
    }
@@ -220,9 +222,13 @@
    	LPBYTE	s=(LPBYTE)x;
    	i=0;nostring=0;
    	while (i<80) {
+                    if (x==-1) TRACE("%d: i=%d\n",__LINE__,i);
    		if (s[i]==0) break;
+                    if (x==-1) TRACE("%d: i=%d\n",__LINE__,i);
    		if (s[i]<0x20) {nostring=1;break;}
+                    if (x==-1) TRACE("%d: i=%d\n",__LINE__,i);
    		if (s[i]>=0x80) {nostring=1;break;}
+                    if (x==-1) TRACE("%d: i=%d\n",__LINE__,i);
    		i++;
    	}
    	if (!nostring) {
--- cut here ---

--
Francois Gouget         [e-mail]        http://fgouget.free.fr/
           If it stinks, it's chemistry. If it moves, it's biology.
                  If it does not work, It's computer science.

[Uwe Bonnes]

> > > > > "Francois" == Francois Gouget  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@CWnd@@MAEHIIJPAJ@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@III@Z+0x10 in C:\NT4SP5G\SYSTEM32\MFC42.DLL) (ebp=405f567c)
  1 0x5f44780a (?OnWndMsg@CWnd@@MAEHIIJPAJ@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