Hmm, I think quite a few of us have seen this now. Well, it just happened again so this time I attached gdb and tried to get a backtrace to see what was going on.
I found a very curious thing.... the stack trace was huge, in fact, it had 3162 frames. As you might expect it was recursive. It looked like this:
#3141 <signal handler called> #3142 0x4009e977 in rwlock_real_init (rwlock=0x42126020) at ../../include/winbase.h:1932 #3143 0x4009ea48 in __pthread_rwlock_rdlock (rwlock=0x42126020) at ../../scheduler/pthread.c:547 #3144 0x4202365a in __dcigettext () from /lib/i686/libc.so.6 #3145 0x42022ed5 in dcgettext () from /lib/i686/libc.so.6 #3146 0x4207a4b7 in strerror_r () from /lib/i686/libc.so.6 #3147 0x4206148b in perror () from /lib/i686/libc.so.6 #3148 0x40099259 in server_protocol_perror (err=0x400bdc31 "read") at ../../scheduler/client.c:134 #3149 0x40099388 in read_reply_data (buffer=0x405ca5a4, size=64) at ../../scheduler/client.c:195 #3150 0x400993de in wine_server_call (req_ptr=0x405ca5a4) at ../../scheduler/client.c:209 #3151 0x400a8653 in send_debug_event (rec=0x405ca6a8, first_chance=1, context=0x405ca71c) at exception.c:137 #3152 0x400a87fa in EXC_RtlRaiseException (rec=0x405ca6a8, context=0x405ca71c) at exception.c:195 #3153 0x400b6e48 in do_segv (context=0x405ca71c, trap_code=14, cr2=0x18, err_code=4) at signal_i386.c:814 #3154 0x400b7324 in segv_handler (__signal=11, __context= {sc_gs = 143, __gsh = 0, sc_fs = 143, __fsh = 0, sc_es = 43, __esh = 0, sc_ds = 43, __dsh = 0, sc_edi = 1108452444, sc_esi = 1108500512, sc_ebp = 1079815400, sc_esp = 1079815380, sc_ebx = 1074654520, sc_edx = 1108500512, sc_ecx = 1108481382, sc_eax = 0, sc_trapno = 14, sc_err = 4, sc_eip = 1074391415, sc_cs = 35, __csh = 0, sc_eflags = 66050, esp_at_signal = 1079815380, sc_ss = 43, __ssh = 0, i387 = 0, oldmask = 2415929859, cr2 = 24}) at signal_i386.c:436 #3155 <signal handler called>
So it would appear that there is a crash in the exception handler which just goes round and round, and clearly at some point garbage is written to stdout/stderr.
Unfortunately my code-fu is not strong in areas related to threading/exception handling, so I don't really know what's going wrong, except that it seems there is a problem in rwlock_real_init (in fact the line number it gives is in GetProcessHeap()).
Well, I thought somebody may find it useful. BTW, after I attached to wine (ie stopped it) something was still typing out letter by letter "xtermxtermxterm" over and over again.... wake up neo :)
thanks -mike
On Mon, Jun 02, 2003 at 04:03:49PM +0100, Mike Hearn wrote:
Hmm, I think quite a few of us have seen this now. Well, it just happened again so this time I attached gdb and tried to get a backtrace to see what was going on.
I found a very curious thing.... the stack trace was huge, in fact, it had 3162 frames. As you might expect it was recursive. It looked like this:
I once had this problem and it was triggered by an unimplemented function in msvcrt. Did you tried running with --debugmsg +seh? But better redirect the output to a file.
bye michael
#3141 <signal handler called> #3142 0x4009e977 in rwlock_real_init (rwlock=0x42126020) at ../../include/winbase.h:1932 #3143 0x4009ea48 in __pthread_rwlock_rdlock (rwlock=0x42126020) at ../../scheduler/pthread.c:547 #3144 0x4202365a in __dcigettext () from /lib/i686/libc.so.6 #3145 0x42022ed5 in dcgettext () from /lib/i686/libc.so.6 #3146 0x4207a4b7 in strerror_r () from /lib/i686/libc.so.6 #3147 0x4206148b in perror () from /lib/i686/libc.so.6 #3148 0x40099259 in server_protocol_perror (err=0x400bdc31 "read") at ../../scheduler/client.c:134 #3149 0x40099388 in read_reply_data (buffer=0x405ca5a4, size=64) at ../../scheduler/client.c:195 #3150 0x400993de in wine_server_call (req_ptr=0x405ca5a4) at ../../scheduler/client.c:209 #3151 0x400a8653 in send_debug_event (rec=0x405ca6a8, first_chance=1, context=0x405ca71c) at exception.c:137 #3152 0x400a87fa in EXC_RtlRaiseException (rec=0x405ca6a8, context=0x405ca71c) at exception.c:195 #3153 0x400b6e48 in do_segv (context=0x405ca71c, trap_code=14, cr2=0x18, err_code=4) at signal_i386.c:814 #3154 0x400b7324 in segv_handler (__signal=11, __context= {sc_gs = 143, __gsh = 0, sc_fs = 143, __fsh = 0, sc_es = 43, __esh = 0, sc_ds = 43, __dsh = 0, sc_edi = 1108452444, sc_esi = 1108500512, sc_ebp = 1079815400, sc_esp = 1079815380, sc_ebx = 1074654520, sc_edx = 1108500512, sc_ecx = 1108481382, sc_eax = 0, sc_trapno = 14, sc_err = 4, sc_eip = 1074391415, sc_cs = 35, __csh = 0, sc_eflags = 66050, esp_at_signal = 1079815380, sc_ss = 43, __ssh = 0, i387 = 0, oldmask = 2415929859, cr2 = 24}) at signal_i386.c:436 #3155 <signal handler called>
So it would appear that there is a crash in the exception handler which just goes round and round, and clearly at some point garbage is written to stdout/stderr.
Unfortunately my code-fu is not strong in areas related to threading/exception handling, so I don't really know what's going wrong, except that it seems there is a problem in rwlock_real_init (in fact the line number it gives is in GetProcessHeap()).
Well, I thought somebody may find it useful. BTW, after I attached to wine (ie stopped it) something was still typing out letter by letter "xtermxtermxterm" over and over again.... wake up neo :)
thanks -mike
I once had this problem and it was triggered by an unimplemented function in msvcrt. Did you tried running with --debugmsg +seh? But better redirect the output to a file.
Nope:
wine client error:0: trace:seh:EXC_RtlRaiseException code=c0000005 flags=0 addr=0x4009e977 trace:seh:EXC_RtlRaiseException info[0]=00000000 trace:seh:EXC_RtlRaiseException info[1]=00000018
It's just a plain old access violation...
El lun, 02 de jun de 2003, a las 16:03, Mike Hearn escribio:
Hmm, I think quite a few of us have seen this now. Well, it just happened again so this time I attached gdb and tried to get a backtrace to see what was going on.
I have seen it. Sometimes i can read the message:
"wine client error"
Regards, Carlos.
dont know why but I have the same issue sometime... and the letters are writting xterm everytime I have this...
before that you have terminal control codes sent to your terminal, which sets it to graphical characters mode. this happens when winedbg crashes. the "xtermxterm" is really fast and slows if you dont kill wine process... after that run 'reset' in your xterm.
you must sometimes kill the terminal because it has become unusable, if you didnt see it early enough.
Well, I thought somebody may find it useful. BTW, after I attached to wine (ie stopped it) something was still typing out letter by letter "xtermxtermxterm" over and over again.... wake up neo :)
thanks -mike
-- Mike Hearn m.hearn@signal.qinetiq.com QinetiQ - Malvern Technology Center
===== Sylvain Petreolle (spetreolle at users dot sourceforge dot net) ICQ #170597259 No more War !
"What if tomorrow the War could be over ?" Morpheus, in "Reloaded".
For the Law of Oil and Fire, Im an European that lives in France. For all my Brothers and friends, Im a human living on Earth.
___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
-
Carlos Lozano -
Michael Stefaniuc -
Mike Hearn -
Sylvain Petreolle