core dump in bootstrap-emacs

core dump in bootstrap-emacs

[Giorgos Keramidas]

Hi all,

I've been having 'make bootstrap' problems with versions of CVS
recently.

The last version I can successfully bootstrap is:

  changeset:   80041:df347cacb5a9
  user:        gm
  date:        Mon Mar 19 20:59:53 2007 +0000
  summary:     Change form of license text to match rest of Emacs.

I haven't been able to track down which particular change is the
one for which the problem started happening, but several versions
from HEAD, including the latest one I have pulled out of CVS and
into my Mercurial workspace:

  changeset:   80096:22cf3bca1ad2
  tag:         tip
  user:        gm
  date:        Wed Mar 21 07:13:06 2007 +0000
  summary:     *** empty log message ***

throw a core dump about half-way through the build, when
gnus-delay.el is compiled:

2007-03-21 11:15:23.191763 - checking build system type... i386-unknown-freebsd7.0
[...]
2007-03-21 11:20:35.558390 - Compiling /home/keramida/tmp/emacs-src/lisp/./gnus/gnus-cite.el
2007-03-21 11:20:37.325671 - Wrote /home/keramida/tmp/emacs-src/lisp/gnus/gnus-cite.elc
2007-03-21 11:20:37.337100 - Compiling /home/keramida/tmp/emacs-src/lisp/./gnus/gnus-cus.el
2007-03-21 11:20:39.207570 - Wrote /home/keramida/tmp/emacs-src/lisp/gnus/gnus-cus.elc
2007-03-21 11:20:39.219345 - Compiling /home/keramida/tmp/emacs-src/lisp/./gnus/gnus-delay.el
2007-03-21 11:20:41.046348 - Fatal error (11)Segmentation fault (core dumped)
2007-03-21 11:20:41.085871 - *** Error code 1
2007-03-21 11:20:41.086155 - 
2007-03-21 11:20:41.086395 - Stop in /home/keramida/tmp/emacs-src/lisp.
2007-03-21 11:20:41.086881 - *** Error code 1
2007-03-21 11:20:41.087886 - 
2007-03-21 11:20:41.088409 - Stop in /home/keramida/tmp/emacs-src.
2007-03-21 11:20:41.088631 - *** Error code 1
2007-03-21 11:20:41.088869 - 
2007-03-21 11:20:41.089023 - Stop in /home/keramida/tmp/emacs-src.

Repeated builds of the same source tree *always* throw a core
dump when gnus-delay.el is compiled, but there are no changes to
lisp/gnus/ between the last version I can successfully bootstrap
and this one.

A backtrace of bootstrap-emacs when this happens is attached
below.  I still have the build tree and the core dump around, and
I can keep it as long as necessary.

Any ideas how to proceed in tracking down why bootstrap-emacs
dumps core here?

------------------------------------------------------------------------
Script started on Wed Mar 21 13:23:03 2007
keramida@kobe:/home/keramida/tmp/emacs-src$ cd src
keramida@kobe:/home/keramida/tmp/emacs-src/src$ gdb bootstrap-emacs ../lisp/bootstrap-emacs.core
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-marcel-freebsd"...No symbol table is loaded.  Use the "file" command.

