Re: address@hidden: Emacs crashes when after closing frame with alternate display]

[Martin Schwenke]

>>>>> "Eli" == Eli Zaretskii <address@hidden> writes:

    Eli> On Sun, 11 Nov 2001, Richard Stallman wrote:

    >> Has anyone been able to work on this?  Does anyone have two
    >> machines to try this with?

    Eli> I agree with the assessment that this is probably not an
    Eli> Emacs problem (it seems like XFindContext gets SIGSEGV).

I reported a similar bug in Emacs 20.7 and it appears to have been
fixed.  The problem occurred when Emacs tried to create a frame on a
display where it didn't have access (say, via xauth).  The problem I
was seeing was probably Emacs not checking a return value and then
passing garbage to a subsequent X routine.  If Gerd is still around
then he might remember it...

    Eli> I can try to reproduce this on two SGI boxes I have here, but
    Eli> I need to build gnudoit first.  Where do I find it?

I've tried it with gnuclient (the current version of gnudoit is a
shell script that calls gnuclient) over SSH, and I can't reproduce it
under Debian GNU/Linux (running XFree86 4.1.0).  I can open a remote
frame and then close it, without problems...  Perhaps Peter's case
occurs when using gnuserv's internet domain sockets (although I can't
really see why Emacs would do anything different when opening and
closing frames), but he didn't say...

    Eli> Peter, can this be reproduced without gnudoit?  If so, how?
    Eli> Even if I must use gnudoit, I need a precise recipe to
    Eli> reproduce the crash, starting with "emacs -q
    Eli> --no-start-file".  Could you please supply such a recipe?

As far as I'm aware, gnuserv only uses make-frame and
make-frame-on-display, although that's with the current XEmacs version
of gnuserv (a package containing this version that (mostly) works
under GNU Emacs is available via http://meltin.net/hacks/emacs/).
That means that you ought to be able to reproduce it using
make-frame-on-display (along with appropriate xhost/xauth commands)
instead of gnudoit.

Could this bug have something to do with the fact that Emacs doesn't
close a connection to a display when its last frame on that display is
closed (although doing so might be expensive), and sometimes that
display can disappear?  Maybe the redisplay is following a dead
pointer or something?

Opening a remote frame via an SSH connection and then closing the
frame stops the SSH session from exiting, because it is waiting for
connections to its X display to close.  When this happens, killing SSH
used to be able to crash Emacs, but that appears to be fixed in Emacs
21.1.

Sorry, no answers here, but hopefully some useful ideas...

peace & happiness,
martin