From xemacs-m  Tue Mar 25 13:51:26 1997
Received: from mailbox2.ucsd.edu (mailbox2.ucsd.edu [132.239.1.54])
	by xemacs.org (8.8.5/8.8.5) with ESMTP id NAA08665
	for <xemacs-beta@xemacs.org>; Tue, 25 Mar 1997 13:51:25 -0600 (CST)
Received: from sdnp5.ucsd.edu (sdnp5.ucsd.edu [132.239.79.10]) by mailbox2.ucsd.edu (8.8.5/8.6.9) with SMTP id LAA15756 for <xemacs-beta@xemacs.org>; Tue, 25 Mar 1997 11:51:27 -0800 (PST)
Received: by sdnp5.ucsd.edu (SMI-8.6/SMI-SVR4)
	id LAA13626; Tue, 25 Mar 1997 11:53:18 -0800
Sender: dmoore@sdnp5.ucsd.edu
To: XEmacs Beta Mailing List <xemacs-beta@xemacs.org>
Subject: more auto-save annoyances & patch
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.106)
Content-Type: multipart/mixed;
 boundary="Multipart_Tue_Mar_25_11:53:17_1997-1"
Content-Transfer-Encoding: 7bit
From: David Moore <dmoore@ucsd.edu>
Date: 25 Mar 1997 11:53:17 -0800
Message-ID: <rvwwqv4uky.fsf@sdnp5.ucsd.edu>
Lines: 118
X-Mailer: Gnus v5.4.36/XEmacs 19.15(beta104)

--Multipart_Tue_Mar_25_11:53:17_1997-1
Content-Type: text/plain; charset=US-ASCII

>Here's the trace.  I get it by exiting xemacs (C-x C-c).  My shell
>prompt doesn't come back (xemacs doesn't exit)  I give it a C-c and
>whamo, core.  I build it with no debug so all I've got is gdb
>backtrace.
>
>(gdb) bt
>#0  0xab4d8 in execute_command_event ()
>#1  0xabeec in Fdispatch_event ()
>#2  0x7abf0 in Fcommand_loop_1 ()
>#3  0x7aa14 in command_loop_1 ()
>#4  0x98188 in condition_case_1 ()
>#5  0x7aef0 in command_loop_2 ()
>#6  0x97ecc in internal_catch ()
>#7  0x7a618 in initial_command_loop ()
>#8  0x9496c in main_1 ()
>#9  0x950dc in main ()

This core trace was found in an XEmacs that had previously gotten a
max-eval-lisp-depth overflow due to recursive efs file handlers.

I have also had some similar affects recently.  And I think I may have
just figured out why.  I have to do some things right now, so someone
else might want to look at this before tonight. [1]

I think what's happening is that in the process of auto-saving before
quitting `error' is being signaled.  So the system happily unwinds the
lisp stack back to the previous condition case, which turns out to be
the main command loop!  And then it blissfully continues onward.  This
may also explain some situations where you'd quit XEmacs and it'd close
all of the windows but sit around on the server eating more and more cpu
time.

It might be best to simply slap condition-cases around all of the calls
in Fdo_auto_save which might cause handlers to run.  And if one of them
signals an error just skip that damn buffer.

Problem calls in Fdo_auto_save are:
Fexpand_file_name
auto_save_1 (which is already wrapped)

Also note that it's illegal to make auto-save-list-file-name be on a
remote system (via efs or similar), since we just 'open' it and 'write'
to it.  Maybe the documention should say that.


[1] Oh nevermind, here's the patch:


--Multipart_Tue_Mar_25_11:53:17_1997-1
Content-Type: application/octet-stream; type=patch
Content-Disposition: attachment; filename="autosave.diff"
Content-Transfer-Encoding: 7bit

--- ChangeLog.orig	Tue Mar 25 11:47:48 1997
+++ ChangeLog	Tue Mar 25 11:45:21 1997
@@ -0,0 +1,7 @@
+Tue Mar 25 11:36:08 1997  David Moore  <dmoore@ucsd.edu>
+
+	* fileio.c (auto_save_expand_name_error): New function.
+	(auto_save_expand_name): Ditto.
+	(Fdo_auto_save): Protect against an error in Fexpand_file_name
+	from kicking us inappropriately out of auto-save.
+
--- fileio.c.orig	Tue Mar 25 11:45:44 1997
+++ fileio.c	Tue Mar 25 11:45:27 1997
@@ -4196,6 +4196,26 @@
     Fwrite_region_internal (Qnil, Qnil, a, Qnil, Qlambda, Qnil);
 }
 
+static Lisp_Object
+auto_save_expand_name_error (Lisp_Object condition_object, Lisp_Object ignored)
+{
+  /* #### this function should spew an error message about not being
+     able to open the .saves file. */
+  return Qnil;
+}
+
+static Lisp_Object
+auto_save_expand_name (Lisp_Object name)
+{
+  struct gcpro gcpro1;
+
+  /* note that caller did NOT gc protect name, so we do it. */
+  /* #### dmoore - this might not be neccessary, if condition_case_1
+     protects it.  but I don't think it does. */
+  GCPRO1 (name);
+  RETURN_UNGCPRO (Fexpand_file_name (name, Qnil));
+}
+
 
 static Lisp_Object
 do_auto_save_unwind (Lisp_Object fd)
@@ -4262,7 +4282,10 @@
   run_hook (Qauto_save_hook);
 
   if (GC_STRINGP (Vauto_save_list_file_name))
-    listfile = Fexpand_file_name (Vauto_save_list_file_name, Qnil);
+    listfile = condition_case_1 (Qt,
+				 auto_save_expand_name,
+				 Vauto_save_list_file_name,
+				 auto_save_expand_name_error, Qnil);
 
   /* Make sure auto_saving is reset. */
   record_unwind_protect (do_auto_save_unwind_2, make_int (auto_saving));

--Multipart_Tue_Mar_25_11:53:17_1997-1
Content-Type: text/plain; charset=US-ASCII

--
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_Tue_Mar_25_11:53:17_1997-1--