Core was generated by `bootstrap-emacs'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/X11R6/lib/libXaw3d.so.8...done.
Loaded symbols for /usr/X11R6/lib/libXaw3d.so.8
Reading symbols from /usr/X11R6/lib/libXmu.so.6...done.
Loaded symbols for /usr/X11R6/lib/libXmu.so.6
Reading symbols from /usr/X11R6/lib/libXt.so.6...done.
Loaded symbols for /usr/X11R6/lib/libXt.so.6
Reading symbols from /usr/X11R6/lib/libSM.so.6...done.
Loaded symbols for /usr/X11R6/lib/libSM.so.6
Reading symbols from /usr/X11R6/lib/libICE.so.6...done.
Loaded symbols for /usr/X11R6/lib/libICE.so.6
Reading symbols from /usr/X11R6/lib/libXext.so.6...done.
Loaded symbols for /usr/X11R6/lib/libXext.so.6
Reading symbols from /usr/local/lib/libtiff.so.4...done.
Loaded symbols for /usr/local/lib/libtiff.so.4
Reading symbols from /usr/local/lib/libjpeg.so.9...done.
Loaded symbols for /usr/local/lib/libjpeg.so.9
Reading symbols from /usr/local/lib/libpng.so.5...done.
Loaded symbols for /usr/local/lib/libpng.so.5
Reading symbols from /lib/libz.so.3...done.
Loaded symbols for /lib/libz.so.3
Reading symbols from /lib/libm.so.4...done.
Loaded symbols for /lib/libm.so.4
Reading symbols from /usr/local/lib/libungif.so.5...done.
Loaded symbols for /usr/local/lib/libungif.so.5
Reading symbols from /usr/X11R6/lib/libXpm.so.4...done.
Loaded symbols for /usr/X11R6/lib/libXpm.so.4
Reading symbols from /usr/X11R6/lib/libX11.so.6...done.
Loaded symbols for /usr/X11R6/lib/libX11.so.6
Reading symbols from /lib/libutil.so.6...done.
Loaded symbols for /lib/libutil.so.6
Reading symbols from /lib/libncurses.so.6...done.
Loaded symbols for /lib/libncurses.so.6
Reading symbols from /lib/libc.so.7...done.
Loaded symbols for /lib/libc.so.7
Reading symbols from /usr/X11R6/lib/libXp.so.6...done.
Loaded symbols for /usr/X11R6/lib/libXp.so.6
Reading symbols from /libexec/ld-elf.so.1...done.
Loaded symbols for /libexec/ld-elf.so.1
#0  0x2855a8a3 in kill () at kill.S:2

warning: Source file is more recent than executable.

2	RSYSCALL(kill)
Current language:  auto; currently asm
Environment variable "DISPLAY" not defined.
TERM = vt220
Breakpoint 1 at 0x80e11b6: file emacs.c, line 431.
Breakpoint 2 at 0x80f8cf9: file sysdep.c, line 1385.
(gdb) bt
#0  0x2855a8a3 in kill () at kill.S:2
#1  0x080e19ad in fatal_error_signal (sig=-1078045488) at emacs.c:397
#2  0xbfbfffb4 in ?? ()
#3  0x0000000b in ?? ()
#4  0x00000001 in ?? ()
#5  0xbfbe5520 in ?? ()
#6  0x000000ec in ?? ()
#7  0x080e18e8 in Fkill_emacs () at emacs.c:2053
#8  0x0812ef48 in mark_stack () at alloc.c:4325
#9  0x0812f337 in Fgarbage_collect () at alloc.c:5178
#10 0x081414f5 in Feval (form=137690981) at eval.c:2220
#11 0x08141a04 in Fprogn (args=0) at eval.c:447
#12 0x08141c35 in funcall_lambda (fun=137689096, nargs=3, arg_vector=0xbfbe5b94) at eval.c:3177
#13 0x08141faa in Ffuncall (nargs=4, args=0x834f80d) at eval.c:3054
#14 0x081433d4 in Fapply (nargs=2, args=0xbfbe5c20) at eval.c:2485
#15 0x08143511 in apply1 (fn=137689101, arg=138110485) at eval.c:2749
#16 0x0814161d in Feval (form=137689109) at eval.c:2386
#17 0x08141a04 in Fprogn (args=0) at eval.c:447
#18 0x08143b8f in FletX (args=138076973) at eval.c:1008
#19 0x081417f3 in Feval (form=137073228) at eval.c:2275
#20 0x08143d1f in For (args=0) at eval.c:343
#21 0x081417f3 in Feval (form=137073660) at eval.c:2275
#22 0x08141a04 in Fprogn (args=0) at eval.c:447
#23 0x08141c35 in funcall_lambda (fun=138108992, nargs=2, arg_vector=0xbfbe5fb0) at eval.c:3177
#24 0x08141d36 in apply_lambda (fun=138108997, args=1, eval_flag=1) at eval.c:3108
#25 0x08141522 in Feval (form=138108997) at eval.c:2388
#26 0x081439b9 in Flet (args=138109125) at eval.c:1048
#27 0x081417f3 in Feval (form=137073204) at eval.c:2275
#28 0x08141a04 in Fprogn (args=0) at eval.c:447
#29 0x08141c35 in funcall_lambda (fun=138109240, nargs=2, arg_vector=0xbfbe6334) at eval.c:3177
#30 0x08141faa in Ffuncall (nargs=3, args=0x83b613d) at eval.c:3054
#31 0x08142220 in call2 (fn=137617889, arg1=150548435, arg2=539640) at eval.c:2804
#32 0x0810eb90 in Finsert_file_contents (filename=150548435, visit=137353217, beg=0, end=539640, replace=137353217)
    at fileio.c:4577
#33 0x081416e8 in Feval (form=135940632) at eval.c:2356
#34 0x081419e3 in Fprogn (args=0) at eval.c:447
#35 0x08143a6b in Flet (args=137987341) at eval.c:1064
#36 0x081417f3 in Feval (form=137073204) at eval.c:2275
#37 0x08141a04 in Fprogn (args=0) at eval.c:447
#38 0x0813848e in Fsave_current_buffer (args=150688021) at editfns.c:1016
#39 0x081417f3 in Feval (form=137072196) at eval.c:2275
#40 0x08141626 in Feval (form=137822397) at eval.c:2386
#41 0x081419e3 in Fprogn (args=0) at eval.c:447
#42 0x08143a6b in Flet (args=137987301) at eval.c:1064
#43 0x081417f3 in Feval (form=137073204) at eval.c:2275
#44 0x0814262e in Funwind_protect (args=137987677) at eval.c:1324
#45 0x081417f3 in Feval (form=137073084) at eval.c:2275
#46 0x081419e3 in Fprogn (args=0) at eval.c:447
#47 0x08143b8f in FletX (args=137989061) at eval.c:1008
#48 0x081417f3 in Feval (form=137073228) at eval.c:2275
#49 0x081419e3 in Fprogn (args=0) at eval.c:447
#50 0x08143c91 in Fif (args=137988701) at eval.c:396
#51 0x081417f3 in Feval (form=137073612) at eval.c:2275
#52 0x08141a04 in Fprogn (args=0) at eval.c:447
#53 0x08141c35 in funcall_lambda (fun=137987960, nargs=4, arg_vector=0xbfbfb3e4) at eval.c:3177
#54 0x08141faa in Ffuncall (nargs=5, args=0x839877d) at eval.c:3054
#55 0x081421e8 in call4 (fn=137515993, arg1=150544467, arg2=150544467, arg3=137353217, arg4=137353265) at eval.c:2851
#56 0x08159743 in Fload (file=147743603, noerror=137353217, nomessage=137353265, nosuffix=137353217, 
    must_suffix=137353265) at lread.c:963
#57 0x0814c3a1 in Frequire (feature=147756729, filename=137353217, noerror=137353217) at fns.c:3588
#58 0x08141723 in Feval (form=137074832) at eval.c:2328
#59 0x081588ea in readevalloop (readcharfun=145659396, stream=0x0, sourcename=147668115, evalfun=0x81412ac <Feval>, 
    printflag=0, unibyte=137353217, readfun=137353217, start=137353217, end=137353217) at lread.c:1543
#60 0x08158f55 in Feval_buffer (buffer=0, printflag=137353217, filename=147639043, unibyte=137353217, 
    do_allow_print=137353265) at lread.c:1606
#61 0x081416e8 in Feval (form=137077128) at eval.c:2356
#62 0x08141a04 in Fprogn (args=0) at eval.c:447
#63 0x08143a6b in Flet (args=137987301) at eval.c:1064
#64 0x081417f3 in Feval (form=137073204) at eval.c:2275
#65 0x0814262e in Funwind_protect (args=137987677) at eval.c:1324
#66 0x081417f3 in Feval (form=137073084) at eval.c:2275
#67 0x081419e3 in Fprogn (args=0) at eval.c:447
#68 0x08143b8f in FletX (args=137989061) at eval.c:1008
#69 0x081417f3 in Feval (form=137073228) at eval.c:2275
#70 0x081419e3 in Fprogn (args=0) at eval.c:447
#71 0x08143c91 in Fif (args=137988701) at eval.c:396
#72 0x081417f3 in Feval (form=137073612) at eval.c:2275
#73 0x08141a04 in Fprogn (args=0) at eval.c:447
#74 0x08141c35 in funcall_lambda (fun=137987960, nargs=4, arg_vector=0xbfbfbff4) at eval.c:3177
#75 0x08141faa in Ffuncall (nargs=5, args=0x839877d) at eval.c:3054
#76 0x081421e8 in call4 (fn=137515993, arg1=147639043, arg2=147639043, arg3=137353217, arg4=137353265) at eval.c:2851
#77 0x08159743 in Fload (file=147585299, noerror=137353217, nomessage=137353265, nosuffix=137353217, 
    must_suffix=137353265) at lread.c:963
#78 0x0814c3a1 in Frequire (feature=147583937, filename=137353217, noerror=137353217) at fns.c:3588
#79 0x081420d7 in Ffuncall (nargs=2, args=0x82b9890) at eval.c:3000
#80 0x081434d1 in Fapply (nargs=2, args=0xbfbfc514) at eval.c:2485
#81 0x0814218b in Ffuncall (nargs=3, args=0x82b912c) at eval.c:2978
#82 0x0816a019 in Fbyte_code (bytestr=0, vector=-1077951216, maxdepth=2) at bytecode.c:679
#83 0x08141b7f in funcall_lambda (fun=145633348, nargs=1, arg_vector=0xbfbfc644) at eval.c:3184
#84 0x08141faa in Ffuncall (nargs=2, args=0x8ae3044) at eval.c:3054
#85 0x0816a019 in Fbyte_code (bytestr=0, vector=-1077950912, maxdepth=1) at bytecode.c:679
#86 0x08141b7f in funcall_lambda (fun=145634244, nargs=1, arg_vector=0xbfbfc774) at eval.c:3184
#87 0x08141faa in Ffuncall (nargs=2, args=0x8ae33c4) at eval.c:3054
#88 0x0816a019 in Fbyte_code (bytestr=0, vector=-1077950608, maxdepth=1) at bytecode.c:679
#89 0x08141b7f in funcall_lambda (fun=145635620, nargs=0, arg_vector=0xbfbfc8b4) at eval.c:3184
#90 0x08141faa in Ffuncall (nargs=1, args=0x8ae3924) at eval.c:3054
#91 0x081417e3 in Feval (form=137072816) at eval.c:2328
#92 0x081437c7 in internal_lisp_condition_case (var=145589849, bodyform=145601349, handlers=145600325) at eval.c:1426
#93 0x0816a40e in Fbyte_code (bytestr=0, vector=-1077949904, maxdepth=143) at bytecode.c:869
#94 0x08141b7f in funcall_lambda (fun=145635428, nargs=2, arg_vector=0xbfbfcb94) at eval.c:3184
#95 0x08141faa in Ffuncall (nargs=3, args=0x8ae3864) at eval.c:3054
#96 0x0816a019 in Fbyte_code (bytestr=0, vector=-1077949552, maxdepth=2) at bytecode.c:679
#97 0x08141b7f in funcall_lambda (fun=145636100, nargs=1, arg_vector=0xbfbfcc70) at eval.c:3184
#98 0x08141d36 in apply_lambda (fun=145636100, args=1, eval_flag=1) at eval.c:3108
#99 0x08141522 in Feval (form=145636100) at eval.c:2388
#100 0x081437c7 in internal_lisp_condition_case (var=137879961, bodyform=141559829, handlers=141480189) at eval.c:1426
#101 0x0816a40e in Fbyte_code (bytestr=0, vector=-1077948832, maxdepth=143) at bytecode.c:869
#102 0x08141b7f in funcall_lambda (fun=145052836, nargs=1, arg_vector=0xbfbfcf94) at eval.c:3184
#103 0x08141faa in Ffuncall (nargs=2, args=0x8a554a4) at eval.c:3054
#104 0x0816a019 in Fbyte_code (bytestr=0, vector=-1077948528, maxdepth=1) at bytecode.c:679
#105 0x08141b7f in funcall_lambda (fun=145053124, nargs=1, arg_vector=0xbfbfd0d4) at eval.c:3184
#106 0x08141faa in Ffuncall (nargs=2, args=0x8a555c4) at eval.c:3054
#107 0x0816a019 in Fbyte_code (bytestr=0, vector=-1077948208, maxdepth=1) at bytecode.c:679
#108 0x08141b7f in funcall_lambda (fun=145053284, nargs=0, arg_vector=0xbfbfd204) at eval.c:3184
#109 0x08141faa in Ffuncall (nargs=1, args=0x8a55664) at eval.c:3054
#110 0x081417e3 in Feval (form=137072816) at eval.c:2328
#111 0x081419e3 in Fprogn (args=0) at eval.c:447
#112 0x08143c91 in Fif (args=144506085) at eval.c:396
#113 0x081417f3 in Feval (form=137073612) at eval.c:2275
#114 0x08141a04 in Fprogn (args=0) at eval.c:447
#115 0x08143c26 in Fcond (args=144506149) at eval.c:424
#116 0x081417f3 in Feval (form=137073588) at eval.c:2275
#117 0x081419e3 in Fprogn (args=0) at eval.c:447
#118 0x08143b8f in FletX (args=144508813) at eval.c:1008
#119 0x081417f3 in Feval (form=137073228) at eval.c:2275
#120 0x081419e3 in Fprogn (args=0) at eval.c:447
#121 0x08143875 in Fwhile (args=144503693) at eval.c:1086
#122 0x081417f3 in Feval (form=137073180) at eval.c:2275
#123 0x08141a04 in Fprogn (args=0) at eval.c:447
#124 0x08143a6b in Flet (args=144508533) at eval.c:1064
#125 0x081417f3 in Feval (form=137073204) at eval.c:2275
#126 0x081419e3 in Fprogn (args=0) at eval.c:447
#127 0x081417f3 in Feval (form=137073564) at eval.c:2275
#128 0x08143c70 in Fif (args=145496901) at eval.c:395
#129 0x081417f3 in Feval (form=137073612) at eval.c:2275
#130 0x08141626 in Feval (form=137689109) at eval.c:2386
#131 0x08141a04 in Fprogn (args=0) at eval.c:447
#132 0x08141c35 in funcall_lambda (fun=144543488, nargs=1, arg_vector=0xbfbfdc40) at eval.c:3177
#133 0x08141d36 in apply_lambda (fun=144543493, args=1, eval_flag=1) at eval.c:3108
#134 0x08141522 in Feval (form=144543493) at eval.c:2388
#135 0x081419e3 in Fprogn (args=0) at eval.c:447
#136 0x08141c35 in funcall_lambda (fun=144480464, nargs=0, arg_vector=0xbfbfde00) at eval.c:3177
#137 0x08141d36 in apply_lambda (fun=144480469, args=1, eval_flag=1) at eval.c:3108
#138 0x08141522 in Feval (form=144480469) at eval.c:2388
#139 0x0814262e in Funwind_protect (args=144463197) at eval.c:1324
#140 0x081417f3 in Feval (form=137073084) at eval.c:2275
#141 0x081419e3 in Fprogn (args=0) at eval.c:447
#142 0x08143a6b in Flet (args=144463173) at eval.c:1064
#143 0x081417f3 in Feval (form=137073204) at eval.c:2275
#144 0x08141a04 in Fprogn (args=0) at eval.c:447
#145 0x08143c91 in Fif (args=144463933) at eval.c:396
#146 0x081417f3 in Feval (form=137073612) at eval.c:2275
#147 0x081419e3 in Fprogn (args=0) at eval.c:447
#148 0x08141c35 in funcall_lambda (fun=144462752, nargs=0, arg_vector=0xbfbfe320) at eval.c:3177
#149 0x08141d36 in apply_lambda (fun=144462757, args=1, eval_flag=1) at eval.c:3108
#150 0x08141522 in Feval (form=144462757) at eval.c:2388
#151 0x080e34a1 in top_level_2 () at keyboard.c:1338
#152 0x081404fe in internal_condition_case (bfun=0x80e3490 <top_level_2>, handlers=137466481, 
    hfun=0x80e88f8 <cmd_error>) at eval.c:1481
#153 0x080e34cd in top_level_1 () at keyboard.c:1346
#154 0x08140225 in internal_catch (tag=0, func=0x80e34a4 <top_level_1>, arg=137353217) at eval.c:1222
#155 0x080e32a3 in command_loop () at keyboard.c:1303
#156 0x080e335c in recursive_edit_1 () at keyboard.c:1006
#157 0x080e3426 in Frecursive_edit () at keyboard.c:1067
#158 0x080e28ae in main (argc=7, argv=0xbfbfe708) at emacs.c:1761

Lisp Backtrace:
0x834f80d Lisp type 5
"when" (0x83b6615)
"let*" (0x83ae32d)
"or" (0x83ae12d)
"find-auto-coding" (0x8f92fd3)
"let" (0x83b60c5)
"set-auto-coding" (0x8f92fd3)
"insert-file-contents" (0x8f92053)
"let" (0x839850d)
"save-current-buffer" (0x8fb5115)
"with-current-buffer" (0x83984f5)
"let" (0x83984e5)
"unwind-protect" (0x839865d)
"let*" (0x8398bc5)
"if" (0x8398a5d)
"load-with-code-conversion" (0x8f92053)
"require" (0x8ce96b9)
"eval-buffer" (0x8ae9604)
"let" (0x83984e5)
"unwind-protect" (0x839865d)
"let*" (0x8398bc5)
"if" (0x8398a5d)
"load-with-code-conversion" (0x8cccb03)
"require" (0x8cbf3c1)
"apply" (0x831fdc9)
"byte-compile-file-form-require" (0x8c505b5)
"byte-compile-file-form" (0x8c505b5)
0x8ae3924 PVEC_COMPILED
"funcall" (0x8ae3924)
"byte-compile-from-buffer" (0x82fc804)
"byte-compile-file" (0x8a9c713)
"batch-byte-compile-file" (0x8a9c713)
"batch-byte-compile" (0x82fd831)
"batch-byte-compile-if-not-done" (0x82b90b0)
"funcall" (0x8513c01)
"if" (0x89cfce5)
"cond" (0x89d03c5)
"let*" (0x89d078d)
"while" (0x89d072d)
"let" (0x89d0675)
"progn" (0x8ac1b2d)
"if" (0x8ac1b45)
"when" (0x89d0475)
"command-line-1" (0x8aa4545)
"command-line" (0x82fd801)
"unwind-protect" (0x89c555d)
"let" (0x89c5545)
"if" (0x89c583d)
"normal-top-level" (0x82fd801)
(gdb) \a\aq
keramida@kobe:/home/keramida/tmp/emacs-src/src$ exit
exit

Script done on Wed Mar 21 13:25:04 2007
------------------------------------------------------------------------

Re: core dump in bootstrap-emacs

[Chong Yidong]

Giorgos Keramidas <keramida@ceid.upatras.gr> writes:

> I've been having 'make bootstrap' problems with versions of CVS
> recently.
>
> Any ideas how to proceed in tracking down why bootstrap-emacs
> dumps core here?

Works for me with latest CVS, i686-pc-linux-gnu, GTK+ Version 2.10.6
of 2007-03-21.  Maybe someone could help if you provided your build
platform and the rest of the information included in M-x
report-emacs-bug.

Re: core dump in bootstrap-emacs

[Giorgos Keramidas]

On 2007-03-21 11:54, Chong Yidong <cyd@stupidchicken.com> wrote:
>Giorgos Keramidas <keramida@ceid.upatras.gr> writes:
>> I've been having 'make bootstrap' problems with versions of CVS
>> recently.
>>
>> Any ideas how to proceed in tracking down why bootstrap-emacs
>> dumps core here?
> 
> Works for me with latest CVS, i686-pc-linux-gnu, GTK+ Version 2.10.6
> of 2007-03-21.  Maybe someone could help if you provided your build
> platform and the rest of the information included in M-x
> report-emacs-bug.

Right, sorry for not sending this earlier...

The text of M-x report-emacs-bug from the latest snapshot I can
bootstrap and install successfully is:

--text follows this line--

Please write in English if possible, because the Emacs maintainers
usually do not have translators to read other languages for them.

Your bug report will be posted to the emacs-pretest-bug@gnu.org mailing list.

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:



If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
    `bt full' and `xbacktrace'.
