From xemacs-m  Wed Feb  5 13:37:43 1997
Received: from UCSD.EDU (mailbox2.ucsd.edu [132.239.1.54])
	by xemacs.org (8.8.5/8.8.5) with ESMTP id NAA02691
	for <xemacs-beta@xemacs.org>; Wed, 5 Feb 1997 13:37:42 -0600 (CST)
Received: from sdnp5.ucsd.edu (sdnp5.ucsd.edu [132.239.79.10]) by UCSD.EDU (8.8.5/8.6.9) with SMTP id LAA26339 for <xemacs-beta@xemacs.org>; Wed, 5 Feb 1997 11:37:41 -0800 (PST)
Received: by sdnp5.ucsd.edu (SMI-8.6/SMI-SVR4)
	id LAA02714; Wed, 5 Feb 1997 11:40:26 -0800
Sender: dmoore@sdnp5.ucsd.edu
To: XEmacs Beta mailing list <xemacs-beta@xemacs.org>
Subject: Re: XEmacs 20.0-b93 & 20.0 dump core w/ Mule...
References: <Pine.LNX.3.95.970205182214.303A-100000@icemark.thenet.ch> <QQcbpq20356.199702051830@crystal.WonderWorks.COM>
X-Face: "oX;zS#-JU$-,WKSzG.1gGE]x^cIg!hW.dq>.f6pzS^A+(k!T|M:}5{_%>Io<>L&{hO7W4cicOQ|>/lZ1G(m%7iaCf,6Qgk0%%Bz7b2-W3jd0m_UG\Y;?]}4s0O-U)uox>P3JN)9cm]O\@,vy2e{`3pb!"pqmRy3peB90*2L
Mail-Copies-To: never
From: David Moore <dmoore@UCSD.EDU>
Date: 05 Feb 1997 11:40:25 -0800
In-Reply-To: Kyle Jones's message of Wed, 5 Feb 1997 13:30:31 -0500 (EST)
Message-ID: <rv6807qbx2.fsf@sdnp5.ucsd.edu>
Lines: 114
X-Mailer: Gnus v5.4.8/XEmacs 19.15

Kyle Jones <kyle_jones@wonderworks.com> writes:

> This crash looks familiar.  I'll exit XEmacs sometimes and it
> takes long time to die.  I look around and usually there's a
> core file that contains a stacktrace something like this.
> 
> Do you use balloon-help or floating-toolbar?  I have a gut
> feeling that invisible frames are a catalyst for this crash.

	It definitely looks like popup frames are the cause.  I thought
I had mailed about this before, but now I think I didn't because I
couldn't fully understand the code.

	The problem might be in the logic of x_delete_frame which tries
not to delete the information of a child when the parent has already
been deleted.  And the code in device_delete_internal loops over frames
in various stages hoping to avoid ordering problems.  But I don't think
it's doing it right.  And I really don't think it's doing it right if
you have minibufferless frames and popups.  Hmm, the balloon-help and
floating-toolbar frames are minibuffer less.  Do they have popup
children?

	At the moment, I'm way too swamped to try to understand this
code. :/ But maybe this info will help someone else.  Definitely look at
the order frames are deleted inside of device_delete_internal.
Something is bad there.

	You could try the patch below which tries to clean up the popups
before the minibufferless frames.  Or maybe a better thing is to try to
create a complete topologically sorted list of the frames which can be
safely deleted along.  Or maybe some other code is broken and the popup
field is self referential, etc.

	It might help a lot if someone could come up with a highly
repeatable test case, so we could see what the structure of the popup
properties on the frames and other orderings are before it crashes.
Also, if you've had this crash, have you put frames on multiple x
displays during the life of that xemacs, and have you done tty
connections to that xemacs?



This patch is a wild guess.  But at the moment I see no reason to prefer
the previous ordering either, and switching didn't immediately break
things for me.  But then I don't make heavy use of popups.

Patch against Xemacs 20.0b93 (Yes, that's 93, been too busy to fetch a
new version.)  I suspect it'll apply cleanly to the current version.

*** device.c.orig	Wed Feb  5 11:29:45 1997
--- device.c	Wed Feb  5 11:30:41 1997
***************
*** 731,755 ****
    {
      Lisp_Object frmcons;
  
-     /* First delete all frames without their own minibuffers,
-        to avoid errors coming from attempting to delete a frame
-        that is a surrogate for another frame. */
-     DEVICE_FRAME_LOOP (frmcons, d)
-       {
- 	struct frame *f = XFRAME (XCAR (frmcons));
- 	/* delete_frame_internal() might do anything such as run hooks,
- 	   so be defensive. */
- 	if (FRAME_LIVE_P (f) && !FRAME_HAS_MINIBUF_P (f))
- 	  delete_frame_internal (f, 1, 1, from_io_error);
- 
- 	if (!DEVICE_LIVE_P (d)) /* make sure the delete-*-hook didn't
- 				   go ahead and delete anything */
- 	  {
- 	    UNGCPRO;
- 	    return;
- 	  }
-       }
- 
      /* #### This should probably be a device method but it is time for
         19.14 to go out the door. */
  #ifdef HAVE_X_WINDOWS
--- 731,736 ----
***************
*** 774,779 ****
--- 755,779 ----
  	  }
        }
  #endif /* HAVE_X_WINDOWS */
+ 
+     /* First delete all frames without their own minibuffers,
+        to avoid errors coming from attempting to delete a frame
+        that is a surrogate for another frame. */
+     DEVICE_FRAME_LOOP (frmcons, d)
+       {
+ 	struct frame *f = XFRAME (XCAR (frmcons));
+ 	/* delete_frame_internal() might do anything such as run hooks,
+ 	   so be defensive. */
+ 	if (FRAME_LIVE_P (f) && !FRAME_HAS_MINIBUF_P (f))
+ 	  delete_frame_internal (f, 1, 1, from_io_error);
+ 
+ 	if (!DEVICE_LIVE_P (d)) /* make sure the delete-*-hook didn't
+ 				   go ahead and delete anything */
+ 	  {
+ 	    UNGCPRO;
+ 	    return;
+ 	  }
+       }
  
      DEVICE_FRAME_LOOP (frmcons, d)
        {


-- 
David Moore <dmoore@ucsd.edu>       | Computer Systems Lab      __o
UCSD Dept. Computer Science - 0114  | Work: (619) 534-8604    _ \<,_
La Jolla, CA 92093-0114             | Fax:  (619) 534-1445   (_)/ (_)
<URL:http://oj.egbt.org/dmoore/>    | In a cloud bones of steel.

