buffer.c 1.407 badness

buffer.c 1.407 badness

[Bob Halley]

I tried to build from the CVS mainline today, and it failed, with the
bootstrap emacs segfaulting while compiling one of the esh modules
during "make bootstrap".  The stack trace was huge (over a thousand
levels deep), and involved lots of calls in the gc involving object
marking before one of them segfaulted.

Experimentation with selective soure file reversions reveals that the
problem occurs without fail if buffer.c 1.407 is present, and does not
occur if buffer.c 1.406 is used instead.

I have no understanding of the change made to buffer.c and cannot
offer a fix.

I also noticed something else while looking at diffs from alloca.c
1.21 to 1.22.  It's not related to my problem since I'm using GCC 3.2
and thus not using this snippet of code, but other people with older
systems may be.

Note how the first "#ifdef emacs" is changed to "#ifndef emacs" in the
patch below.  This seems like a serious problem to me, especially
since the comment above it in the source says that emacs wants
xmalloc.

@@ -91,12 +90,13 @@
 
    Callers below should use malloc.  */
 
-#ifdef emacs
-#define malloc xmalloc
-#ifdef EMACS_FREE
-#define free EMACS_FREE
-#endif
-#endif
+#  ifndef emacs
+#   undef malloc
+#   define malloc xmalloc
+#   ifdef EMACS_FREE
+#    define free EMACS_FREE
+#   endif
+#  endif
 extern pointer malloc ();
 
 /* Define STACK_DIRECTION if you know the direction of stack

Re: buffer.c 1.407 badness

[Richard Stallman]

    Note how the first "#ifdef emacs" is changed to "#ifndef emacs" in the
    patch below.  This seems like a serious problem to me, especially
    since the comment above it in the source says that emacs wants
    xmalloc.

Thanks.  I was installing an updated master version of alloca.c
and did not notice this conditional had been reversed.

Re: buffer.c 1.407 badness

[Richard Stallman]

    Experimentation with selective soure file reversions reveals that the
    problem occurs without fail if buffer.c 1.407 is present, and does not
    occur if buffer.c 1.406 is used instead.

Can you show us the part of the backtrace that starts at the entry to
GC and runs up the stack towards `main'?

Re: buffer.c 1.407 badness

[Bob Halley]

Richard Stallman <rms@gnu.org> writes:

>     Experimentation with selective soure file reversions reveals that the
>     problem occurs without fail if buffer.c 1.407 is present, and does not
>     occur if buffer.c 1.406 is used instead.
> 
> Can you show us the part of the backtrace that starts at the entry to
> GC and runs up the stack towards `main'?

Sure.  It's still dying for me, though it's dying compiling a
different LISP source file today than it was a few days ago, and it is
dying with SIGABRT not SIGSEGV.  I've CVS updated since then, so that
is not surprising.

It goes right through the changed code in buffer.c just before the
garbage collection it aborts in starts, specifically line 422 of
buffer.c.

  /* Fixme:  Protect against errors, which would trigger infinite
     regress?  */
  if (!NILP (Ffboundp (Qucs_set_table_for_input)))
    /* buff is on buffer-alist, so no gcpro */
    call1 (Qucs_set_table_for_input, buf);		<-- line 422

Here is the full backtrace:

#0  0x42028cc1 in kill () from /lib/i686/libc.so.6
#1  0x080d4178 in fatal_error_signal (sig=16648) at emacs.c:379
#2  <signal handler called>
#3  0x42028cc1 in kill () from /lib/i686/libc.so.6
#4  0x080d41be in abort () at emacs.c:412
#5  0x0811c278 in mark_buffer (buf=0) at alloc.c:4816
#6  0x0811c334 in mark_buffer (buf=0) at alloc.c:4876
#7  0x0811b970 in Fgarbage_collect () at alloc.c:4148
#8  0x0812f248 in Ffuncall (nargs=2, args=0xbfffcbf0) at eval.c:2677
#9  0x0812ee70 in call1 (fn=405473828, arg1=1216469608) at eval.c:2533
#10 0x080eab23 in Fget_buffer_create (name=948031044) at buffer.c:422
#11 0x0812e7ae in Feval (form=135844896) at eval.c:2096
#12 0x0812cd71 in FletX (args=1484955108) at eval.c:891
#13 0x0812e900 in Feval (form=1210511344) at eval.c:2043
#14 0x0812c159 in For (args=0) at eval.c:308
#15 0x0812e900 in Feval (form=1210510936) at eval.c:2043
#16 0x0812c2e5 in Fprogn (args=0) at eval.c:424
#17 0x0812f492 in funcall_lambda (fun=142779420, nargs=4, 
    arg_vector=0xbfffcfd4) at eval.c:2917
#18 0x0812f03b in Ffuncall (nargs=5, args=0xbfffcfd0) at eval.c:2794
#19 0x08156c88 in Fbyte_code (bytestr=410828292, vector=4, 
    maxdepth=-1073754160) at bytecode.c:709
