* bug#17215: Build failure @ 2014-04-07 8:08 David Kastrup 2014-04-07 20:47 ` Glenn Morris [not found] ` <handler.17215.B.139685811224063.ack@debbugs.gnu.org> 0 siblings, 2 replies; 20+ messages in thread From: David Kastrup @ 2014-04-07 8:08 UTC (permalink / raw) To: 17215 I cannot get current master to build. System is Ubuntu 14.04, I am building with ../emacs/configure --without-toolkit-scroll-bars Even after make distclean, cleaning out the build directory completely and then running make after configuring as above, I eventually crash out at Wrote /usr/local/tmp/emacs/lisp/progmodes/cc-mode.elc Compiling ../../emacs/lisp/org/ob-asymptote.el Backtrace: ../src/emacs[0x8138913] ../src/emacs[0x8120061] ../src/emacs[0x8138967] ../src/emacs[0x8178c10] ../src/emacs[0x81c2007] ../src/emacs[0x818d79e] ../src/emacs[0x818da53] ../src/emacs[0x81c07c3] ../src/emacs[0x818d79e] ../src/emacs[0x818cc8c] ../src/emacs[0x818cfa4] ../src/emacs[0x818d4a6] ../src/emacs[0x818c9d7] ../src/emacs[0x81901f5] ../src/emacs[0x818d28e] ../src/emacs[0x818d4a6] ../src/emacs[0x818fdc7] ../src/emacs[0x818d28e] ../src/emacs[0x818d4a6] ../src/emacs[0x818d80f] ../src/emacs[0x818cc8c] ../src/emacs[0x818cfa4] ../src/emacs[0x818d28e] ../src/emacs[0x818fd33] ../src/emacs[0x818d28e] ../src/emacs[0x818d4a6] ../src/emacs[0x818d80f] ../src/emacs[0x818da53] ../src/emacs[0x818ee5b] ../src/emacs[0x818f08f] ../src/emacs[0x818f620] ../src/emacs[0x818dc70] ../src/emacs[0x81c07c3] ../src/emacs[0x818d79e] ../src/emacs[0x818da53] ../src/emacs[0x81c07c3] ../src/emacs[0x818d79e] ../src/emacs[0x818da53] ../src/emacs[0x81c07c3] ../src/emacs[0x818d79e] ../src/emacs[0x818da53] ... make[2]: *** [org/ob-asymptote.elc] Aborted (core dumped) make[2]: Leaving directory `/usr/local/tmp/emacs-build/lisp' make[1]: *** [compile-main] Error 2 make[1]: Leaving directory `/usr/local/tmp/emacs-build/lisp' make: *** [lisp] Error 2 uname -a Linux lola 3.11.0-17-generic #31-Ubuntu SMP Mon Feb 3 21:53:31 UTC 2014 i686 i686 i686 GNU/Linux gcc --version gcc (Ubuntu 4.8.2-17ubuntu2) 4.8.2 Copyright (C) 2013 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Any more information that you need? -- David Kastrup ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#17215: Build failure 2014-04-07 8:08 bug#17215: Build failure David Kastrup @ 2014-04-07 20:47 ` Glenn Morris 2014-04-08 10:42 ` David Kastrup [not found] ` <handler.17215.B.139685811224063.ack@debbugs.gnu.org> 1 sibling, 1 reply; 20+ messages in thread From: Glenn Morris @ 2014-04-07 20:47 UTC (permalink / raw) To: David Kastrup; +Cc: 17215 David Kastrup wrote: > Any more information that you need? Please run addr2line as described in info node `Crashing'. Or get a backtrace from gdb. (But I'm going to guess that this is just http://debbugs.gnu.org/17178 aka 17168 again.) ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#17215: Build failure 2014-04-07 20:47 ` Glenn Morris @ 2014-04-08 10:42 ` David Kastrup 2014-04-08 10:50 ` Daniel Colascione 0 siblings, 1 reply; 20+ messages in thread From: David Kastrup @ 2014-04-08 10:42 UTC (permalink / raw) To: Glenn Morris; +Cc: 17215 Glenn Morris <rgm@gnu.org> writes: > David Kastrup wrote: > >> Any more information that you need? > > Please run addr2line as described in info node `Crashing'. > Or get a backtrace from gdb. > > (But I'm going to guess that this is just > http://debbugs.gnu.org/17178 aka 17168 again.) With regard to relating to the other bug: I reverted the respective part in subr.el of (git commit) commit 099c333d57a88bf1ea2fee992c721225608303c9 Author: Richard Stallman <> Date: Wed Apr 2 13:21:34 2014 -0400 Revert subr.el workaround for GC bug. * subr.el (set-transient-map): Comment out previous change. But "make bootstrap" crashed at the same point, and lisp/subr.elc has a modification date later than lisp/subr.el when the crash occurs. Just to be sure, I cleaned out the build directory and made a "make distclean", then tried again. Same outcome. So at least this "workaround" does not apply to this bug. Here is a backtrace from the corresponding core dump (namely the core dump of master from yesterday, with the revert of Richard's revert on top): #0 0x40022424 in __kernel_vsyscall () #1 0x416b60c6 in raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/pt-raise.c:37 #2 0x08120099 in terminate_due_to_signal (sig=sig@entry=6, backtrace_limit=backtrace_limit@entry=40) at ../../emacs/src/emacs.c:382 #3 0x08138967 in emacs_abort () at ../../emacs/src/sysdep.c:2130 #4 0x08178c10 in Ffset (symbol=140567234, definition=136867149) at ../../emacs/src/data.c:733 #5 0x081c2007 in exec_byte_code (bytestr=0, vector=6, maxdepth=12, args_template=args_template@entry=1028, nargs=nargs@entry=1, args=0xbfd90b98) at ../../emacs/src/bytecode.c:1322 #6 0x0818d79e in funcall_lambda (fun=178833477, nargs=nargs@entry=1, arg_vector=arg_vector@entry=0xbfd90d3c) at ../../emacs/src/eval.c:2983 #7 0x0818da53 in Ffuncall (nargs=2, args=0xbfd90d38) at ../../emacs/src/eval.c:2876 #8 0x081c07c3 in exec_byte_code (bytestr=0, vector=6, maxdepth=44, args_template=args_template@entry=2056, nargs=nargs@entry=2, args=0xbfd90d34) at ../../emacs/src/bytecode.c:919 #9 0x0818d79e in funcall_lambda (fun=fun@entry=137210677, nargs=nargs@entry=2, arg_vector=arg_vector@entry=0xbfd90e70) at ../../emacs/src/eval.c:2983 #10 0x0818cc8c in apply_lambda (fun=<optimized out>, args=<optimized out>) at ../../emacs/src/eval.c:2924 #11 0x0818cfa4 in eval_sub (form=178737886) at ../../emacs/src/eval.c:2260 #12 0x0818d4a6 in Fprogn (body=178737910) at ../../emacs/src/eval.c:468 #13 0x0818c9d7 in unbind_to (count=count@entry=144, value=178826574) at ../../emacs/src/eval.c:3309 #14 0x081901f5 in Funwind_protect (args=178735734) at ../../emacs/src/eval.c:1216 #15 0x0818d28e in eval_sub (form=178735726) at ../../emacs/src/eval.c:2133 #16 0x0818d4a6 in Fprogn (body=178735862) at ../../emacs/src/eval.c:468 #17 0x0818fdc7 in FletX (args=178735870) at ../../emacs/src/eval.c:906 #18 0x0818d28e in eval_sub (form=178735878) at ../../emacs/src/eval.c:2133 #19 0x0818d4a6 in Fprogn (body=178735910) at ../../emacs/src/eval.c:468 #20 0x0818d80f in funcall_lambda (fun=178735958, fun@entry=178735966, nargs=nargs@entry=4, arg_vector=arg_vector@entry=0xbfd911e0) at ../../emacs/src/eval.c:3042 #21 0x0818cc8c in apply_lambda (fun=<optimized out>, args=<optimized out>) at ../../emacs/src/eval.c:2924 #22 0x0818cfa4 in eval_sub (form=178768494) at ../../emacs/src/eval.c:2260 #23 0x0818d28e in eval_sub (form=178768438) at ../../emacs/src/eval.c:2133 #24 0x0818fd33 in FletX (args=178802726) at ../../emacs/src/eval.c:881 #25 0x0818d28e in eval_sub (form=178802734) at ../../emacs/src/eval.c:2133 #26 0x0818d4a6 in Fprogn (body=178802774) at ../../emacs/src/eval.c:468 #27 0x0818d80f in funcall_lambda (fun=178802974, nargs=nargs@entry=4, arg_vector=arg_vector@entry=0xbfd91514) at ../../emacs/src/eval.c:3042 #28 0x0818da53 in Ffuncall (nargs=5, args=args@entry=0xbfd91510) at ../../emacs/src/eval.c:2876 #29 0x0818ee5b in Fapply (nargs=nargs@entry=2, args=args@entry=0xbfd915a8) at ../../emacs/src/eval.c:2354 #30 0x0818f08f in apply1 (fn=178802982, arg=177536782) at ../../emacs/src/eval.c:2588 #31 0x0818f620 in Fmacroexpand (form=<optimized out>, environment=138922946) at ../../emacs/src/eval.c:1066 #32 0x0818dc70 in Ffuncall (nargs=3, args=0xbfd9166c) at ../../emacs/src/eval.c:2818 #33 0x081c07c3 in exec_byte_code (bytestr=0, vector=6, maxdepth=108, args_template=args_template@entry=1028, nargs=nargs@entry=1, args=0xbfd91668) at ../../emacs/src/bytecode.c:919 #34 0x0818d79e in funcall_lambda (fun=137023429, nargs=nargs@entry=1, arg_vector=arg_vector@entry=0xbfd91874) at ../../emacs/src/eval.c:2983 #35 0x0818da53 in Ffuncall (nargs=2, args=0xbfd91870) at ../../emacs/src/eval.c:2876 #36 0x081c07c3 in exec_byte_code (bytestr=0, vector=6, maxdepth=36, args_template=args_template@entry=2052, nargs=nargs@entry=2, args=0xbfd9186c) at ../../emacs/src/bytecode.c:919 #37 0x0818d79e in funcall_lambda (fun=137022557, nargs=nargs@entry=2, arg_vector=arg_vector@entry=0xbfd91a14) at ../../emacs/src/eval.c:2983 #38 0x0818da53 in Ffuncall (nargs=3, args=0xbfd91a10) at ../../emacs/src/eval.c:2876 #39 0x081c07c3 in exec_byte_code (bytestr=0, vector=6, maxdepth=44, args_template=args_template@entry=2056, nargs=nargs@entry=2, args=0xbfd91a0c) at ../../emacs/src/bytecode.c:919 #40 0x0818d79e in funcall_lambda (fun=137023621, nargs=nargs@entry=2, arg_vector=arg_vector@entry=0xbfd91bd4) at ../../emacs/src/eval.c:2983 #41 0x0818da53 in Ffuncall (nargs=3, args=0xbfd91bd0) at ../../emacs/src/eval.c:2876 #42 0x081c07c3 in exec_byte_code (bytestr=0, vector=6, maxdepth=108, args_template=args_template@entry=1028, nargs=nargs@entry=1, args=0xbfd91bb8) at ../../emacs/src/bytecode.c:919 #43 0x0818d79e in funcall_lambda (fun=137023429, nargs=nargs@entry=1, arg_vector=arg_vector@entry=0xbfd91dc4) at ../../emacs/src/eval.c:2983 #44 0x0818da53 in Ffuncall (nargs=2, args=0xbfd91dc0) at ../../emacs/src/eval.c:2876 #45 0x081c07c3 in exec_byte_code (bytestr=0, vector=6, maxdepth=36, args_template=args_template@entry=2052, nargs=nargs@entry=2, args=0xbfd91dbc) at ../../emacs/src/bytecode.c:919 #46 0x0818d79e in funcall_lambda (fun=137022557, nargs=nargs@entry=2, arg_vector=arg_vector@entry=0xbfd91f64) at ../../emacs/src/eval.c:2983 #47 0x0818da53 in Ffuncall (nargs=3, args=0xbfd91f60) at ../../emacs/src/eval.c:2876 #48 0x081c07c3 in exec_byte_code (bytestr=0, vector=6, maxdepth=44, args_template=args_template@entry=2056, nargs=nargs@entry=2, args=0xbfd91f5c) at ../../emacs/src/bytecode.c:919 #49 0x0818d79e in funcall_lambda (fun=137023621, nargs=nargs@entry=2, arg_vector=arg_vector@entry=0xbfd92124) at ../../emacs/src/eval.c:2983 #50 0x0818da53 in Ffuncall (nargs=3, args=0xbfd92120) at ../../emacs/src/eval.c:2876 #51 0x081c07c3 in exec_byte_code (bytestr=0, vector=6, maxdepth=108, args_template=args_template@entry=1028, nargs=nargs@entry=1, args=0xbfd92108) at ../../emacs/src/bytecode.c:919 #52 0x0818d79e in funcall_lambda (fun=137023429, nargs=nargs@entry=1, arg_vector=arg_vector@entry=0xbfd92300) at ../../emacs/src/eval.c:2983 #53 0x0818da53 in Ffuncall (nargs=2, args=0xbfd922fc) at ../../emacs/src/eval.c:2876 #54 0x081c07c3 in exec_byte_code (bytestr=0, vector=6, maxdepth=16, args_template=args_template@entry=2052, nargs=nargs@entry=1, args=0xbfd922f8) at ../../emacs/src/bytecode.c:919 #55 0x0818d79e in funcall_lambda (fun=137024085, nargs=nargs@entry=1, arg_vector=arg_vector@entry=0xbfd92498) at ../../emacs/src/eval.c:2983 #56 0x0818da53 in Ffuncall (nargs=2, args=0xbfd92494) at ../../emacs/src/eval.c:2876 #57 0x081c07c3 in exec_byte_code (bytestr=0, vector=6, maxdepth=8, args_template=args_template@entry=0, nargs=nargs@entry=0, args=0xbfd92490) at ../../emacs/src/bytecode.c:919 #58 0x0818d79e in funcall_lambda (fun=177520389, nargs=nargs@entry=0, arg_vector=arg_vector@entry=0xbfd92634) at ../../emacs/src/eval.c:2983 #59 0x0818da53 in Ffuncall (nargs=1, args=0xbfd92630) at ../../emacs/src/eval.c:2876 #60 0x0818d350 in eval_sub (form=177535262) at ../../emacs/src/eval.c:2157 #61 0x081903eb in internal_lisp_condition_case (var=140664170, bodyform=<optimized out>, handlers=<optimized out>) at ../../emacs/src/eval.c:1323 #62 0x081c1d9d in exec_byte_code (bytestr=0, vector=6, maxdepth=44, args_template=args_template@entry=1028, nargs=nargs@entry=1, args=0xbfd92748) at ../../emacs/src/bytecode.c:1169 #63 0x0818d79e in funcall_lambda (fun=137025397, nargs=nargs@entry=1, arg_vector=arg_vector@entry=0xbfd928fc) at ../../emacs/src/eval.c:2983 #64 0x0818da53 in Ffuncall (nargs=nargs@entry=2, args=args@entry=0xbfd928f8) at ../../emacs/src/eval.c:2876 #65 0x0818dde7 in call1 (fn=fn@entry=139083706, arg1=arg1@entry=177536726) at ../../emacs/src/eval.c:2614 #66 0x081aef73 in readevalloop (readcharfun=readcharfun@entry=176865173, stream=stream@entry=0x0, sourcename=176867369, sourcename@entry=176966881, printflag=false, unibyte=unibyte@entry=138922946, readfun=138922946, start=138922946, end=138922946) at ../../emacs/src/lread.c:1933 #67 0x081b000b in Feval_buffer (buffer=176865173, printflag=138922946, filename=176966881, unibyte=138922946, do_allow_print=138922970) at ../../emacs/src/lread.c:1995 #68 0x0818dc16 in Ffuncall (nargs=6, args=0xbfd92a24) at ../../emacs/src/eval.c:2831 #69 0x081c07c3 in exec_byte_code (bytestr=0, vector=6, maxdepth=24, args_template=138922946, nargs=nargs@entry=0, args=0xbfd92a2c) at ../../emacs/src/bytecode.c:919 #70 0x0818d71d in funcall_lambda (fun=136878341, nargs=nargs@entry=4, arg_vector=arg_vector@entry=0xbfd92bd0) at ../../emacs/src/eval.c:3049 #71 0x0818da53 in Ffuncall (nargs=nargs@entry=5, args=args@entry=0xbfd92bcc) at ../../emacs/src/eval.c:2876 #72 0x0818f6ef in call4 (fn=140760930, arg1=arg1@entry=176966881, arg2=arg2@entry=176966881, arg3=138922946, arg4=138922970) at ../../emacs/src/eval.c:2663 #73 0x081afd85 in Fload (file=176966257, noerror=noerror@entry=138922946, nomessage=138922970, nosuffix=nosuffix@entry=138922946, must_suffix=138922970) at ../../emacs/src/lread.c:1305 #74 0x08199e6e in Frequire (feature=176964874, filename=138922946, noerror=138922946) at ../../emacs/src/fns.c:2671 #75 0x0818d185 in eval_sub (form=form@entry=176939310) at ../../emacs/src/eval.c:2191 #76 0x081aef7d in readevalloop (readcharfun=readcharfun@entry=176849653, stream=stream@entry=0x0, sourcename=176854193, sourcename@entry=176848697, printflag=false, unibyte=unibyte@entry=138922946, readfun=138922946, start=138922946, end=138922946) at ../../emacs/src/lread.c:1934 #77 0x081b000b in Feval_buffer (buffer=176849653, printflag=138922946, filename=176848697, unibyte=138922946, do_allow_print=138922970) at ../../emacs/src/lread.c:1995 #78 0x0818dc16 in Ffuncall (nargs=6, args=0xbfd92ef4) at ../../emacs/src/eval.c:2831 #79 0x081c07c3 in exec_byte_code (bytestr=0, vector=6, maxdepth=24, args_template=138922946, nargs=nargs@entry=0, args=0xbfd92efc) at ../../emacs/src/bytecode.c:919 #80 0x0818d71d in funcall_lambda (fun=136878341, nargs=nargs@entry=4, arg_vector=arg_vector@entry=0xbfd930a0) at ../../emacs/src/eval.c:3049 #81 0x0818da53 in Ffuncall (nargs=nargs@entry=5, args=args@entry=0xbfd9309c) at ../../emacs/src/eval.c:2876 #82 0x0818f6ef in call4 (fn=140760930, arg1=arg1@entry=176848697, arg2=arg2@entry=176848697, arg3=138922946, arg4=138922970) at ../../emacs/src/eval.c:2663 #83 0x081afd85 in Fload (file=176846033, noerror=noerror@entry=138922946, nomessage=138922970, nosuffix=nosuffix@entry=138922946, must_suffix=138922970) at ../../emacs/src/lread.c:1305 #84 0x08199e6e in Frequire (feature=176835482, filename=138922946, noerror=138922946) at ../../emacs/src/fns.c:2671 #85 0x0818dc59 in Ffuncall (nargs=nargs@entry=2, args=args@entry=0xbfd93388) at ../../emacs/src/eval.c:2822 #86 0x0818f01c in Fapply (nargs=2, args=0xbfd93388) at ../../emacs/src/eval.c:2301 #87 0x0818db27 in Ffuncall (nargs=3, args=0xbfd93384) at ../../emacs/src/eval.c:2796 #88 0x081c07c3 in exec_byte_code (bytestr=0, vector=6, maxdepth=28, args_template=args_template@entry=1028, nargs=nargs@entry=1, args=0x1) at ../../emacs/src/bytecode.c:919 #89 0x0818d79e in funcall_lambda (fun=142657717, nargs=nargs@entry=1, arg_vector=arg_vector@entry=0xbfd93520) at ../../emacs/src/eval.c:2983 #90 0x0818da53 in Ffuncall (nargs=2, args=0xbfd9351c) at ../../emacs/src/eval.c:2876 #91 0x081c07c3 in exec_byte_code (bytestr=0, vector=6, maxdepth=16, args_template=args_template@entry=1028, nargs=nargs@entry=1, args=0xbfd93518) at ../../emacs/src/bytecode.c:919 #92 0x0818d79e in funcall_lambda (fun=142653581, nargs=nargs@entry=1, arg_vector=arg_vector@entry=0xbfd936bc) at ../../emacs/src/eval.c:2983 #93 0x0818da53 in Ffuncall (nargs=2, args=0xbfd936b8) at ../../emacs/src/eval.c:2876 #94 0x081c07c3 in exec_byte_code (bytestr=0, vector=6, maxdepth=20, args_template=args_template@entry=1028, nargs=nargs@entry=1, args=0xbfd936b4) at ../../emacs/src/bytecode.c:919 #95 0x0818d79e in funcall_lambda (fun=142653533, nargs=nargs@entry=1, arg_vector=arg_vector@entry=0xbfd9385c) at ../../emacs/src/eval.c:2983 #96 0x0818da53 in Ffuncall (nargs=2, args=0xbfd93858) at ../../emacs/src/eval.c:2876 #97 0x081c07c3 in exec_byte_code (bytestr=0, vector=6, maxdepth=16, args_template=args_template@entry=0, nargs=nargs@entry=0, args=0xbfd93854) at ../../emacs/src/bytecode.c:919 #98 0x0818d79e in funcall_lambda (fun=141433917, nargs=nargs@entry=0, arg_vector=arg_vector@entry=0xbfd939f8) at ../../emacs/src/eval.c:2983 #99 0x0818da53 in Ffuncall (nargs=1, args=0xbfd939f4) at ../../emacs/src/eval.c:2876 #100 0x081c07c3 in exec_byte_code (bytestr=0, vector=6, maxdepth=4, args_template=args_template@entry=0, nargs=nargs@entry=0, args=0x0) at ../../emacs/src/bytecode.c:919 #101 0x0818d79e in funcall_lambda (fun=141433957, nargs=nargs@entry=0, arg_vector=arg_vector@entry=0xbfd93b94) at ../../emacs/src/eval.c:2983 #102 0x0818da53 in Ffuncall (nargs=1, args=0xbfd93b90) at ../../emacs/src/eval.c:2876 #103 0x0818d350 in eval_sub (form=176799150) at ../../emacs/src/eval.c:2157 #104 0x081903eb in internal_lisp_condition_case (var=143193746, bodyform=<optimized out>, handlers=<optimized out>) at ../../emacs/src/eval.c:1323 #105 0x081c1d9d in exec_byte_code (bytestr=0, vector=6, maxdepth=64, args_template=args_template@entry=1028, nargs=nargs@entry=1, args=0xbfd93cb0) at ../../emacs/src/bytecode.c:1169 #106 0x0818d79e in funcall_lambda (fun=142641333, nargs=nargs@entry=1, arg_vector=arg_vector@entry=0xbfd93e98) at ../../emacs/src/eval.c:2983 #107 0x0818da53 in Ffuncall (nargs=2, args=0xbfd93e94) at ../../emacs/src/eval.c:2876 #108 0x081c07c3 in exec_byte_code (bytestr=0, vector=6, maxdepth=68, args_template=args_template@entry=2052, nargs=nargs@entry=1, args=0xbfd93e90) at ../../emacs/src/bytecode.c:919 #109 0x0818d79e in funcall_lambda (fun=142633061, nargs=nargs@entry=1, arg_vector=arg_vector@entry=0xbfd94048) at ../../emacs/src/eval.c:2983 #110 0x0818da53 in Ffuncall (nargs=2, args=0xbfd94044) at ../../emacs/src/eval.c:2876 #111 0x081c07c3 in exec_byte_code (bytestr=0, vector=6, maxdepth=8, args_template=args_template@entry=0, nargs=nargs@entry=0, args=0x0) at ../../emacs/src/bytecode.c:919 #112 0x0818d79e in funcall_lambda (fun=141761653, nargs=nargs@entry=0, arg_vector=arg_vector@entry=0xbfd941e4) at ../../emacs/src/eval.c:2983 #113 0x0818da53 in Ffuncall (nargs=1, args=0xbfd941e0) at ../../emacs/src/eval.c:2876 #114 0x0818d350 in eval_sub (form=176800838) at ../../emacs/src/eval.c:2157 #115 0x081903eb in internal_lisp_condition_case (var=143549378, bodyform=<optimized out>, handlers=<optimized out>) at ../../emacs/src/eval.c:1323 #116 0x081c1d9d in exec_byte_code (bytestr=0, vector=6, maxdepth=48, args_template=args_template@entry=1028, nargs=nargs@entry=1, args=0xbfd942f8) at ../../emacs/src/bytecode.c:1169 #117 0x0818d79e in funcall_lambda (fun=141723053, nargs=nargs@entry=1, arg_vector=arg_vector@entry=0xbfd944c0) at ../../emacs/src/eval.c:2983 #118 0x0818da53 in Ffuncall (nargs=2, args=0xbfd944bc) at ../../emacs/src/eval.c:2876 #119 0x081c07c3 in exec_byte_code (bytestr=0, vector=6, maxdepth=40, args_template=args_template@entry=1024, nargs=nargs@entry=0, args=0xbfd944b8) at ../../emacs/src/bytecode.c:919 #120 0x0818d79e in funcall_lambda (fun=141725101, nargs=nargs@entry=0, arg_vector=arg_vector@entry=0xbfd946a0) at ../../emacs/src/eval.c:2983 #121 0x0818da53 in Ffuncall (nargs=1, args=0xbfd9469c) at ../../emacs/src/eval.c:2876 #122 0x081c07c3 in exec_byte_code (bytestr=0, vector=6, maxdepth=92, args_template=args_template@entry=1028, nargs=nargs@entry=1, args=0xbfd94678) at ../../emacs/src/bytecode.c:919 #123 0x0818d79e in funcall_lambda (fun=137084413, nargs=nargs@entry=1, arg_vector=arg_vector@entry=0xbfd94848) at ../../emacs/src/eval.c:2983 #124 0x0818da53 in Ffuncall (nargs=2, args=0xbfd94844) at ../../emacs/src/eval.c:2876 #125 0x081c07c3 in exec_byte_code (bytestr=0, vector=6, maxdepth=68, args_template=args_template@entry=0, nargs=nargs@entry=0, args=0x82b8ba4 <pure+288068>) at ../../emacs/src/bytecode.c:919 #126 0x0818d79e in funcall_lambda (fun=137071485, nargs=nargs@entry=0, arg_vector=arg_vector@entry=0xbfd94a1c) at ../../emacs/src/eval.c:2983 #127 0x0818da53 in Ffuncall (nargs=1, args=0xbfd94a18) at ../../emacs/src/eval.c:2876 #128 0x081c07c3 in exec_byte_code (bytestr=0, vector=6, maxdepth=48, args_template=args_template@entry=0, nargs=nargs@entry=0, args=0xbfd94a14) at ../../emacs/src/bytecode.c:919 #129 0x0818d79e in funcall_lambda (fun=fun@entry=137069733, nargs=nargs@entry=0, arg_vector=arg_vector@entry=0xbfd94b70) at ../../emacs/src/eval.c:2983 #130 0x0818cc8c in apply_lambda (fun=<optimized out>, args=<optimized out>) at ../../emacs/src/eval.c:2924 #131 0x0818cfa4 in eval_sub (form=form@entry=140586918) at ../../emacs/src/eval.c:2260 #132 0x08190564 in Feval (form=140586918, lexical=138922946) at ../../emacs/src/eval.c:2003 #133 0x08120559 in top_level_2 () at ../../emacs/src/keyboard.c:1183 #134 0x0818c213 in internal_condition_case ( bfun=bfun@entry=0x8120540 <top_level_2>, handlers=138956090, hfun=hfun@entry=0x81249f0 <cmd_error>) at ../../emacs/src/eval.c:1354 #135 0x08120535 in top_level_1 (ignore=138922946) at ../../emacs/src/keyboard.c:1191 #136 0x0818c143 in internal_catch (tag=138954138, func=func@entry=0x81204d0 <top_level_1>, arg=138922946) at ../../emacs/src/eval.c:1118 #137 0x08124624 in command_loop () at ../../emacs/src/keyboard.c:1152 #138 recursive_edit_1 () at ../../emacs/src/keyboard.c:777 #139 0x08124903 in Frecursive_edit () at ../../emacs/src/keyboard.c:845 #140 0x08059578 in main (argc=<optimized out>, argv=0xbfd94e44) at ../../emacs/src/emacs.c:1654 -- David Kastrup ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#17215: Build failure 2014-04-08 10:42 ` David Kastrup @ 2014-04-08 10:50 ` Daniel Colascione 2014-04-08 11:36 ` David Kastrup 0 siblings, 1 reply; 20+ messages in thread From: Daniel Colascione @ 2014-04-08 10:50 UTC (permalink / raw) To: David Kastrup, Glenn Morris; +Cc: 17215 [-- Attachment #1: Type: text/plain, Size: 505 bytes --] On 04/08/2014 03:42 AM, David Kastrup wrote: > Glenn Morris <rgm@gnu.org> writes: > >> David Kastrup wrote: >> >>> Any more information that you need? >> >> Please run addr2line as described in info node `Crashing'. >> Or get a backtrace from gdb. >> >> (But I'm going to guess that this is just >> http://debbugs.gnu.org/17178 aka 17168 again.) > > With regard to relating to the other bug: I reverted the respective part > in subr.el of (git commit) Try it with the current trunk. [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 901 bytes --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#17215: Build failure 2014-04-08 10:50 ` Daniel Colascione @ 2014-04-08 11:36 ` David Kastrup 2014-04-09 10:19 ` Nicolas Richard 0 siblings, 1 reply; 20+ messages in thread From: David Kastrup @ 2014-04-08 11:36 UTC (permalink / raw) To: Daniel Colascione; +Cc: 17215 Daniel Colascione <dancol@dancol.org> writes: > On 04/08/2014 03:42 AM, David Kastrup wrote: >> Glenn Morris <rgm@gnu.org> writes: >> >>> David Kastrup wrote: >>> >>>> Any more information that you need? >>> >>> Please run addr2line as described in info node `Crashing'. >>> Or get a backtrace from gdb. >>> >>> (But I'm going to guess that this is just >>> http://debbugs.gnu.org/17178 aka 17168 again.) >> >> With regard to relating to the other bug: I reverted the respective part >> in subr.el of (git commit) > > Try it with the current trunk. I am using the Git mirror. Last commit is commit 2da406808826326ea46e43f8187a0451d0ef5303 Author: Daniel Colascione <dancol@dancol.org> Date: Tue Apr 8 03:33:48 2014 -0700 Tweak completion documentation Still dumps core. Looks pretty much the same to me: #0 0x40022424 in __kernel_vsyscall () #1 0x416b60c6 in raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/pt-raise.c:37 #2 0x08120099 in terminate_due_to_signal (sig=sig@entry=6, backtrace_limit=backtrace_limit@entry=40) at ../../emacs/src/emacs.c:382 #3 0x08138967 in emacs_abort () at ../../emacs/src/sysdep.c:2130 #4 0x08178cc0 in Ffset (symbol=140567234, definition=136867149) at ../../emacs/src/data.c:733 #5 0x081c20b7 in exec_byte_code (bytestr=0, vector=6, maxdepth=12, args_template=args_template@entry=1028, nargs=nargs@entry=1, args=0xbfda3528) at ../../emacs/src/bytecode.c:1322 #6 0x0818d84e in funcall_lambda (fun=162440189, nargs=nargs@entry=1, arg_vector=arg_vector@entry=0xbfda36cc) at ../../emacs/src/eval.c:2983 #7 0x0818db03 in Ffuncall (nargs=2, args=0xbfda36c8) at ../../emacs/src/eval.c:2876 #8 0x081c0873 in exec_byte_code (bytestr=0, vector=6, maxdepth=44, args_template=args_template@entry=2056, nargs=nargs@entry=2, args=0xbfda36c4) at ../../emacs/src/bytecode.c:919 #9 0x0818d84e in funcall_lambda (fun=fun@entry=137210773, nargs=nargs@entry=2, arg_vector=arg_vector@entry=0xbfda3800) at ../../emacs/src/eval.c:2983 #10 0x0818cd3c in apply_lambda (fun=<optimized out>, args=<optimized out>) at ../../emacs/src/eval.c:2924 #11 0x0818d054 in eval_sub (form=162401054) at ../../emacs/src/eval.c:2260 #12 0x0818d556 in Fprogn (body=162401078) at ../../emacs/src/eval.c:468 #13 0x0818ca87 in unbind_to (count=count@entry=144, value=162484622) at ../../emacs/src/eval.c:3309 #14 0x081902a5 in Funwind_protect (args=162398902) at ../../emacs/src/eval.c:1216 #15 0x0818d33e in eval_sub (form=162398894) at ../../emacs/src/eval.c:2133 #16 0x0818d556 in Fprogn (body=162399030) at ../../emacs/src/eval.c:468 #17 0x0818fe77 in FletX (args=162399038) at ../../emacs/src/eval.c:906 #18 0x0818d33e in eval_sub (form=162399046) at ../../emacs/src/eval.c:2133 #19 0x0818d556 in Fprogn (body=162399078) at ../../emacs/src/eval.c:468 #20 0x0818d8bf in funcall_lambda (fun=162399126, fun@entry=162399134, nargs=nargs@entry=4, arg_vector=arg_vector@entry=0xbfda3b70) at ../../emacs/src/eval.c:3042 #21 0x0818cd3c in apply_lambda (fun=<optimized out>, args=<optimized out>) at ../../emacs/src/eval.c:2924 #22 0x0818d054 in eval_sub (form=162422446) at ../../emacs/src/eval.c:2260 #23 0x0818d33e in eval_sub (form=162422390) at ../../emacs/src/eval.c:2133 #24 0x0818fde3 in FletX (args=162468966) at ../../emacs/src/eval.c:881 #25 0x0818d33e in eval_sub (form=162468974) at ../../emacs/src/eval.c:2133 #26 0x0818d556 in Fprogn (body=162469014) at ../../emacs/src/eval.c:468 #27 0x0818d8bf in funcall_lambda (fun=162469214, nargs=nargs@entry=4, arg_vector=arg_vector@entry=0xbfda3ea4) at ../../emacs/src/eval.c:3042 #28 0x0818db03 in Ffuncall (nargs=5, args=args@entry=0xbfda3ea0) at ../../emacs/src/eval.c:2876 #29 0x0818ef0b in Fapply (nargs=nargs@entry=2, args=args@entry=0xbfda3f38) at ../../emacs/src/eval.c:2354 #30 0x0818f13f in apply1 (fn=162469222, arg=161192782) at ../../emacs/src/eval.c:2588 #31 0x0818f6d0 in Fmacroexpand (form=<optimized out>, environment=138922946) at ../../emacs/src/eval.c:1066 #32 0x0818dd20 in Ffuncall (nargs=3, args=0xbfda3ffc) at ../../emacs/src/eval.c:2818 #33 0x081c0873 in exec_byte_code (bytestr=0, vector=6, maxdepth=108, args_template=args_template@entry=1028, nargs=nargs@entry=1, args=0xbfda3ff8) at ../../emacs/src/bytecode.c:919 #34 0x0818d84e in funcall_lambda (fun=137023405, nargs=nargs@entry=1, arg_vector=arg_vector@entry=0xbfda4204) at ../../emacs/src/eval.c:2983 #35 0x0818db03 in Ffuncall (nargs=2, args=0xbfda4200) at ../../emacs/src/eval.c:2876 #36 0x081c0873 in exec_byte_code (bytestr=0, vector=6, maxdepth=36, args_template=args_template@entry=2052, nargs=nargs@entry=2, args=0xbfda41fc) at ../../emacs/src/bytecode.c:919 #37 0x0818d84e in funcall_lambda (fun=137022533, nargs=nargs@entry=2, arg_vector=arg_vector@entry=0xbfda43a4) at ../../emacs/src/eval.c:2983 #38 0x0818db03 in Ffuncall (nargs=3, args=0xbfda43a0) at ../../emacs/src/eval.c:2876 #39 0x081c0873 in exec_byte_code (bytestr=0, vector=6, maxdepth=44, args_template=args_template@entry=2056, nargs=nargs@entry=2, args=0xbfda439c) at ../../emacs/src/bytecode.c:919 #40 0x0818d84e in funcall_lambda (fun=137023597, nargs=nargs@entry=2, arg_vector=arg_vector@entry=0xbfda4564) at ../../emacs/src/eval.c:2983 #41 0x0818db03 in Ffuncall (nargs=3, args=0xbfda4560) at ../../emacs/src/eval.c:2876 #42 0x081c0873 in exec_byte_code (bytestr=0, vector=6, maxdepth=108, args_template=args_template@entry=1028, nargs=nargs@entry=1, args=0xbfda4548) at ../../emacs/src/bytecode.c:919 #43 0x0818d84e in funcall_lambda (fun=137023405, nargs=nargs@entry=1, arg_vector=arg_vector@entry=0xbfda4754) at ../../emacs/src/eval.c:2983 #44 0x0818db03 in Ffuncall (nargs=2, args=0xbfda4750) at ../../emacs/src/eval.c:2876 #45 0x081c0873 in exec_byte_code (bytestr=0, vector=6, maxdepth=36, args_template=args_template@entry=2052, nargs=nargs@entry=2, args=0xbfda474c) at ../../emacs/src/bytecode.c:919 #46 0x0818d84e in funcall_lambda (fun=137022533, nargs=nargs@entry=2, arg_vector=arg_vector@entry=0xbfda48f4) at ../../emacs/src/eval.c:2983 #47 0x0818db03 in Ffuncall (nargs=3, args=0xbfda48f0) at ../../emacs/src/eval.c:2876 #48 0x081c0873 in exec_byte_code (bytestr=0, vector=6, maxdepth=44, args_template=args_template@entry=2056, nargs=nargs@entry=2, args=0xbfda48ec) at ../../emacs/src/bytecode.c:919 #49 0x0818d84e in funcall_lambda (fun=137023597, nargs=nargs@entry=2, arg_vector=arg_vector@entry=0xbfda4ab4) at ../../emacs/src/eval.c:2983 #50 0x0818db03 in Ffuncall (nargs=3, args=0xbfda4ab0) at ../../emacs/src/eval.c:2876 #51 0x081c0873 in exec_byte_code (bytestr=0, vector=6, maxdepth=108, args_template=args_template@entry=1028, nargs=nargs@entry=1, args=0xbfda4a98) at ../../emacs/src/bytecode.c:919 #52 0x0818d84e in funcall_lambda (fun=137023405, nargs=nargs@entry=1, arg_vector=arg_vector@entry=0xbfda4c90) at ../../emacs/src/eval.c:2983 #53 0x0818db03 in Ffuncall (nargs=2, args=0xbfda4c8c) at ../../emacs/src/eval.c:2876 #54 0x081c0873 in exec_byte_code (bytestr=0, vector=6, maxdepth=16, args_template=args_template@entry=2052, nargs=nargs@entry=1, args=0xbfda4c88) at ../../emacs/src/bytecode.c:919 #55 0x0818d84e in funcall_lambda (fun=137024061, nargs=nargs@entry=1, arg_vector=arg_vector@entry=0xbfda4e28) at ../../emacs/src/eval.c:2983 #56 0x0818db03 in Ffuncall (nargs=2, args=0xbfda4e24) at ../../emacs/src/eval.c:2876 #57 0x081c0873 in exec_byte_code (bytestr=0, vector=6, maxdepth=8, args_template=args_template@entry=0, nargs=nargs@entry=0, args=0xbfda4e20) at ../../emacs/src/bytecode.c:919 #58 0x0818d84e in funcall_lambda (fun=161202149, nargs=nargs@entry=0, arg_vector=arg_vector@entry=0xbfda4fc4) at ../../emacs/src/eval.c:2983 #59 0x0818db03 in Ffuncall (nargs=1, args=0xbfda4fc0) at ../../emacs/src/eval.c:2876 #60 0x0818d400 in eval_sub (form=161191262) at ../../emacs/src/eval.c:2157 #61 0x0819049b in internal_lisp_condition_case (var=140664170, bodyform=<optimized out>, handlers=<optimized out>) at ../../emacs/src/eval.c:1323 #62 0x081c1e4d in exec_byte_code (bytestr=0, vector=6, maxdepth=44, args_template=args_template@entry=1028, nargs=nargs@entry=1, args=0xbfda50d8) at ../../emacs/src/bytecode.c:1169 #63 0x0818d84e in funcall_lambda (fun=137025373, nargs=nargs@entry=1, arg_vector=arg_vector@entry=0xbfda528c) at ../../emacs/src/eval.c:2983 #64 0x0818db03 in Ffuncall (nargs=nargs@entry=2, args=args@entry=0xbfda5288) at ../../emacs/src/eval.c:2876 #65 0x0818de97 in call1 (fn=fn@entry=139083706, arg1=arg1@entry=161192726) at ../../emacs/src/eval.c:2614 #66 0x081af023 in readevalloop (readcharfun=readcharfun@entry=160515237, stream=stream@entry=0x0, sourcename=160526257, sourcename@entry=160514841, printflag=false, unibyte=unibyte@entry=138922946, readfun=138922946, start=138922946, end=138922946) at ../../emacs/src/lread.c:1933 #67 0x081b00bb in Feval_buffer (buffer=160515237, printflag=138922946, filename=160514841, unibyte=138922946, do_allow_print=138922970) at ../../emacs/src/lread.c:1995 #68 0x0818dcc6 in Ffuncall (nargs=6, args=0xbfda53b4) at ../../emacs/src/eval.c:2831 #69 0x081c0873 in exec_byte_code (bytestr=0, vector=6, maxdepth=24, args_template=138922946, nargs=nargs@entry=0, args=0xbfda53bc) at ../../emacs/src/bytecode.c:919 #70 0x0818d7cd in funcall_lambda (fun=136878341, nargs=nargs@entry=4, arg_vector=arg_vector@entry=0xbfda5560) at ../../emacs/src/eval.c:3049 #71 0x0818db03 in Ffuncall (nargs=nargs@entry=5, args=args@entry=0xbfda555c) at ../../emacs/src/eval.c:2876 #72 0x0818f79f in call4 (fn=140760930, arg1=arg1@entry=160514841, arg2=arg2@entry=160514841, arg3=138922946, arg4=138922970) at ../../emacs/src/eval.c:2663 #73 0x081afe35 in Fload (file=160514217, noerror=noerror@entry=138922946, nomessage=138922970, nosuffix=nosuffix@entry=138922946, must_suffix=138922970) at ../../emacs/src/lread.c:1305 #74 0x08199f1e in Frequire (feature=160582642, filename=138922946, noerror=138922946) at ../../emacs/src/fns.c:2671 #75 0x0818d235 in eval_sub (form=form@entry=160597358) at ../../emacs/src/eval.c:2191 #76 0x081af02d in readevalloop (readcharfun=readcharfun@entry=160498701, stream=stream@entry=0x0, sourcename=160512097, sourcename@entry=160496369, printflag=false, unibyte=unibyte@entry=138922946, readfun=138922946, start=138922946, end=138922946) at ../../emacs/src/lread.c:1934 #77 0x081b00bb in Feval_buffer (buffer=160498701, printflag=138922946, filename=160496369, unibyte=138922946, do_allow_print=138922970) at ../../emacs/src/lread.c:1995 #78 0x0818dcc6 in Ffuncall (nargs=6, args=0xbfda5884) at ../../emacs/src/eval.c:2831 #79 0x081c0873 in exec_byte_code (bytestr=0, vector=6, maxdepth=24, args_template=138922946, nargs=nargs@entry=0, args=0xbfda588c) at ../../emacs/src/bytecode.c:919 #80 0x0818d7cd in funcall_lambda (fun=136878341, nargs=nargs@entry=4, arg_vector=arg_vector@entry=0xbfda5a30) at ../../emacs/src/eval.c:3049 #81 0x0818db03 in Ffuncall (nargs=nargs@entry=5, args=args@entry=0xbfda5a2c) at ../../emacs/src/eval.c:2876 #82 0x0818f79f in call4 (fn=140760930, arg1=arg1@entry=160496369, arg2=arg2@entry=160496369, arg3=138922946, arg4=138922970) at ../../emacs/src/eval.c:2663 #83 0x081afe35 in Fload (file=160495745, noerror=noerror@entry=138922946, nomessage=138922970, nosuffix=nosuffix@entry=138922946, must_suffix=138922970) at ../../emacs/src/lread.c:1305 #84 0x08199f1e in Frequire (feature=160492674, filename=138922946, noerror=138922946) at ../../emacs/src/fns.c:2671 #85 0x0818dd09 in Ffuncall (nargs=nargs@entry=2, args=args@entry=0xbfda5d18) at ../../emacs/src/eval.c:2822 #86 0x0818f0cc in Fapply (nargs=2, args=0xbfda5d18) at ../../emacs/src/eval.c:2301 #87 0x0818dbd7 in Ffuncall (nargs=3, args=0xbfda5d14) at ../../emacs/src/eval.c:2796 #88 0x081c0873 in exec_byte_code (bytestr=0, vector=6, maxdepth=28, args_template=args_template@entry=1028, nargs=nargs@entry=1, args=0x1) at ../../emacs/src/bytecode.c:919 #89 0x0818d84e in funcall_lambda (fun=141717197, nargs=nargs@entry=1, arg_vector=arg_vector@entry=0xbfda5eb0) at ../../emacs/src/eval.c:2983 #90 0x0818db03 in Ffuncall (nargs=2, args=0xbfda5eac) at ../../emacs/src/eval.c:2876 #91 0x081c0873 in exec_byte_code (bytestr=0, vector=6, maxdepth=16, args_template=args_template@entry=1028, nargs=nargs@entry=1, args=0xbfda5ea8) at ../../emacs/src/bytecode.c:919 #92 0x0818d84e in funcall_lambda (fun=141675541, nargs=nargs@entry=1, arg_vector=arg_vector@entry=0xbfda604c) at ../../emacs/src/eval.c:2983 #93 0x0818db03 in Ffuncall (nargs=2, args=0xbfda6048) at ../../emacs/src/eval.c:2876 #94 0x081c0873 in exec_byte_code (bytestr=0, vector=6, maxdepth=20, args_template=args_template@entry=1028, nargs=nargs@entry=1, args=0xbfda6044) at ../../emacs/src/bytecode.c:919 #95 0x0818d84e in funcall_lambda (fun=141675493, nargs=nargs@entry=1, arg_vector=arg_vector@entry=0xbfda61ec) at ../../emacs/src/eval.c:2983 #96 0x0818db03 in Ffuncall (nargs=2, args=0xbfda61e8) at ../../emacs/src/eval.c:2876 #97 0x081c0873 in exec_byte_code (bytestr=0, vector=6, maxdepth=16, args_template=args_template@entry=0, nargs=nargs@entry=0, args=0xbfda61e4) at ../../emacs/src/bytecode.c:919 #98 0x0818d84e in funcall_lambda (fun=143074821, nargs=nargs@entry=0, arg_vector=arg_vector@entry=0xbfda6388) at ../../emacs/src/eval.c:2983 #99 0x0818db03 in Ffuncall (nargs=1, args=0xbfda6384) at ../../emacs/src/eval.c:2876 #100 0x081c0873 in exec_byte_code (bytestr=0, vector=6, maxdepth=4, args_template=args_template@entry=0, nargs=nargs@entry=0, args=0x0) at ../../emacs/src/bytecode.c:919 #101 0x0818d84e in funcall_lambda (fun=143074861, nargs=nargs@entry=0, arg_vector=arg_vector@entry=0xbfda6524) at ../../emacs/src/eval.c:2983 #102 0x0818db03 in Ffuncall (nargs=1, args=0xbfda6520) at ../../emacs/src/eval.c:2876 #103 0x0818d400 in eval_sub (form=160449006) at ../../emacs/src/eval.c:2157 #104 0x0819049b in internal_lisp_condition_case (var=143210426, bodyform=<optimized out>, handlers=<optimized out>) at ../../emacs/src/eval.c:1323 #105 0x081c1e4d in exec_byte_code (bytestr=0, vector=6, maxdepth=64, args_template=args_template@entry=1028, nargs=nargs@entry=1, args=0xbfda6640) at ../../emacs/src/bytecode.c:1169 #106 0x0818d84e in funcall_lambda (fun=141552629, nargs=nargs@entry=1, arg_vector=arg_vector@entry=0xbfda6828) at ../../emacs/src/eval.c:2983 #107 0x0818db03 in Ffuncall (nargs=2, args=0xbfda6824) at ../../emacs/src/eval.c:2876 #108 0x081c0873 in exec_byte_code (bytestr=0, vector=6, maxdepth=68, args_template=args_template@entry=2052, nargs=nargs@entry=1, args=0xbfda6820) at ../../emacs/src/bytecode.c:919 #109 0x0818d84e in funcall_lambda (fun=140938653, nargs=nargs@entry=1, arg_vector=arg_vector@entry=0xbfda69d8) at ../../emacs/src/eval.c:2983 #110 0x0818db03 in Ffuncall (nargs=2, args=0xbfda69d4) at ../../emacs/src/eval.c:2876 #111 0x081c0873 in exec_byte_code (bytestr=0, vector=6, maxdepth=8, args_template=args_template@entry=0, nargs=nargs@entry=0, args=0x0) at ../../emacs/src/bytecode.c:919 #112 0x0818d84e in funcall_lambda (fun=142078949, nargs=nargs@entry=0, arg_vector=arg_vector@entry=0xbfda6b74) at ../../emacs/src/eval.c:2983 #113 0x0818db03 in Ffuncall (nargs=1, args=0xbfda6b70) at ../../emacs/src/eval.c:2876 #114 0x0818d400 in eval_sub (form=160450694) at ../../emacs/src/eval.c:2157 #115 0x0819049b in internal_lisp_condition_case (var=143563674, bodyform=<optimized out>, handlers=<optimized out>) at ../../emacs/src/eval.c:1323 #116 0x081c1e4d in exec_byte_code (bytestr=0, vector=6, maxdepth=48, args_template=args_template@entry=1028, nargs=nargs@entry=1, args=0xbfda6c88) at ../../emacs/src/bytecode.c:1169 #117 0x0818d84e in funcall_lambda (fun=142178453, nargs=nargs@entry=1, arg_vector=arg_vector@entry=0xbfda6e50) at ../../emacs/src/eval.c:2983 #118 0x0818db03 in Ffuncall (nargs=2, args=0xbfda6e4c) at ../../emacs/src/eval.c:2876 #119 0x081c0873 in exec_byte_code (bytestr=0, vector=6, maxdepth=40, args_template=args_template@entry=1024, nargs=nargs@entry=0, args=0xbfda6e48) at ../../emacs/src/bytecode.c:919 #120 0x0818d84e in funcall_lambda (fun=142178429, nargs=nargs@entry=0, arg_vector=arg_vector@entry=0xbfda7030) at ../../emacs/src/eval.c:2983 #121 0x0818db03 in Ffuncall (nargs=1, args=0xbfda702c) at ../../emacs/src/eval.c:2876 #122 0x081c0873 in exec_byte_code (bytestr=0, vector=6, maxdepth=92, args_template=args_template@entry=1028, nargs=nargs@entry=1, args=0xbfda7008) at ../../emacs/src/bytecode.c:919 #123 0x0818d84e in funcall_lambda (fun=137084509, nargs=nargs@entry=1, arg_vector=arg_vector@entry=0xbfda71d8) at ../../emacs/src/eval.c:2983 #124 0x0818db03 in Ffuncall (nargs=2, args=0xbfda71d4) at ../../emacs/src/eval.c:2876 #125 0x081c0873 in exec_byte_code (bytestr=0, vector=6, maxdepth=68, args_template=args_template@entry=0, nargs=nargs@entry=0, args=0x82b8c04 <pure+288164>) at ../../emacs/src/bytecode.c:919 #126 0x0818d84e in funcall_lambda (fun=137071581, nargs=nargs@entry=0, arg_vector=arg_vector@entry=0xbfda73ac) at ../../emacs/src/eval.c:2983 #127 0x0818db03 in Ffuncall (nargs=1, args=0xbfda73a8) at ../../emacs/src/eval.c:2876 #128 0x081c0873 in exec_byte_code (bytestr=0, vector=6, maxdepth=48, args_template=args_template@entry=0, nargs=nargs@entry=0, args=0xbfda73a4) at ../../emacs/src/bytecode.c:919 #129 0x0818d84e in funcall_lambda (fun=fun@entry=137069829, nargs=nargs@entry=0, arg_vector=arg_vector@entry=0xbfda7500) at ../../emacs/src/eval.c:2983 #130 0x0818cd3c in apply_lambda (fun=<optimized out>, args=<optimized out>) at ../../emacs/src/eval.c:2924 #131 0x0818d054 in eval_sub (form=form@entry=140586918) at ../../emacs/src/eval.c:2260 #132 0x08190614 in Feval (form=140586918, lexical=138922946) at ../../emacs/src/eval.c:2003 #133 0x08120559 in top_level_2 () at ../../emacs/src/keyboard.c:1182 #134 0x0818c2c3 in internal_condition_case ( bfun=bfun@entry=0x8120540 <top_level_2>, handlers=138956090, hfun=hfun@entry=0x81249f0 <cmd_error>) at ../../emacs/src/eval.c:1354 #135 0x08120535 in top_level_1 (ignore=138922946) at ../../emacs/src/keyboard.c:1190 #136 0x0818c1f3 in internal_catch (tag=138954138, func=func@entry=0x81204d0 <top_level_1>, arg=138922946) at ../../emacs/src/eval.c:1118 #137 0x08124624 in command_loop () at ../../emacs/src/keyboard.c:1151 #138 recursive_edit_1 () at ../../emacs/src/keyboard.c:776 #139 0x08124903 in Frecursive_edit () at ../../emacs/src/keyboard.c:844 #140 0x08059578 in main (argc=<optimized out>, argv=0xbfda77d4) at ../../emacs/src/emacs.c:1654 -- David Kastrup ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#17215: Build failure 2014-04-08 11:36 ` David Kastrup @ 2014-04-09 10:19 ` Nicolas Richard 2014-04-09 10:48 ` Daniel Colascione 2014-04-09 15:38 ` Bastien 0 siblings, 2 replies; 20+ messages in thread From: Nicolas Richard @ 2014-04-09 10:19 UTC (permalink / raw) To: David Kastrup; +Cc: bzg, 17215 [I'm cc-ing Bastien because he had a similar problem IIRC] Hi David, > Still dumps core. Looks pretty much the same to me: > #0 0x40022424 in __kernel_vsyscall () > #1 0x416b60c6 in raise (sig=sig@entry=6) > at ../nptl/sysdeps/unix/sysv/linux/pt-raise.c:37 You could try Daniel's suggestion to bug#17184, i.e. compile with -DSYSTEM_PURESIZE_EXTRA=10000000 Perhaps it is time to increase BASE_PURESIZE ? FWIW I applied this patch to my local branch : Modified src/ChangeLog diff --git a/src/ChangeLog b/src/ChangeLog index 2b00e60..9d0d8f0 100644 --- a/src/ChangeLog +++ b/src/ChangeLog @@ -1,3 +1,7 @@ +2014-04-09 Nicolas Richard <theonewiththeevillook@yahoo.fr> + + * puresize.h (BASE_PURESIZE): Increase to 1720000. + 2014-04-09 Stefan Monnier <monnier@iro.umontreal.ca> * insdel.c (prepare_to_modify_buffer_1): Cancel lock-file checks and Modified src/puresize.h diff --git a/src/puresize.h b/src/puresize.h index 0ee29d8..ad591c7 100644 --- a/src/puresize.h +++ b/src/puresize.h @@ -40,7 +40,7 @@ along with GNU Emacs. If not, see <http://www.gnu.org/licenses/>. */ #endif #ifndef BASE_PURESIZE -#define BASE_PURESIZE (1700000 + SYSTEM_PURESIZE_EXTRA + SITELOAD_PURESIZE_EXTRA) +#define BASE_PURESIZE (1720000 + SYSTEM_PURESIZE_EXTRA + SITELOAD_PURESIZE_EXTRA) #endif /* Increase BASE_PURESIZE by a ratio depending on the machine's word size. */ -- Nico. ^ permalink raw reply related [flat|nested] 20+ messages in thread
* bug#17215: Build failure 2014-04-09 10:19 ` Nicolas Richard @ 2014-04-09 10:48 ` Daniel Colascione 2014-04-09 12:43 ` Stefan Monnier 2014-04-09 15:38 ` Bastien 1 sibling, 1 reply; 20+ messages in thread From: Daniel Colascione @ 2014-04-09 10:48 UTC (permalink / raw) To: Nicolas Richard, David Kastrup; +Cc: bzg, 17215 [-- Attachment #1: Type: text/plain, Size: 940 bytes --] On 04/09/2014 03:19 AM, Nicolas Richard wrote: > [I'm cc-ing Bastien because he had a similar problem IIRC] > > Hi David, > >> Still dumps core. Looks pretty much the same to me: >> #0 0x40022424 in __kernel_vsyscall () >> #1 0x416b60c6 in raise (sig=sig@entry=6) >> at ../nptl/sysdeps/unix/sysv/linux/pt-raise.c:37 > > You could try Daniel's suggestion to bug#17184, i.e. compile with > -DSYSTEM_PURESIZE_EXTRA=10000000 > > Perhaps it is time to increase BASE_PURESIZE ? FWIW I applied this patch > to my local branch : > Probably a good idea, assuming the core size increase is natural and doesn't reflect some deeper problem. Aside: why do we even bother with the malloc-on-pure-overflow logic? We can't GC once we've overflown pure storage (although that could be made to work), so an Emacs in that condition isn't very useful. Wouldn't it be simpler just to abort when we overflow pure storage? [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 901 bytes --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#17215: Build failure 2014-04-09 10:48 ` Daniel Colascione @ 2014-04-09 12:43 ` Stefan Monnier 0 siblings, 0 replies; 20+ messages in thread From: Stefan Monnier @ 2014-04-09 12:43 UTC (permalink / raw) To: Daniel Colascione; +Cc: Nicolas Richard, 17215, David Kastrup, bzg >> Perhaps it is time to increase BASE_PURESIZE ? Apparently. Stefan ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#17215: Build failure 2014-04-09 10:19 ` Nicolas Richard 2014-04-09 10:48 ` Daniel Colascione @ 2014-04-09 15:38 ` Bastien 1 sibling, 0 replies; 20+ messages in thread From: Bastien @ 2014-04-09 15:38 UTC (permalink / raw) To: Nicolas Richard; +Cc: 17215, David Kastrup Hi Nicolas, Nicolas Richard <theonewiththeevillook@yahoo.fr> writes: > Perhaps it is time to increase BASE_PURESIZE ? FWIW I applied this patch > to my local branch : I'm using the same patch now, it works well, thanks! -- Bastien ^ permalink raw reply [flat|nested] 20+ messages in thread
[parent not found: <handler.17215.B.139685811224063.ack@debbugs.gnu.org>]
* bug#17215: Acknowledgement (Build failure) [not found] ` <handler.17215.B.139685811224063.ack@debbugs.gnu.org> @ 2014-04-11 15:51 ` David Kastrup 2014-04-11 19:11 ` Daniel Colascione 0 siblings, 1 reply; 20+ messages in thread From: David Kastrup @ 2014-04-11 15:51 UTC (permalink / raw) To: 17215 It would appear that this particular bug yielded to the pure size increase. What a singularly useless error behavior for a problem that is expected to reoccur with some regularity! So I think this bug can be closed. It would not seem to be related to the more obscure GC problems that were suggested as its cause at first. Bit of a pity since it was quite reproducible. -- David Kastrup ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#17215: Acknowledgement (Build failure) 2014-04-11 15:51 ` bug#17215: Acknowledgement (Build failure) David Kastrup @ 2014-04-11 19:11 ` Daniel Colascione 2014-04-11 20:10 ` Eli Zaretskii 2014-04-11 20:11 ` Stefan Monnier 0 siblings, 2 replies; 20+ messages in thread From: Daniel Colascione @ 2014-04-11 19:11 UTC (permalink / raw) To: David Kastrup, 17215 [-- Attachment #1: Type: text/plain, Size: 367 bytes --] On 04/11/2014 08:51 AM, David Kastrup wrote: > > It would appear that this particular bug yielded to the pure size > increase. What a singularly useless error behavior for a problem that > is expected to reoccur with some regularity! Still waiting to hear a response to my previous question on why we don't just abort as soon as we detect pure overflow. [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 901 bytes --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#17215: Acknowledgement (Build failure) 2014-04-11 19:11 ` Daniel Colascione @ 2014-04-11 20:10 ` Eli Zaretskii 2014-04-11 20:18 ` Stefan Monnier 2014-04-11 20:11 ` Stefan Monnier 1 sibling, 1 reply; 20+ messages in thread From: Eli Zaretskii @ 2014-04-11 20:10 UTC (permalink / raw) To: Daniel Colascione; +Cc: 17215, dak > Date: Fri, 11 Apr 2014 12:11:26 -0700 > From: Daniel Colascione <dancol@dancol.org> > > Still waiting to hear a response to my previous question on why we don't > just abort as soon as we detect pure overflow. AFAIR, we used to do that in the past, but then an overflow during a build would trap you. So now we don't (and actually you have an overflow every time you run "temacs -batch -load loadup bootstrap" during a normal build. ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#17215: Acknowledgement (Build failure) 2014-04-11 20:10 ` Eli Zaretskii @ 2014-04-11 20:18 ` Stefan Monnier 0 siblings, 0 replies; 20+ messages in thread From: Stefan Monnier @ 2014-04-11 20:18 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 17215, dak > and actually you have an overflow every time you run > "temacs -batch -load loadup bootstrap" during a normal build. I don't think so: we set purify-flag to nil early in loadup during the bootstrap, specifically to avoid overflowing (which means that the bootstrap-emacs executable has a mostly empty pure space). Stefan ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#17215: Acknowledgement (Build failure) 2014-04-11 19:11 ` Daniel Colascione 2014-04-11 20:10 ` Eli Zaretskii @ 2014-04-11 20:11 ` Stefan Monnier 2014-04-11 20:58 ` David Kastrup 2014-04-12 8:35 ` Eli Zaretskii 1 sibling, 2 replies; 20+ messages in thread From: Stefan Monnier @ 2014-04-11 20:11 UTC (permalink / raw) To: Daniel Colascione; +Cc: 17215, David Kastrup >> It would appear that this particular bug yielded to the pure size >> increase. What a singularly useless error behavior for a problem that >> is expected to reoccur with some regularity! > Still waiting to hear a response to my previous question on why we don't > just abort as soon as we detect pure overflow. Good question. The reason is largely histerical, where it was convenient to still have a partly usable Emacs. Nowadays, many more people build their Emacs from trunk without having the technical knowledge to detect and handle this problem, so it's probably better to just abort. Stefan ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#17215: Acknowledgement (Build failure) 2014-04-11 20:11 ` Stefan Monnier @ 2014-04-11 20:58 ` David Kastrup 2014-04-11 21:34 ` Daniel Colascione 2014-04-12 8:35 ` Eli Zaretskii 1 sibling, 1 reply; 20+ messages in thread From: David Kastrup @ 2014-04-11 20:58 UTC (permalink / raw) To: Stefan Monnier; +Cc: 17215 Stefan Monnier <monnier@iro.umontreal.ca> writes: >>> It would appear that this particular bug yielded to the pure size >>> increase. What a singularly useless error behavior for a problem that >>> is expected to reoccur with some regularity! >> Still waiting to hear a response to my previous question on why we don't >> just abort as soon as we detect pure overflow. > > Good question. The reason is largely histerical, where it was > convenient to still have a partly usable Emacs. Nowadays, many more > people build their Emacs from trunk without having the technical > knowledge to detect and handle this problem, so it's probably better to > just abort. I fail to see how an Emacs that segfaults during the build can be considered usable to a degree making sense. -- David Kastrup ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#17215: Acknowledgement (Build failure) 2014-04-11 20:58 ` David Kastrup @ 2014-04-11 21:34 ` Daniel Colascione 2014-04-12 13:19 ` Stefan Monnier 0 siblings, 1 reply; 20+ messages in thread From: Daniel Colascione @ 2014-04-11 21:34 UTC (permalink / raw) To: David Kastrup, Stefan Monnier; +Cc: 17215 [-- Attachment #1: Type: text/plain, Size: 1478 bytes --] On 04/11/2014 01:58 PM, David Kastrup wrote: > Stefan Monnier <monnier@iro.umontreal.ca> writes: > >>>> It would appear that this particular bug yielded to the pure size >>>> increase. What a singularly useless error behavior for a problem that >>>> is expected to reoccur with some regularity! >>> Still waiting to hear a response to my previous question on why we don't >>> just abort as soon as we detect pure overflow. >> >> Good question. The reason is largely histerical, where it was >> convenient to still have a partly usable Emacs. Nowadays, many more >> people build their Emacs from trunk without having the technical >> knowledge to detect and handle this problem, so it's probably better to >> just abort. > > I fail to see how an Emacs that segfaults during the build can be > considered usable to a degree making sense. Emacs didn't always segfault (well, abort, really) on pure overflow --- I broke it. Before, when we noticed we oveflowed pure space, we would continue (mallocing more pure space), then just refuse to GC. Ever. The benefit of this scheme (as opposed to failing early) is that you can tell *by how much* pure space overflowed, but I don't think that this power is very useful given that users generally don't know how to find this information. IMHO (and I think Stefan agrees), we should just abort as soon as we detect pure space overflow and ask users to increase the necessary constants in the source. [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 901 bytes --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#17215: Acknowledgement (Build failure) 2014-04-11 21:34 ` Daniel Colascione @ 2014-04-12 13:19 ` Stefan Monnier 0 siblings, 0 replies; 20+ messages in thread From: Stefan Monnier @ 2014-04-12 13:19 UTC (permalink / raw) To: Daniel Colascione; +Cc: 17215, David Kastrup >>> Good question. The reason is largely histerical, where it was >>> convenient to still have a partly usable Emacs. Nowadays, many more >>> people build their Emacs from trunk without having the technical >>> knowledge to detect and handle this problem, so it's probably better to >>> just abort. >> I fail to see how an Emacs that segfaults during the build can be >> considered usable to a degree making sense. I don't know why it segfaults in the current situation, but usually it works "just fine", modulo never reclaiming memory. More specifically, such an Emacs should usually have no trouble compiling a few .el files (tho the memory growth usually prevents such an Emacs from recompiling all the .el files). Stefan ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#17215: Acknowledgement (Build failure) 2014-04-11 20:11 ` Stefan Monnier 2014-04-11 20:58 ` David Kastrup @ 2014-04-12 8:35 ` Eli Zaretskii 2014-04-12 13:21 ` Stefan Monnier 1 sibling, 1 reply; 20+ messages in thread From: Eli Zaretskii @ 2014-04-12 8:35 UTC (permalink / raw) To: Stefan Monnier; +Cc: 17215, dak > From: Stefan Monnier <monnier@iro.umontreal.ca> > Date: Fri, 11 Apr 2014 16:11:58 -0400 > Cc: 17215@debbugs.gnu.org, David Kastrup <dak@gnu.org> > > >> It would appear that this particular bug yielded to the pure size > >> increase. What a singularly useless error behavior for a problem that > >> is expected to reoccur with some regularity! > > Still waiting to hear a response to my previous question on why we don't > > just abort as soon as we detect pure overflow. > > Good question. The reason is largely histerical, where it was > convenient to still have a partly usable Emacs. Nowadays, many more > people build their Emacs from trunk without having the technical > knowledge to detect and handle this problem, so it's probably better to > just abort. More people building development code doesn't mean more people who know what to do about pure storage. So just aborting without any helpful information (e.g., how much to enlarge the pure space, and what macro to change) doesn't seem like progress to me. ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#17215: Acknowledgement (Build failure) 2014-04-12 8:35 ` Eli Zaretskii @ 2014-04-12 13:21 ` Stefan Monnier 2014-04-12 14:18 ` Eli Zaretskii 0 siblings, 1 reply; 20+ messages in thread From: Stefan Monnier @ 2014-04-12 13:21 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 17215, dak > More people building development code doesn't mean more people who > know what to do about pure storage. So just aborting without any > helpful information (e.g., how much to enlarge the pure space, and > what macro to change) doesn't seem like progress to me. At least they'll come and look for a solution to "not enough pure space", rather than report bugs about slowdowns and whatnots which make us waste time trying to figure out what's going on. Stefan ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#17215: Acknowledgement (Build failure) 2014-04-12 13:21 ` Stefan Monnier @ 2014-04-12 14:18 ` Eli Zaretskii 0 siblings, 0 replies; 20+ messages in thread From: Eli Zaretskii @ 2014-04-12 14:18 UTC (permalink / raw) To: Stefan Monnier; +Cc: 17215, dak > From: Stefan Monnier <monnier@IRO.UMontreal.CA> > Cc: dancol@dancol.org, 17215@debbugs.gnu.org, dak@gnu.org > Date: Sat, 12 Apr 2014 09:21:15 -0400 > > > More people building development code doesn't mean more people who > > know what to do about pure storage. So just aborting without any > > helpful information (e.g., how much to enlarge the pure space, and > > what macro to change) doesn't seem like progress to me. > > At least they'll come and look for a solution to "not enough pure > space", rather than report bugs about slowdowns and whatnots which make > us waste time trying to figure out what's going on. Why not tell them exactly what to do? ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2014-04-12 14:18 UTC | newest] Thread overview: 20+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-04-07 8:08 bug#17215: Build failure David Kastrup 2014-04-07 20:47 ` Glenn Morris 2014-04-08 10:42 ` David Kastrup 2014-04-08 10:50 ` Daniel Colascione 2014-04-08 11:36 ` David Kastrup 2014-04-09 10:19 ` Nicolas Richard 2014-04-09 10:48 ` Daniel Colascione 2014-04-09 12:43 ` Stefan Monnier 2014-04-09 15:38 ` Bastien [not found] ` <handler.17215.B.139685811224063.ack@debbugs.gnu.org> 2014-04-11 15:51 ` bug#17215: Acknowledgement (Build failure) David Kastrup 2014-04-11 19:11 ` Daniel Colascione 2014-04-11 20:10 ` Eli Zaretskii 2014-04-11 20:18 ` Stefan Monnier 2014-04-11 20:11 ` Stefan Monnier 2014-04-11 20:58 ` David Kastrup 2014-04-11 21:34 ` Daniel Colascione 2014-04-12 13:19 ` Stefan Monnier 2014-04-12 8:35 ` Eli Zaretskii 2014-04-12 13:21 ` Stefan Monnier 2014-04-12 14:18 ` Eli Zaretskii
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.