[xemacs-hg @ 2001-06-18 07:09:50 by ben] --------------------------------------------------------------- DOCUMENTATION FIXES: --------------------------------------------------------------- eval.c: Correct documentation. elhash.c: Doc correction. --------------------------------------------------------------- LISP OBJECT CLEANUP: --------------------------------------------------------------- bytecode.h, buffer.h, casetab.h, chartab.h, console-msw.h, console.h, database.c, device.h, eldap.h, elhash.h, events.h, extents.h, faces.h, file-coding.h, frame.h, glyphs.h, gui-x.h, gui.h, keymap.h, lisp-disunion.h, lisp-union.h, lisp.h, lrecord.h, lstream.h, mule-charset.h, objects.h, opaque.h, postgresql.h, process.h, rangetab.h, specifier.h, toolbar.h, tooltalk.h, ui-gtk.h: Add wrap_* to all objects (it was already there for a few of them) -- an expression to encapsulate a pointer into a Lisp object, rather than the inconvenient XSET*. "wrap" was chosen because "make" as in make_int(), make_char() is not appropriate. (It implies allocation. The issue does not exist for ints and chars because they are not allocated.) Full error checking has been added to these expressions. When used without error checking, non-union build, use of these expressions will incur no loss of efficiency. (In fact, XSET* is now defined in terms of wrap_* in a non-union build.) In a union build, you will also get no loss of efficiency provided that you have a decent optimizing compiler, and a compiler that either understands inlines or automatically inlines those particular functions. (And since people don't normally do their production builds on union, it doesn't matter.) Update the sample Lisp object definition in lrecord.h accordingly. dumper.c: Fix places in dumper that referenced wrap_object to reference its new name, wrap_pointer_1. buffer.c, bufslots.h, conslots.h, console.c, console.h, devslots.h, device.c, device.h, frame.c, frame.h, frameslots.h, window.c, window.h, winslots.h: -- Extract out the Lisp objects of `struct device' into devslots.h, just like for the other structures. -- Extract out the remaining (not copied into the window config) Lisp objects in `struct window' into winslots.h; use different macros (WINDOW_SLOT vs. WINDOW_SAVED_SLOT) to differentiate them. -- Eliminate the `dead' flag of `struct frame', since it duplicates information already available in `framemeths', and fix FRAME_LIVE_P accordingly. (Devices and consoles already work this way.) -- In *slots.h, switch to system where MARKED_SLOT is automatically undef'd at the end of the file. (Follows what winslots.h already does.) -- Update the comments at the beginning of *slots.h to be accurate. -- When making any of the above objects dead, zero it out entirely and reset all Lisp object slots to Qnil. (We were already doing this somewhat, but not consistently.) This (1) Eliminates the possibility of extra objects hanging around that ought to be GC'd, (2) Causes an immediate crash if anyone tries to access a structure in one of these objects, (3) Ensures consistent behavior wrt dead objects. dialog-msw.c: Use internal_object_printer, since this object should not escape. --------------------------------------------------------------- FIXING A CRASH THAT I HIT ONCE (AND A RELATED BAD BEHAVIOR): --------------------------------------------------------------- eval.c: Fix up some comments about the FSF implementation. Fix two nasty bugs: (1) condition_case_unwind frees the conses sitting in the catch->tag slot too quickly, resulting in a crash that I hit. (2) catches need to be unwound one at a time when calling unwind-protect code, rather than all at once at the end; otherwise, incorrect behavior can result. (A comment shows exactly how.) backtrace.h: Improve comment about FSF differences in the handler stack. --------------------------------------------------------------- FIXING A CRASH THAT I REPEATEDLY HIT WHEN USING THE MOUSE WHEEL UNDER MSWINDOWS: --------------------------------------------------------------- Basic idea: My crash is due either to a dead, non-marked, GC-collected frame inside of a window mirror, or a prematurely freed window mirror. We need to mark the Lisp objects inside of window mirrors. Tracking the lifespan of window mirrors and scrollbar instances is extremely hard, and there may well be lurking bugs where such objects are freed too soon. The only safe way to fix these problems (and it fixes both problems at once) is to make both of these structures Lisp objects. lrecord.h, emacs.c, inline.c, scrollbar-gtk.c, scrollbar-msw.c, scrollbar-x.c, scrollbar.c, scrollbar.h, symsinit.h: Make scrollbar instances actual Lisp objects. Mark the window mirrors in them. inline.c needs to know about scrollbar.h now. Record the new type in lrecord.h. Fix up scrollbar-*.c appropriately. Create a hash table in scrollbar-msw.c so that the scrollbar instances stored in scrollbar HWND's are properly GC-protected. Create complex_vars_of_scrollbar_mswindows() to create the hash table at startup, and call it from emacs.c. Don't store the scrollbar instance as a property of the GTK scrollbar, as it's not used and if we did this, we'd have to separately GC-protect it in a hash table, like in MS Windows. lrecord.h, frame.h, frame.c, frameslots.h, redisplay.c, window.c, window.h: Move mark_window_mirror from redisplay.c to window.c. Make window mirrors actual Lisp objects. Tell lrecord.h about them. Change the window mirror member of struct frame from a pointer to a Lisp object, and add XWINDOW_MIRROR in appropriate places. Mark the scrollbar instances in the window mirror. redisplay.c, redisplay.h, alloc.c: Delete mark_redisplay. Don't call mark_redisplay. We now mark frame-specific structures in mark_frame. NOTE: I also deleted an extremely questionable call to update_frame_window_mirrors(). It was extremely questionable before, and now totally impossible, since it will create Lisp objects during redisplay. frame.c: Mark the scrollbar instances, which are now Lisp objects. Call mark_gutter() here, not in mark_redisplay(). gutter.c: Update comments about correct marking. --------------------------------------------------------------- ISSUES BROUGHT UP BY MARTIN: --------------------------------------------------------------- buffer.h: Put back these macros the way Steve T and I think they ought to be. I already explained in a previous changelog entry why I think these macros should be the way I'd defined them. Once again: We fix these macros so they don't care about the type of their lvalues. The non-C-string equivalents of these already function in the same way, and it's correct because it should be OK to pass in a CBufbyte *, a BufByte *, a Char_Binary *, an UChar_Binary *, etc. The whole reason for these different types is to work around errors caused by signed-vs-unsigned non-matching types. Any possible error that might be caught in a DFC macro would also be caught wherever the argument is used elsewhere. So creating multiple macro versions would add no useful error-checking and just further complicate an already complicated area. As for Martin's "ANSI aliasing" bug, XEmacs is not ANSI-aliasing clean and probably never will be. Unless the board agrees to change XEmacs in this way (and we really don't want to go down that road), this is not a bug. sound.h: Undo Martin's type change. signal.c: Fix problem identified by Martin with Linux and g++ due to non-standard declaration of setitimer(). systime.h: Update the docs for "qxe_" to point out why making the encapsulation explicit is always the right way to go. (setitimer() itself serves as an example.) For 21.4: update-elc-2.el: Correct misplaced parentheses, making lisp/mule not get recompiled.

--- a/src/eval.c	Mon Jun 11 07:47:20 2001 +0000
+++ b/src/eval.c	Mon Jun 18 07:10:32 2001 +0000
@@ -1343,10 +1343,7 @@
 static void
 unwind_to_catch (struct catchtag *c, Lisp_Object val)
 {
-#if 0 /* FSFmacs */
-  /* #### */
   REGISTER int last_time;
-#endif
 
   /* Unwind the specbind, catch, and handler stacks back to CATCH
      Before each catch is discarded, unbind all special bindings
@@ -1365,8 +1362,7 @@
   set_poll_suppress_count (catch->poll_suppress_count);
 #endif
 
-#if 0 /* FSFmacs */
-  /* #### FSFmacs has the following loop.  Is it more correct? */
+#if 1
   do
     {
       last_time = catchlist == c;
@@ -1374,21 +1370,40 @@
       /* Unwind the specpdl stack, and then restore the proper set of
          handlers.  */
       unbind_to (catchlist->pdlcount, Qnil);
-      handlerlist = catchlist->handlerlist;
       catchlist = catchlist->next;
 #ifdef ERROR_CHECK_TYPECHECK
       check_error_state_sanity ();
 #endif
     }
   while (! last_time);
-#else /* Actual XEmacs code */
+#else
+  /* Former XEmacs code.  This is definitely not as correct because
+     there may be a number of catches we're unwinding, and a number
+     of unwind-protects in the process.  By not undoing the catches till
+     the end, there may be invalid catches still current. (This would
+     be a particular problem with code like this:
+
+     (catch 'foo
+       (call-some-code-which-does...
+        (catch 'bar
+          (unwind-protect
+              (call-some-code-which-does...
+               (catch 'bar
+                 (call-some-code-which-does...
+                  (throw 'foo nil))))
+            (throw 'bar nil)))))
+
+     This would try to throw to the inner (catch 'bar)!
+
+     --ben
+   */
   /* Unwind the specpdl stack */
   unbind_to (c->pdlcount, Qnil);
   catchlist = c->next;
 #ifdef ERROR_CHECK_TYPECHECK
   check_error_state_sanity ();
 #endif
-#endif
+#endif /* Former code */
 
   gcprolist = c->gcpro;
   backtrace_list = c->backlist;
@@ -1504,6 +1519,9 @@
 static Lisp_Object
 condition_bind_unwind (Lisp_Object loser)
 {
+  /* There is no problem freeing stuff here like there is in
+     condition_case_unwind(), because there are no outside pointers
+     (like the tag below in the catchlist) pointing to the objects. */
   Lisp_Cons *victim;
   /* ((handler-fun . handler-args) ... other handlers) */
   Lisp_Object tem = XCAR (loser);
@@ -1526,17 +1544,32 @@
 static Lisp_Object
 condition_case_unwind (Lisp_Object loser)
 {
-  Lisp_Cons *victim;
-
   /* ((<unbound> . clauses) ... other handlers */
-  victim = XCONS (XCAR (loser));
-  free_cons (victim);
-
-  victim = XCONS (loser);
+  /* NO! Doing this now leaves the tag deleted in a still-active
+     catch.  With the recent changes to unwind_to_catch(), the
+     evil situation might not happen any more; it certainly could
+     happen before because it did.  But it's very precarious to rely
+     on something like this.  #### Instead we should rewrite, adopting
+     the FSF's mechanism with a struct handler instead of
+     Vcondition_handlers; then we have NO Lisp-object structures used
+     to hold all of the values, and there's no possibility either of
+     crashes from freeing objects too quickly, or objects not getting
+     freed and hanging around till the next GC.
+
+     In practice, the extra consing here should not matter because
+     it only happens when we throw past the condition-case, which almost
+     always is the result of an error.  Most of the time, there will be
+     no error, and we will free the objects below in the main function.
+
+     --ben
+
+     DO NOT DO: free_cons (XCAR (loser));
+     */
+
   if (EQ (loser, Vcondition_handlers)) /* may have been rebound to some tail */
-    Vcondition_handlers = victim->cdr;
-
-  free_cons (victim);
+    Vcondition_handlers = XCDR (loser);
+
+  /* DO NOT DO: free_cons (loser); */
   return Qnil;
 }
 
@@ -1599,7 +1632,7 @@
 {
   int speccount = specpdl_depth();
   struct catchtag c;
-  struct gcpro gcpro1;
+  struct gcpro gcpro1, gcpro2, gcpro3;
 
 #if 0 /* FSFmacs */
   c.tag = Qnil;
@@ -1607,9 +1640,18 @@
   /* Do consing now so out-of-memory error happens up front */
   /* (unbound . stuff) is a special condition-case kludge marker
      which is known specially by Fsignal.
-     This is an abomination, but to fix it would require either
+     [[ This is an abomination, but to fix it would require either
      making condition_case cons (a union of the conditions of the clauses)
-     or changing the byte-compiler output (no thanks). */
+     or changing the byte-compiler output (no thanks).]]
+
+     The above comment is clearly wrong.  FSF does not do it this way
+     and did not change the byte-compiler output.  Instead they use a
+     `struct handler' to hold the various values (in place of our
+     Vcondition_handlers) and chain them together, with pointers from
+     the `struct catchtag' to the `struct handler'.  We should perhaps
+     consider moving to something similar, but not before I merge my
+     stderr-proc workspace, which contains changes to these
+     functions. --ben */
   c.tag = noseeum_cons (noseeum_cons (Qunbound, handlers),
 			Vcondition_handlers);
 #endif
@@ -1647,22 +1689,27 @@
   Vcondition_handlers = c.tag;
 #endif
   GCPRO1 (harg);                /* Somebody has to gc-protect */
-
   c.val = ((*bfun) (barg));
-
-  /* The following is *not* true: (ben)
-
-     ungcpro, restoring catchlist and condition_handlers are actually
-     redundant since unbind_to now restores them.  But it looks funny not to
-     have this code here, and it doesn't cost anything, so I'm leaving it.*/
   UNGCPRO;
+
+  /* Once we change `catchlist' below, the stuff in c will not be GCPRO'd. */
+  GCPRO3 (harg, c.val, c.tag);
+
   catchlist = c.next;
 #ifdef ERROR_CHECK_TYPECHECK
   check_error_state_sanity ();
 #endif
+  /* Note: The unbind also resets Vcondition_handlers.  Maybe we should
+     delete this here. */
   Vcondition_handlers = XCDR (c.tag);
-
-  return unbind_to (speccount, c.val);
+  unbind_to (speccount, Qnil);
+
+  UNGCPRO;
+  /* free the conses *after* the unbind, because the unbind will run
+     condition_case_unwind above. */
+  free_cons (XCONS (XCAR (c.tag)));
+  free_cons (XCONS (c.tag));
+  return c.val;
 }
 
 static Lisp_Object
@@ -3603,7 +3650,7 @@
 }
 
 DEFUN ("function-min-args", Ffunction_min_args, 1, 1, 0, /*
-Return the number of arguments a function may be called with.
+Return the minimum number of arguments a function may be called with.
 The function may be any form that can be passed to `funcall',
 any special form, or any macro.
 */
@@ -3613,7 +3660,7 @@
 }
 
 DEFUN ("function-max-args", Ffunction_max_args, 1, 1, 0, /*
-Return the number of arguments a function may be called with.
+Return the maximum number of arguments a function may be called with.
 The function may be any form that can be passed to `funcall',
 any special form, or any macro.
 If the function takes an arbitrary number of arguments or is