Hi
Looking through debugmessages I found a small bug. There's a message of CALL ... (really all upper case) and the next message is appended to it, seems like there is a linefeed missing. I don't have cvs access and I didn't thought it's a bug as big as it would need a bug report. So I posted it here.
Why are there Call ... and CALL ...?
Fabi
"Fabian Cenedese" Cenedese@indel.ch wrote:
Looking through debugmessages I found a small bug. There's a message of CALL ... (really all upper case) and the next message is appended to it, seems like there is a linefeed missing. I don't have cvs access and I didn't thought it's a bug as big as it would need a bug report. So I posted it here.
Why are there Call ... and CALL ...?
"Call" indicates a normal relay trace call, "CALL" is an indication of the call performed by an external (i.e. not a Wine builtin) library.
Either turn of snooping (by removing +snoop from your command line), or take a look at relay32/snoop.c (32-bit snooping) and if1632/snoop.c (16-bit snooping) where all the snooping magic is implemented.
At the first glance there is nothing wrong in that files.
Looking through debugmessages I found a small bug. There's a message of CALL ... (really all upper case) and the next message is appended to
it, seems
like there is a linefeed missing. I don't have cvs access and I didn't thought it's a bug as big as it would need a bug report. So I posted it here.
Why are there Call ... and CALL ...?
"Call" indicates a normal relay trace call, "CALL" is an indication of the call performed by an external (i.e. not a Wine builtin) library.
Either turn of snooping (by removing +snoop from your command line), or take a look at relay32/snoop.c (32-bit snooping) and if1632/snoop.c (16-bit snooping) where all the snooping magic is implemented.
At the first glance there is nothing wrong in that files.
I found that this only happens if the first message is CALL ... and the second message is one of only a few messages. I found so far trace:seh:EXC_RtlRaiseException and trace:heap:RtlAllocateHeap. Then they get printed on one line. If they show up separately they're printed normally. Could also be some kind of performance problem or multithreading handling that the linefeed gets lost as I logged +all. (Though I have a 800MHz).
Here some sample output (look for :heap: or :seh:):
08071168:Ret kernel32.LocalAlloc() retval=403c10f0 ret=5f40fbc2 08071168:CALL MSVCRT.666: memset(403c10f0 "UUUUUUUUUUUUUUUUUUUUUUUUY",00000000,00000008) ret=5f40fbec 08071168:RET MSVCRT.666: memset() retval = 403c10f0 ret=5f40fbec 08071168:CALL MSVCRT.658: malloc(<unknown, check return>08071168:trace:heap:RtlAllocateHeap (40360000,00000002,00000040): returning 403c1110 ) ret=5f40fc79 08071168:RET MSVCRT.658: malloc() retval = 417e1e60 ret=5f40fc79 08071168:trace:heap:RtlFreeHeap (40360000,00000002,403c1110): returning TRUE 08071168:CALL MSVCRT.272: _initterm(<unknown, check return>08071168:trace:heap:RtlAllocateHeap (40360000,00000002,00000040): returning 403c1110 ) ret=5f40fca3 08071168:CALL MSVCRT.86: __dllonexit(5f412410,5f4d26b0,5f4d26ac) ret=5f4089d5 08071168:RET MSVCRT.86: __dllonexit() retval = 5f412410 ret=5f4089d5 08071168:CALL MSVCRT.86: __dllonexit(5f412506,5f4d26b0,5f4d26ac) ret=5f4089d5 08071168:RET MSVCRT.86: __dllonexit() retval = 5f412487 ret=5f4089d5 08071168:CALL MSVCRT.86: __dllonexit(5f41246c,5f4d26b0,5f4d26ac) ret=5f4089d5 08071168:RET MSVCRT.86: __dllonexit() retval = 5f41246c ret=5f4089d5 08071168:CALL MSVCRT.86: __dllonexit(5f412451,5f4d26b0,5f4d26ac) ret=5f4089d5 08071168:RET MSVCRT.86: __dllonexit() retval = 5f412451 ret=5f4089d5 08071168:CALL MSVCRT.86: __dllonexit(5f4123f5,5f4d26b0,5f4d26ac) ret=5f4089d5 08071168:RET MSVCRT.86: __dllonexit() retval = 5f4123f5 ret=5f4089d5 08071168:CALL MSVCRT.67: _EH_prolog(5f408b11,78001510,00000001,40fe0000,5f4d25a4,5f4d26a4,5f40f9dc,5f400000,00000001,00000001,00000001,5f40f9a1,4010ef04,405c6de4,4008abe1,5f400000, ...) ret=5f408b2c 08071168:RET MSVCRT.67: _EH_prolog() retval = 40fe0019 ret=5f408b2c 08071168:CALL MSVCRT.86: __dllonexit(5f412385,5f4d26b0,5f4d26ac) ret=5f4089d5 08071168:RET MSVCRT.86: __dllonexit() retval = 5f412385 ret=5f4089d5 08071168:CALL MSVCRT.86: __dllonexit(5f41237b,5f4d26b0,5f4d26ac) ret=5f4089d5 08071168:RET MSVCRT.86: __dllonexit() retval = 5f41237b ret=5f4089d5 08071168:CALL MSVCRT.86: __dllonexit(5f412371,5f4d26b0,5f4d26ac) ret=5f4089d5 08071168:RET MSVCRT.86: __dllonexit() retval = 5f4121fe ret=5f4089d5 08071168:CALL MSVCRT.86: __dllonexit(5f412144,5f4d26b0,5f4d26ac) ret=5f4089d5 08071168:RET MSVCRT.86: __dllonexit() retval = 5f412144 ret=5f4089d5 08071168:CALL MSVCRT.86: __dllonexit(5f4121ee,5f4d26b0,5f4d26ac) ret=5f4089d5 08071168:RET MSVCRT.86: __dllonexit() retval = 5f4121ee ret=5f4089d5 08071168:Call kernel32.GetOEMCP() ret=5f408e5e 08071168:Ret kernel32.GetOEMCP() retval=00000352 ret=5f408e5e 08071168:Call kernel32.GetCPInfo(00000352,405c6d74) ret=5f408e65 08071168:Ret kernel32.GetCPInfo() retval=00000001 ret=5f408e65 08071168:Call user32.RegisterWindowMessageA(5f49ff7c "commctrl_DragListMsg") ret=5f408e7c 08071168:trace:msg:RegisterWindowMessageA commctrl_DragListMsg 08071168: add_atom( local=0, name=L"commctrl_DragListMsg" ) 08071168: add_atom() = 0 { atom=c01b } 08071168:trace:atom:ATOM_AddAtomA (global) "commctrl_DragListMsg" -> c01b 08071168:Ret user32.RegisterWindowMessageA() retval=0000c01b ret=5f408e7c 08071168:CALL MSVCRT.67: _EH_prolog(5f408ea9,00000001,5f4d2640,5f408e9f,00000000,5f408e87,78001510,00000001,40fe0000,5f4d25a4,5f4d26a4,5f40f9dc,5f400000,00000001,00000001,00000001, ...) ret=5f402039 08071168:RET MSVCRT.67: _EH_prolog() retval = 40fe0019 ret=5f402039 08071168:CALL MSVCRT.666: memset(5f4d1b88,00000000,00000020) ret=5f408ebc 08071168:RET MSVCRT.666: memset() retval = 5f4d1b88 ret=5f408ebc 08071168:CALL MSVCRT.86: __dllonexit(5f40180c,5f4d26b0,5f4d26ac) ret=5f4089d5 08071168:RET MSVCRT.86: __dllonexit() retval = 5f40180c ret=5f4089d5 08071168:CALL MSVCRT.67: _EH_prolog(5f408ea9,00000001,5f4d2644,5f408ee9,00000001,5f408ed1,78001510,00000001,40fe0000,5f4d25a4,5f4d26a4,5f40f9dc,5f400000,00000001,00000001,00000001, ...) ret=5f402039 08071168:RET MSVCRT.67: _EH_prolog() retval = 40fe0019 ret=5f402039 08071168:CALL MSVCRT.666: memset(5f4d1bc8,00000000,00000020) ret=5f408ebc 08071168:RET MSVCRT.666: memset() retval = 5f4d1bc8 ret=5f408ebc 08071168:CALL MSVCRT.86: __dllonexit(5f4121d0,5f4d26b0,5f4d26ac) ret=5f4089d5 08071168:RET MSVCRT.86: __dllonexit() retval = 5f4121d0 ret=5f4089d5 08071168:CALL MSVCRT.67: _EH_prolog(5f408ea9,00000001,5f4d2648,5f408f07,ffffffff08071168:trace:seh:EXC_RtlRaiseException code=c0000005 flags=0 addr=0x400c9c77 08071168:trace:seh:EXC_RtlRaiseException info[0]=00000000 08071168:trace:seh:EXC_RtlRaiseException info[1]=ffffffff 08071168: queue_exception_event( first=1, record={context={flags=00000000,eax=00000000,ebx=4010ef04,ecx=ffffffff,edx=00000000,esi=00000000,edi=00000010,ebp=405c69d8,eip=400c9c77,esp=405c691c,eflags=00010246,cs=0023,ds=002b,es=002b,fs=008f,gs=0000,dr0=00000000,dr1=00000000,dr2=00000000,dr3=00000000,dr6=00000000,dr7=00000000,float={00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000}},rec={code=c0000005,flags=0,rec=(nil),addr=0x400c9c77,params={0,ffffffff}} ) 08071168: queue_exception_event() = 0 { handle=0 } 08071168:trace:seh:EXC_CallHandler calling handler at 0x400dcb40 code=c0000005 flags=0 08071168:trace:seh:EXC_RtlUnwind code=c0000005 flags=2 08071168:trace:seh:EXC_CallHandler calling handler at 0x400dc3d0 code=c0000005 flags=2 08071168:trace:seh:EXC_CallHandler handler returned 1 ,5f408eef,78001510,00000001,40fe0000,5f4d25a4,5f4d26a4,5f40f9dc,5f400000,00000001,00000001,00000001, ...) ret=5f402039 08071168:RET MSVCRT.67: _EH_prolog() retval = 40fe0019 ret=5f402039 08071168:CALL MSVCRT.666: memset(5f4d1c08,00000000,00000020) ret=5f408ebc 08071168:RET MSVCRT.666: memset() retval = 5f4d1c08 ret=5f408ebc 08071168:CALL MSVCRT.86: __dllonexit(5f4121b2,5f4d26b0,5f4d26ac) ret=5f4089d5 08071168:RET MSVCRT.86: __dllonexit() retval = 5f4121b2 ret=5f4089d5 08071168:CALL MSVCRT.67: _EH_prolog(5f408ea9,00000001,5f4d264c,5f408f25,fffffffe08071168:trace:seh:EXC_RtlRaiseException code=c0000005 flags=0 addr=0x400c9c77 08071168:trace:seh:EXC_RtlRaiseException info[0]=00000000 08071168:trace:seh:EXC_RtlRaiseException info[1]=fffffffe 08071168: queue_exception_event( first=1, record={context={flags=00000000,eax=00000000,ebx=4010ef04,ecx=fffffffe,edx=00000000,esi=00000000,edi=00000010,ebp=405c69d8,eip=400c9c77,esp=405c691c,eflags=00010246,cs=0023,ds=002b,es=002b,fs=008f,gs=0000,dr0=00000000,dr1=00000000,dr2=00000000,dr3=00000000,dr6=00000000,dr7=00000000,float={00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000}},rec={code=c0000005,flags=0,rec=(nil),addr=0x400c9c77,params={0,fffffffe}} ) 08071168: queue_exception_event() = 0 { handle=0 } 08071168:trace:seh:EXC_CallHandler calling handler at 0x400dcb40 code=c0000005 flags=0 08071168:trace:seh:EXC_RtlUnwind code=c0000005 flags=2 08071168:trace:seh:EXC_CallHandler calling handler at 0x400dc3d0 code=c0000005 flags=2 08071168:trace:seh:EXC_CallHandler handler returned 1
bye Fabi
"Fabian Cenedese" Cenedese@indel.ch wrote:
I found that this only happens if the first message is CALL ... and the second message is one of only a few messages. I found so far trace:seh:EXC_RtlRaiseException and trace:heap:RtlAllocateHeap. Then they get printed on one line. If they show up separately they're printed normally. Could also be some kind of performance problem or multithreading handling that the linefeed gets lost as I logged +all. (Though I have a 800MHz).
+all is *always* an overkill. You have 800 MHz or better it doesn't matter. If you are trying to debug a problem, first start with simple +relay, examine the log, and only then, *looking into the Wine sources*, try to turn on other debug channels.
-
Dmitry Timoshkov -
Fabian Cenedese