readevalloop and GC

readevalloop and GC

[Kyotaro HORIGUCHI]

In readevalloop() in lread.c creates marker object in every turn
of the loop when start is not nil, and the marker is not
GC-protected.

So, it may be freed by GC happened in evalfun (is typically
Feval) called just after.

lread.c:1410
|       if (!NILP (start) && continue_reading_p)
| 	  start = Fpoint_marker ();
|       unbind_to (count1, Qnil);
| 
|       val = (*evalfun) (val);    ;; GC will happen.

This problem was fixed by following patch.

BTW, I have seen the problem on Meadow when doing eval-region in
ps-print.el, but not on emacs.

-- 
Kyotaro HORIGUCHI

====
Index: lread.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/lread.c,v
retrieving revision 1.342
diff -u -2 -r1.342 lread.c
--- lread.c	1 Nov 2005 19:46:16 -0000	1.342
+++ lread.c	13 Nov 2005 17:17:27 -0000
@@ -1317,5 +1317,5 @@
   register Lisp_Object val;
   int count = SPECPDL_INDEX ();
-  struct gcpro gcpro1;
+  struct gcpro gcpro1, gcpro2;
   struct buffer *b = 0;
   int continue_reading_p;
@@ -1333,5 +1333,17 @@
   readchar_backlog = -1;
 
-  GCPRO1 (sourcename);
+  if (! NILP (start))
+    {    
+      if (NUMBERP (start))
+	{
+	  Lisp_Object tmp = start;
+	  start = Fmake_marker ();
+	  Fset_marker (start, tmp, Qnil);
+	}
+      else if (! MARKERP (start))
+	wrong_type_argument (Qinteger_or_marker_p, start);
+    }
+
+  GCPRO2 (sourcename, start);
 
   LOADHIST_ATTACH (sourcename);
@@ -1401,5 +1413,5 @@
 
       if (!NILP (start) && continue_reading_p)
-	start = Fpoint_marker ();
+	set_marker_both (start , Qnil, PT, PT_BYTE);
       unbind_to (count1, Qnil);

Re: readevalloop and GC

[Stefan Monnier]

> In readevalloop() in lread.c creates marker object in every turn
> of the loop when start is not nil, and the marker is not
> GC-protected.

Indeed and neither were `end' and `readfun' GC-protected.  I've installed
a patch to GCPRO them.  Thank you.

> So, it may be freed by GC happened in evalfun (is typically
> Feval) called just after.

Actually, in most configurations nowadays Emacs doesn't use GCPROs any more
but uses conservative stack scanning instead, so the problem is limited to
some particular (hopefully rare) configs.

> This problem was fixed by following patch.

I haven't installed the part of the patch which avoids the repeated creation
of a marker.  Seeing how the build_load_history call at the end
distinguishes ints from markers, I feel like this part of the code is buggy
(or else, lacks comments) anyway and I'll let someone else think about how it
should be fixed.


        Stefan