From xemacs-m  Sat Mar 15 17:08:38 1997
Received: from mailbox1.ucsd.edu (mailbox1.ucsd.edu [132.239.1.53])
	by xemacs.org (8.8.5/8.8.5) with ESMTP id RAA20735
	for <xemacs-beta@xemacs.org>; Sat, 15 Mar 1997 17:08:37 -0600 (CST)
Received: from sdnp5.ucsd.edu (sdnp5.ucsd.edu [132.239.79.10]) by mailbox1.ucsd.edu (8.8.5/8.6.9) with SMTP id PAA28250 for <xemacs-beta@xemacs.org>; Sat, 15 Mar 1997 15:08:38 -0800 (PST)
Received: by sdnp5.ucsd.edu (SMI-8.6/SMI-SVR4)
	id PAA09953; Sat, 15 Mar 1997 15:10:41 -0800
Sender: dmoore@sdnp5.ucsd.edu
To: xemacs-beta@xemacs.org
Subject: Re: Bug in XEmacs
References: <Pine.GSO.3.96.970313105629.15936A-100000@camoes.rnl.ist.utl.pt> 	<m2vi6vm5z2.fsf@altair.xemacs.org> 	<rv7mjbx89y.fsf@sdnp5.ucsd.edu> <199703141516.KAA01189@anthem.CNRI.Reston.Va.US> <m2endif82g.fsf@altair.xemacs.org>
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
Mime-Version: 1.0 (generated by tm-edit 7.105)
Content-Type: multipart/mixed;
 boundary="Multipart_Sat_Mar_15_15:10:40_1997-1"
Content-Transfer-Encoding: 7bit
From: David Moore <dmoore@ucsd.edu>
Date: 15 Mar 1997 15:10:40 -0800
In-Reply-To: Steven L Baur's message of 14 Mar 1997 14:00:07 -0800
Message-ID: <rv7mj8n43z.fsf@sdnp5.ucsd.edu>
Lines: 137
X-Mailer: Gnus v5.4.24/XEmacs 19.15

--Multipart_Sat_Mar_15_15:10:40_1997-1
Content-Type: text/plain; charset=US-ASCII

Steven L Baur <steve@miranova.com> writes:

> "Barry A. Warsaw" <bwarsaw@anthem.cnri.reston.va.us> writes:
> 
> > Or maybe its just us, and we suck.
> 
> We don't have any procedures for handling and maintaining bug reports,
> so the same bugs keep getting reported and the bugs (sometimes) don't
> get fixed.

Anyone get gnats working yet?

> > #0  0xef273e30 in Qoverwrite_mode_binary ()
> > #1  0x6b3e4 in fatal_error_signal ()
> > #2  0xef237d4c in Qoverwrite_mode_binary ()
> > #3  0x724f4 in funcall_lambda ()

Ok, the topmost Qoverwrite_mode_binary has been fixed, at least in some
cases, with my recent patch to auto_save_error.

The problem looks like one of the method pointers in a display device
struct is getting corrupted.  So when it goes to display (to the echo
area for example), it blows off the end of the text segment.

The second Qoverwrite_mode_binary (which just means past the end of the
text segement with the prebuilt 19.14 binaries) seems to be generated
when someone in the error handler tries to use these corrupted entries
some more.  This suggests that the auto_save_error patch really won't
fix things, since lisp code can run during auto-save, and some of that
might try doing a message or otherwise try talking to a display.

Of course figuring out where it's getting corrupted should be quite a
challenge.


Hmm, you know, there are several places in the code will die a horrible
death if an file handler kills the buffer it's working on behalf of.
Patch against 19.15b98+ for one such problem in Fdo_auto_save.


--Multipart_Sat_Mar_15_15:10:40_1997-1
Content-Type: application/octet-stream; type=patch
Content-Disposition: attachment; filename="f.diff"
Content-Transfer-Encoding: 7bit

--- fileio.c.orig	Sat Mar 15 14:28:34 1997
+++ fileio.c	Sat Mar 15 15:02:54 1997
@@ -4196,17 +4196,19 @@
        (no_message, current_only))
 {
   /* This function can GC */
-  struct buffer *old = current_buffer, *b;
+  struct buffer *b;
   Lisp_Object tail, buf;
   int auto_saved = 0;
   int do_handled_files;
   Lisp_Object oquit = Qnil;
   Lisp_Object listfile = Qnil;
+  Lisp_Object old;
   int listdesc = -1;
   int speccount = specpdl_depth ();
-  struct gcpro gcpro1, gcpro2;
+  struct gcpro gcpro1, gcpro2, gcpro3;
 
-  GCPRO2 (oquit, listfile);
+  XSETBUFFER (old, current_buffer);
+  GCPRO3 (oquit, listfile, old);
   check_quit (); /* make Vquit_flag accurate */
   /* Ordinarily don't quit within this function,
      but don't make it impossible to quit (in case we get hung in I/O).  */
@@ -4358,14 +4360,36 @@
 		  write (listdesc, "\n", 1);
 		}
 
-	      condition_case_1 (Qt,
-				auto_save_1, Qnil,
-				auto_save_error, Qnil);
+	      /* dmoore - In a bad scenario we've set b=XBUFFER(buf)
+		 based on values in Vbuffer_alist.  auto_save_1 may
+		 cause lisp handlers to run.  Those handlers may kill
+		 the buffer and then GC.  Since the buffer is killed,
+		 it's no longer in Vbuffer_alist so it might get reaped
+		 by the GC.  We also need to protect tail. */
+	      /* #### There is probably a lot of other code which has
+		 pointers into buffers which may get blown away by
+		 handlers. */
+	      {
+		struct gcpro gcpro1, gcpro2;
+		GCPRO2 (buf, tail);
+		condition_case_1 (Qt,
+				  auto_save_1, Qnil,
+				  auto_save_error, Qnil);
+		UNGCPRO;
+	      }
+	      /* Handler killed our saved current-buffer!  Pick any. */
+	      if (!BUFFER_LIVE_P (XBUFFER (old)))
+		XSETBUFFER (old, current_buffer);
+
+	      set_buffer_internal (XBUFFER (old));
 	      auto_saved++;
+	      
+	      /* Handler killed their own buffer! */
+	      if (!BUFFER_LIVE_P(b))
+		continue;
+
 	      b->auto_save_modified = BUF_MODIFF (b);
 	      b->save_length = make_int (BUF_SIZE (b));
-	      set_buffer_internal (old);
-
 	      EMACS_GET_TIME (after_time);
 	      /* If auto-save took more than 60 seconds,
 		 assume it was an NFS failure that got a timeout.  */
--- /dev/null	Sat Mar 15 04:12:25 1997
+++ ChangeLog	Sat Mar 15 15:02:31 1997
@@ -0,0 +1,5 @@
+Sat Mar 15 14:21:39 1997  David Moore  <dmoore@ucsd.edu>
+
+	* fileio.c (Fdo_auto_save): Protect against file handlers which
+ 	may kill the buffer being saved or otherwise modify Vbuffer_alist.
+

--Multipart_Sat_Mar_15_15:10:40_1997-1
Content-Type: text/plain; charset=US-ASCII



Look ma, ChangeLog entry.
-- 
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.

--Multipart_Sat_Mar_15_15:10:40_1997-1--

