emacs-devel
[Top][All Lists]
Advanced

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

Re: SEGV in x_catch_errors_unwind (x86_64-unknown-linux-gnu)


From: John W. Eaton
Subject: Re: SEGV in x_catch_errors_unwind (x86_64-unknown-linux-gnu)
Date: Sat, 25 Feb 2006 12:47:52 -0500

On 25-Feb-2006, Chong Yidong wrote:

| Chong Yidong <address@hidden> writes:
| 
| >> However, as I was looking at the following loop unbind_to in eval.c,
| >> it occurred to me that one way the x_catch_errors_unwind function
| >> could be called twice in succession would be if specpdl_ptr is
| >> incremented by the addition of additional bindings while the loop is
| >> running (by some other code that is misbehaving while manipulating the
| >> specpdl array).
| 
| There isn't any misbehaving code, btw.  Since unbind_to is currently
| run without BLOCK_INPUT, it can be interrupted by a signal handler.
| The signal handler can call the x error handler, which calls
| record_unwind_protect, which screws things up.

| One solution is to somehow re-engineer the x error handler not to use
| record_unwind_protect.

I think this might be the best bet.

| The other is to block inputs at the point in
| unbind_to where specpdl_ptr is being modified, like this:

This does not solve the problem for me.  It seems to be harder to
generate the crash, but I am still hitting the x_error_message == 0
segfault.

Again, the way I'm triggering the bug is to run Emacs under gdb.  The
last line of my .gdbinit file is

  set args -q file1 file2 ...

where the list of files was generated with

  find ~/src/octave -name '*.cc'

There are 386 files in the list.  The rest of the .gdbinit file is
extracted from the .gdbinit file in the Emacs src directory that I
checked out from savannah.I had to throw out a few things that did not
apply because I'm installing emacs (--prefix=/usr/local/cvs-emacs)
before running it.  While Emacs is processing the list of files, I
grab the title bar of the window with the mouse pointer and rapidly
move the Emacs window around the screen.

Before applying your latest patch, I could generate a crash in maybe 7
or 8 out of 10 tries.  With the patch, it is down to around 1 or 2 out
of 10 tries, but it is still crashing.

Just to be sure I haven't screwed something up, I updated from the
public CVS archive for Emacs and made sure that I had no local
modifications, then applied your patch and ran configure and make
bootstrap, then generated a crash with the method explained above.

Even surrounding the entire body of unbind_to with a
BLOCK_INPUT/UNBLOCK_INPUT pair did not avoid the crash, though it took
nearly 20 attempts to trigger it.  Of course, even if this had worked,
I don't think it could be a solution becuase it would prevent any user
input from happening inside the cleanup portion of an unwind-protect
form.

BTW, as a wishlist item, it would be nice if either the manual or the
source included an explanation of the origin of names like specpdl,
staticpro, gcpro, etc.  It took some time before I understood what
these mean, even after looking at the declarations for these
variables/macros/functions (and I'm still not sure of how the term
specpdl was derived).  OTOH, perhaps I just missed them, or am
unusually slow to catch on.

Thanks,

jwe




reply via email to

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