#20 0x0812f453 in funcall_lambda (fun=1216144744, nargs=3, 
    arg_vector=0xbfffd0f4) at eval.c:2924
#21 0x0812f03b in Ffuncall (nargs=4, args=0xbfffd0f0) at eval.c:2794
#22 0x08156c88 in Fbyte_code (bytestr=405630452, vector=3, 
    maxdepth=-1073753872) at bytecode.c:709
#23 0x0812f453 in funcall_lambda (fun=1216144952, nargs=3, 
    arg_vector=0xbfffd204) at eval.c:2924
#24 0x0812f03b in Ffuncall (nargs=4, args=0xbfffd200) at eval.c:2794
#25 0x08156c88 in Fbyte_code (bytestr=410837844, vector=3, 
    maxdepth=-1073753600) at bytecode.c:709
#26 0x0812f453 in funcall_lambda (fun=1216157784, nargs=3, 
    arg_vector=0xbfffd324) at eval.c:2924
#27 0x0812f03b in Ffuncall (nargs=4, args=0xbfffd320) at eval.c:2794
#28 0x08156c88 in Fbyte_code (bytestr=410785964, vector=3, 
    maxdepth=-1073753312) at bytecode.c:709
#29 0x0812f453 in funcall_lambda (fun=1216158016, nargs=0, 
    arg_vector=0xbfffd434) at eval.c:2924
#30 0x0812f03b in Ffuncall (nargs=1, args=0xbfffd430) at eval.c:2794
#31 0x08156c88 in Fbyte_code (bytestr=405846868, vector=0, 
    maxdepth=-1073753040) at bytecode.c:709
#32 0x0812f453 in funcall_lambda (fun=1216166208, nargs=0, 
    arg_vector=0xbfffd554) at eval.c:2924
#33 0x0812f03b in Ffuncall (nargs=1, args=0xbfffd550) at eval.c:2794
#34 0x0812e7ae in Feval (form=136769928) at eval.c:2096
#35 0x0812d558 in Fcondition_case (args=405473468) at eval.c:1296
#36 0x08157895 in Fbyte_code (bytestr=410786180, vector=143, 
    maxdepth=-1073752240) at bytecode.c:891
#37 0x0812f453 in funcall_lambda (fun=1216166616, nargs=2, 
    arg_vector=0xbfffd894) at eval.c:2924
#38 0x0812f03b in Ffuncall (nargs=3, args=0xbfffd890) at eval.c:2794
#39 0x08156c88 in Fbyte_code (bytestr=405989908, vector=2, 
    maxdepth=-1073751920) at bytecode.c:709
#40 0x0812f453 in funcall_lambda (fun=1216164368, nargs=1, 
    arg_vector=0xbfffd950) at eval.c:2924
#41 0x0812f322 in apply_lambda (fun=1216164368, args=947483164, eval_flag=1)
    at eval.c:2846
#42 0x0812e610 in Feval (form=1216164368) at eval.c:2154
#43 0x0812d558 in Fcondition_case (args=405473468) at eval.c:1296
#44 0x08157895 in Fbyte_code (bytestr=142492276, vector=143, 
    maxdepth=-1073751104) at bytecode.c:891
#45 0x0812f453 in funcall_lambda (fun=1216237864, nargs=1, 
    arg_vector=0xbfffdcd4) at eval.c:2924
#46 0x0812f03b in Ffuncall (nargs=2, args=0xbfffdcd0) at eval.c:2794
#47 0x08156c88 in Fbyte_code (bytestr=410172268, vector=1, 
    maxdepth=-1073750832) at bytecode.c:709
#48 0x0812f453 in funcall_lambda (fun=1216237504, nargs=1, 
    arg_vector=0xbfffddf4) at eval.c:2924
#49 0x0812f03b in Ffuncall (nargs=2, args=0xbfffddf0) at eval.c:2794
#50 0x08156c88 in Fbyte_code (bytestr=142492180, vector=1, 
    maxdepth=-1073750544) at bytecode.c:709
#51 0x0812f453 in funcall_lambda (fun=1216237232, nargs=0, 
    arg_vector=0xbfffdf04) at eval.c:2924
