emacs-pretest-bug
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Asynchronous bug


From: Stefan Monnier
Subject: Asynchronous bug
Date: Wed, 30 Apr 2003 14:34:35 -0400

I've been getting random crashes for a while and finally tracked it
down to something useful.  The way it manifests itself is typically
by a crash in mark_object, most of the time because the value of
`nil' is garbage pointing to nowhereland.

Watchpoints showed that the value of `nil' is modified in `unbind_to'.
The way it works is that specpdl_ptr->symbol changes from non-nil
to nil in the time between the nil test and the use of the value.

The reason why the value is changed is because of async interrupts.
Here is a backtrace showing how code run from the signal handler ends
up calling record_unwind_protect (which will mess with specpdl_ptr):

#0  abort () at emacs.c:413
#1  0x082024df in die () at alloc.c:5483
#2  0x08229240 in record_unwind_protect (
    function=0x81428f4 <x_catch_errors_unwind>, arg=1483500012) at eval.c:3090
#3  0x0814288e in x_catch_errors (dpy=0x8766270) at xterm.c:7529
#4  0x0814b7eb in x_real_positions (f=0x88262e0, xptr=0x87e3668, 
    yptr=0x87e366c) at xfns.c:780
#5  0x0813ec84 in handle_one_xevent (dpyinfo=0x8775c50, eventp=0xbffd14d4, 
    bufp_r=0xbffd1558, numcharsp=0xbffd155c, finish=0xbffd14c8) at xterm.c:6710
#6  0x0813f609 in XTread_socket (sd=0, bufp=0xbffd2584, numchars=4096, 
    expected=1) at xterm.c:7088
#7  0x08185c6c in read_avail_input (expected=1) at keyboard.c:6570
#8  0x08185fda in input_available_signal (signo=29) at keyboard.c:6723
#9  <signal handler called>
#10 0x402e5f81 in kill () from /lib/libc.so.6
#11 0x0818601b in reinvoke_input_signal () at keyboard.c:6752
#12 0x0815349d in x_sync (f=0x88262e0) at xfns.c:4096
#13 0x08145159 in x_make_frame_visible (f=0x88262e0) at xterm.c:8680
#14 0x0806bc1d in Fmake_frame_visible (frame=1216504544) at frame.c:1543
...

Admittedly, in this case the signal is actually synchronous, so
maybe this is not the real problem, but it's still a case where
code called from XTread_socket messes with specpdl_ptr.

Does anybody have an idea how to deal with this ?


        Stefan





reply via email to

[Prev in Thread] Current Thread [Next in Thread]