buffer.c 1.407 badness

unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed

* buffer.c 1.407 badness
@ 2002-12-06  7:57 Bob Halley
  2002-12-07 21:27 ` Richard Stallman
  2002-12-07 21:27 ` Richard Stallman
  0 siblings, 2 replies; 6+ messages in thread
From: Bob Halley @ 2002-12-06  7:57 UTC (permalink / raw)
  Cc: emacs-devel

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: buffer.c 1.407 badness
  2002-12-06  7:57 buffer.c 1.407 badness Bob Halley
@ 2002-12-07 21:27 ` Richard Stallman
  2002-12-07 21:27 ` Richard Stallman
  1 sibling, 0 replies; 6+ messages in thread
From: Richard Stallman @ 2002-12-07 21:27 UTC (permalink / raw)
  Cc: emacs-devel

    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.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: buffer.c 1.407 badness
  2002-12-06  7:57 buffer.c 1.407 badness Bob Halley
  2002-12-07 21:27 ` Richard Stallman
@ 2002-12-07 21:27 ` Richard Stallman
  2002-12-07 22:10   ` Bob Halley
  1 sibling, 1 reply; 6+ messages in thread
From: Richard Stallman @ 2002-12-07 21:27 UTC (permalink / raw)
  Cc: emacs-devel

    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'?

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: buffer.c 1.407 badness
  2002-12-07 21:27 ` Richard Stallman
@ 2002-12-07 22:10   ` Bob Halley
  2002-12-09 20:22     ` Richard Stallman
  0 siblings, 1 reply; 6+ messages in thread
From: Bob Halley @ 2002-12-07 22:10 UTC (permalink / raw)
  Cc: emacs-devel

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: buffer.c 1.407 badness
  2002-12-07 22:10   ` Bob Halley
@ 2002-12-09 20:22     ` Richard Stallman
  2002-12-09 22:29       ` Bob Halley
  0 siblings, 1 reply; 6+ messages in thread
From: Richard Stallman @ 2002-12-09 20:22 UTC (permalink / raw)
  Cc: emacs-devel

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 ----

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: buffer.c 1.407 badness
  2002-12-09 20:22     ` Richard Stallman
@ 2002-12-09 22:29       ` Bob Halley
  0 siblings, 0 replies; 6+ messages in thread
From: Bob Halley @ 2002-12-09 22:29 UTC (permalink / raw)
  Cc: emacs-devel

Richard Stallman <rms@gnu.org> writes:

> Does the patch below fix it?

Yes it does.

Thanks!

/Bob

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2002-12-09 22:29 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-12-06  7:57 buffer.c 1.407 badness Bob Halley
2002-12-07 21:27 ` Richard Stallman
2002-12-07 21:27 ` Richard Stallman
2002-12-07 22:10   ` Bob Halley
2002-12-09 20:22     ` Richard Stallman
2002-12-09 22:29       ` Bob Halley

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).