If you would like to further debug the crash, please read the file
/opt/emacs/share/emacs/22.0.95/etc/DEBUG for instructions.


In GNU Emacs 22.0.95.2 (i386-unknown-freebsd7.0, X toolkit, Xaw3d scroll bars)
 of 2007-03-21 on kobe
configured using `configure  '--prefix=/opt/emacs' '--with-x' '--with-x-toolkit=lucid' '--with-xpm' '--with-jpeg' '--with-tiff' '--with-gif' '--with-png''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: el_GR.ISO8859-7
  value of $LC_CTYPE: el_GR.ISO8859-7
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: C
  locale-coding-system: greek-iso-8bit
  default-enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
  encoded-kbd-mode: t
  file-name-shadow-mode: t
  unify-8859-on-encoding-mode: t
  utf-translate-cjk-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t

Recent input:
ESC x r e p o TAB TAB r t - e m TAB RET

Recent messages:
Loading disp-table...done
Loading encoded-kb...done
Loading edmacro...done
Loading cc-mode...done
Loading hl-line...done
Loading vc...done
For information about the GNU Project and its goals, type <f1> C-p.
Making completion list...
Loading help-mode...done
Loading emacsbug...done

Re: core dump in bootstrap-emacs

[Giorgos Keramidas]

On 2007-03-21 18:08, Giorgos Keramidas <keramida@ceid.upatras.gr> wrote:
> On 2007-03-21 11:54, Chong Yidong <cyd@stupidchicken.com> wrote:
> >Giorgos Keramidas <keramida@ceid.upatras.gr> writes:
> >> I've been having 'make bootstrap' problems with versions of CVS
> >> recently.
> >>
> >> Any ideas how to proceed in tracking down why bootstrap-emacs
> >> dumps core here?
> > 
> > Works for me with latest CVS, i686-pc-linux-gnu, GTK+ Version 2.10.6
> > of 2007-03-21.  Maybe someone could help if you provided your build
> > platform and the rest of the information included in M-x
> > report-emacs-bug.
> 
> Right, sorry for not sending this earlier...

The platform information is:

$ uname -a
FreeBSD kobe 7.0-CURRENT FreeBSD 7.0-CURRENT #0: Thu Mar 15 05:04:56 EET 2007 \
    build@kobe:/home/build/obj/home/build/src/sys/KOBE  i386
$

I'm not using GTK+ for these builds, so if there's anything else I can
send that helps, please let me know...

Re: core dump in bootstrap-emacs

[Giorgos Keramidas]

On 2007-03-21 13:34, Giorgos Keramidas <keramida@ceid.upatras.gr> wrote:
> Hi all,
> I've been having 'make bootstrap' problems with versions of CVS
> recently.

I've managed to build a full version of tonight's CVS head
on FreeBSD 7.0-CURRENT now, but only by setting in my shell's
environment the following variables:

    bash$ export CC='cc'
    bash$ export CXX='c++'
    bash$ export CFLAGS='-ggdb -pipe'
    bash$ export CXXFLAGS='-ggdb -pipe'

I was hoping to catch a backtrace with -ggdb enabled, but
unfortunately removing optimization options from the build
hides the problem :-/

Re: core dump in bootstrap-emacs

[Chong Yidong]

Giorgos Keramidas <keramida@ceid.upatras.gr> writes:

> I'm not using GTK+ for these builds, so if there's anything else I can
> send that helps, please let me know...

The only recent change likely to have caused this problem are those
associated with this src/ChangeLog entry:

2007-03-20  YAMAMOTO Mitsuharu  <mituharu@math.s.chiba-u.ac.jp>

Could you revert these and see if the problem goes away?  If so, could
you find out which subset of these changes causes the problem?

Thanks.

Re: core dump in bootstrap-emacs

[Richard Stallman]

    #7  0x080e18e8 in Fkill_emacs () at emacs.c:2053
    #8  0x0812ef48 in mark_stack () at alloc.c:4325

Why does mark_stack call Fkill_emacs?

Re: core dump in bootstrap-emacs

[Richard Stallman]

    I was hoping to catch a backtrace with -ggdb enabled, but
    unfortunately removing optimization options from the build
    hides the problem :-/

Try compiling some files optimized and others not.
By binary searching, you can determine which file the problem is in.

Re: core dump in bootstrap-emacs

[Giorgos Keramidas]

On 2007-03-21 21:24, Chong Yidong <cyd@stupidchicken.com> wrote:
> Giorgos Keramidas <keramida@ceid.upatras.gr> writes:
> > I'm not using GTK+ for these builds, so if there's anything else I can
> > send that helps, please let me know...
>
> The only recent change likely to have caused this problem are those
> associated with this src/ChangeLog entry:
>
> 2007-03-20  YAMAMOTO Mitsuharu  <mituharu@math.s.chiba-u.ac.jp>
>
> Could you revert these and see if the problem goes away?  If so, could
> you find out which subset of these changes causes the problem?
>
> Thanks.

On 2007-03-22 01:02, Richard Stallman <rms@gnu.org> wrote:
>     #7  0x080e18e8 in Fkill_emacs () at emacs.c:2053
>     #8  0x0812ef48 in mark_stack () at alloc.c:4325
>
> Why does mark_stack call Fkill_emacs?

On 2007-03-22 11:38, Richard Stallman <rms@gnu.org> wrote:
> Try compiling some files optimized and others not.
> By binary searching, you can determine which file the problem is in.

Sorry for dropping the ball on this for so many days.  One of the recent
changes seems to have fixed the crash I was seeing, and I can bootstrap
Emacs again without using debug-only gcc flags.

Thanks for all the help with this, however :-)

Re: core dump in bootstrap-emacs

[Giorgos Keramidas]

On 2007-03-28 13:34, Giorgos Keramidas <keramida@ceid.upatras.gr> wrote:
> Sorry for dropping the ball on this for so many days.  One of the recent
> changes seems to have fixed the crash I was seeing, and I can bootstrap
> Emacs again without using debug-only gcc flags.

FWIW, the last commit I have locally is:

% keramida@kobe:/home/keramida/hg/emacs/gnu$ hg tip
% changeset:   80237:a70f5c6c0095
% tag:         tip
% user:        lektu
% date:        Wed Mar 28 09:16:41 2007 +0000
% summary:     *** empty log message ***
% 
% keramida@kobe:/home/keramida/hg/emacs/gnu$