Wierd random spew to the terminal

[Mike Hearn]

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

[Michael Stefaniuc]

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

[Mike Hearn]

> 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...

[Carlos Lozano]

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.

[Sylvain Petreolle]

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 
> 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