#52 0x0812f03b in Ffuncall (nargs=1, args=0xbfffdf00) at eval.c:2794
#53 0x0812e7ae in Feval (form=136769928) at eval.c:2096
#54 0x0812c2e5 in Fprogn (args=0) at eval.c:424
#55 0x0812c241 in Fif (args=1483998868) at eval.c:368
#56 0x0812e900 in Feval (form=1210510984) at eval.c:2043
#57 0x0812c2e5 in Fprogn (args=0) at eval.c:424
#58 0x0812c2b3 in Fcond (args=1483998932) at eval.c:396
#59 0x0812e900 in Feval (form=1210511008) at eval.c:2043
#60 0x0812c2e5 in Fprogn (args=0) at eval.c:424
#61 0x0812cd45 in FletX (args=1483996268) at eval.c:897
#62 0x0812e900 in Feval (form=1210511344) at eval.c:2043
#63 0x0812c2e5 in Fprogn (args=0) at eval.c:424
#64 0x0812cfca in Fwhile (args=1484002588) at eval.c:977
#65 0x0812e900 in Feval (form=1210511392) at eval.c:2043
#66 0x0812c2e5 in Fprogn (args=0) at eval.c:424
#67 0x0812cf07 in Flet (args=1483995940) at eval.c:955
#68 0x0812e900 in Feval (form=1210511368) at eval.c:2043
#69 0x0812c220 in Fif (args=1483995412) at eval.c:367
#70 0x0812e900 in Feval (form=1210510984) at eval.c:2043
#71 0x0812c2e5 in Fprogn (args=0) at eval.c:424
#72 0x0812f492 in funcall_lambda (fun=141826260, nargs=1, 
    arg_vector=0xbfffe760) at eval.c:2917
#73 0x0812f322 in apply_lambda (fun=1484003540, args=1484236620, eval_flag=1)
    at eval.c:2846
#74 0x0812e610 in Feval (form=1484003540) at eval.c:2154
#75 0x0812c2e5 in Fprogn (args=0) at eval.c:424
#76 0x0812f492 in funcall_lambda (fun=141792524, nargs=0, 
    arg_vector=0xbfffe910) at eval.c:2917
#77 0x0812f322 in apply_lambda (fun=1483969804, args=405473468, eval_flag=1)
    at eval.c:2846
#78 0x0812e610 in Feval (form=1483969804) at eval.c:2154
#79 0x0812d357 in Funwind_protect (args=1483949596) at eval.c:1208
#80 0x0812e900 in Feval (form=1210511488) at eval.c:2043
#81 0x0812c2e5 in Fprogn (args=0) at eval.c:424
#82 0x0812cf07 in Flet (args=1483949572) at eval.c:955
#83 0x0812e900 in Feval (form=1210511368) at eval.c:2043
#84 0x0812c2e5 in Fprogn (args=0) at eval.c:424
#85 0x0812c241 in Fif (args=1483947084) at eval.c:368
#86 0x0812e900 in Feval (form=1210510984) at eval.c:2043
#87 0x0812c2e5 in Fprogn (args=0) at eval.c:424
#88 0x0812f492 in funcall_lambda (fun=141773964, nargs=0, 
    arg_vector=0xbfffee10) at eval.c:2917
#89 0x0812f322 in apply_lambda (fun=1483951244, args=405473468, eval_flag=1)
    at eval.c:2846
#90 0x0812e610 in Feval (form=1483951244) at eval.c:2154
#91 0x080d6971 in top_level_2 () at keyboard.c:1283
#92 0x0812d652 in internal_condition_case (bfun=0x80d6960 <top_level_2>, 
    handlers=405570076, hfun=0x80d6668 <cmd_error>) at eval.c:1352
#93 0x080d699d in top_level_1 () at keyboard.c:1291
#94 0x0812d20d in internal_catch (tag=0, func=0x80d6974 <top_level_1>, 
    arg=405473468) at eval.c:1112
#95 0x080d68ef in command_loop () at keyboard.c:1252
#96 0x080d6447 in recursive_edit_1 () at keyboard.c:969
#97 0x080d6554 in Frecursive_edit () at keyboard.c:1025
#98 0x080d4eaf in main (argc=7, argv=0xbffff484) at emacs.c:1647
#99 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6

Re: buffer.c 1.407 badness

[Richard Stallman]

Does the patch below fix it?  It fixes an obvious error.
If it still fails, please examine the data in these frames:

    #5  0x0811c278 in mark_buffer (buf=0) at alloc.c:4816
    #6  0x0811c334 in mark_buffer (buf=0) at alloc.c:4876


*** buffer.c.~1.407.~	Tue Dec  3 10:40:31 2002
--- buffer.c	Sun Dec  8 22:55:47 2002
***************
*** 411,416 ****
--- 411,420 ----
    reset_buffer (b);
    reset_buffer_local_variables (b, 1);
  
+   b->mark = Fmake_marker ();
+   BUF_MARKERS (b) = Qnil;
+   b->name = name;
+ 
    /* Put this in the alist of all live buffers.  */
    XSETBUFFER (buf, b);
    Vbuffer_alist = nconc2 (Vbuffer_alist, Fcons (Fcons (name, buf), Qnil));
***************
*** 421,429 ****
      /* buff is on buffer-alist, so no gcpro */
      call1 (Qucs_set_table_for_input, buf);
  
-   b->mark = Fmake_marker ();
-   BUF_MARKERS (b) = Qnil;
-   b->name = name;
    return buf;
  }
  
--- 425,430 ----

Re: buffer.c 1.407 badness

[Bob Halley]

Richard Stallman <rms@gnu.org> writes:

> Does the patch below fix it?

Yes it does.

Thanks!

/Bob