From debbugs-submit-bounces@debbugs.gnu.org Mon Apr 07 04:08:32 2014 Received: (at submit) by debbugs.gnu.org; 7 Apr 2014 08:08:32 +0000 Received: from localhost ([127.0.0.1]:38735 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WX4bY-0006G2-89 for submit@debbugs.gnu.org; Mon, 07 Apr 2014 04:08:32 -0400 Received: from eggs.gnu.org ([208.118.235.92]:38218) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WX4bV-0006Fq-FU for submit@debbugs.gnu.org; Mon, 07 Apr 2014 04:08:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WX4bU-00064K-GS for submit@debbugs.gnu.org; Mon, 07 Apr 2014 04:08:29 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_05,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:46133) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WX4bU-00064C-DZ for submit@debbugs.gnu.org; Mon, 07 Apr 2014 04:08:28 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39940) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WX4bT-0001XP-E7 for bug-gnu-emacs@gnu.org; Mon, 07 Apr 2014 04:08:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WX4bS-00063u-DN for bug-gnu-emacs@gnu.org; Mon, 07 Apr 2014 04:08:27 -0400 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:39451) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WX4bS-00063q-AO for bug-gnu-emacs@gnu.org; Mon, 07 Apr 2014 04:08:26 -0400 Received: from localhost ([127.0.0.1]:46627 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WX4bR-0007zn-Pq for bug-emacs@gnu.org; Mon, 07 Apr 2014 04:08:26 -0400 Received: by lola (Postfix, from userid 1000) id 50B91E04FC; Mon, 7 Apr 2014 10:08:25 +0200 (CEST) From: David Kastrup To: bug-emacs@gnu.org Subject: Build failure Date: Mon, 07 Apr 2014 10:08:25 +0200 Message-ID: <871tx9k1dy.fsf@fencepost.gnu.org> MIME-Version: 1.0 Content-Type: text/plain X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -5.3 (-----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.3 (-----) 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 From debbugs-submit-bounces@debbugs.gnu.org Mon Apr 07 16:47:25 2014 Received: (at 17215) by debbugs.gnu.org; 7 Apr 2014 20:47:25 +0000 Received: from localhost ([127.0.0.1]:39926 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WXGRw-0004Nw-9A for submit@debbugs.gnu.org; Mon, 07 Apr 2014 16:47:24 -0400 Received: from fencepost.gnu.org ([208.118.235.10]:53691) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WXGRt-0004Nn-Fw for 17215@debbugs.gnu.org; Mon, 07 Apr 2014 16:47:21 -0400 Received: from rgm by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1WXGRs-0003d6-4P; Mon, 07 Apr 2014 16:47:20 -0400 From: Glenn Morris To: David Kastrup Subject: Re: bug#17215: Build failure References: <871tx9k1dy.fsf@fencepost.gnu.org> X-Spook: genetic Jyllandsposten virus assassinate morse X-Ran: nx*>s"HRjWD7hw;DNFiAhZYnYYw74dOWHVco<]W:s1cNVF=%{vS-3d8{rxTOZ2r]qN=6E; X-Hue: yellow X-Attribution: GM Date: Mon, 07 Apr 2014 16:47:20 -0400 In-Reply-To: <871tx9k1dy.fsf@fencepost.gnu.org> (David Kastrup's message of "Mon, 07 Apr 2014 10:08:25 +0200") Message-ID: <4d2gshnon.fsf@fencepost.gnu.org> User-Agent: Gnus (www.gnus.org), GNU Emacs (www.gnu.org/software/emacs/) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -5.3 (-----) X-Debbugs-Envelope-To: 17215 Cc: 17215@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.3 (-----) 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.) From debbugs-submit-bounces@debbugs.gnu.org Tue Apr 08 06:43:11 2014 Received: (at 17215) by debbugs.gnu.org; 8 Apr 2014 10:43:11 +0000 Received: from localhost ([127.0.0.1]:40336 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WXTUk-0002Yx-3u for submit@debbugs.gnu.org; Tue, 08 Apr 2014 06:43:11 -0400 Received: from fencepost.gnu.org ([208.118.235.10]:38745) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WXTUd-0002Yj-Ok for 17215@debbugs.gnu.org; Tue, 08 Apr 2014 06:43:05 -0400 Received: from localhost ([127.0.0.1]:46052 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WXTUb-0005IE-To; Tue, 08 Apr 2014 06:43:02 -0400 Received: by lola (Postfix, from userid 1000) id EB234E070E; Tue, 8 Apr 2014 12:42:39 +0200 (CEST) From: David Kastrup To: Glenn Morris Subject: Re: bug#17215: Build failure References: <871tx9k1dy.fsf@fencepost.gnu.org> <4d2gshnon.fsf@fencepost.gnu.org> Date: Tue, 08 Apr 2014 12:42:39 +0200 Message-ID: <87ob0cgl0g.fsf@fencepost.gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -5.3 (-----) X-Debbugs-Envelope-To: 17215 Cc: 17215@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.3 (-----) Glenn Morris 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=, args=) 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=, args=) 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=, 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=, handlers=) 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=, handlers=) 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=, handlers=) 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 ) 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=, args=) 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 , handlers=138956090, hfun=hfun@entry=0x81249f0 ) 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 , 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=, argv=0xbfd94e44) at ../../emacs/src/emacs.c:1654 -- David Kastrup From debbugs-submit-bounces@debbugs.gnu.org Tue Apr 08 06:50:55 2014 Received: (at 17215) by debbugs.gnu.org; 8 Apr 2014 10:50:55 +0000 Received: from localhost ([127.0.0.1]:40340 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WXTcE-0002m9-8I for submit@debbugs.gnu.org; Tue, 08 Apr 2014 06:50:54 -0400 Received: from dancol.org ([96.126.100.184]:57738) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WXTcB-0002lx-4I for 17215@debbugs.gnu.org; Tue, 08 Apr 2014 06:50:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=uaxb9NL16NHKO9AtExK35F1G3E5h2J8oTx/amHVJ/bc=; b=Iz8YB3/rjjgKzawuCUH057wh1ERLwSVP5Uq5Z4hpFE80GXpYqOirc9AfoupnfcTgJnr32n2ZJeLeXgSJe0x6UXW5dEsiLDfFpZheuRBFGf4eFrGVzpIxRc5D4oynO+DPFRcZY/b4UqL3HMKGllvnEd6D/A6KE8iBk5wcQMZDsjzn3FaBN8ruE9PfNrE3pEv0Eg+NJpuFB62oJWFiAgau4aY2yLAW/CvK/o/lZ3YfODvDABl89knK8Hhg4nCAO1jn+fvG95zn6VEl0qERnC7cwTBz9mkryPHAIqXDaRqtGam1Fzejbz4TNHy7ONsfgSxI9w1qe9UaEi4ALZxFR5WADA==; Received: from [2601:8:b200:551::2b1] by dancol.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1WXTcA-0000JG-2h; Tue, 08 Apr 2014 03:50:50 -0700 Message-ID: <5343D489.7080409@dancol.org> Date: Tue, 08 Apr 2014 03:50:49 -0700 From: Daniel Colascione User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: David Kastrup , Glenn Morris Subject: Re: bug#17215: Build failure References: <871tx9k1dy.fsf@fencepost.gnu.org> <4d2gshnon.fsf@fencepost.gnu.org> <87ob0cgl0g.fsf@fencepost.gnu.org> In-Reply-To: <87ob0cgl0g.fsf@fencepost.gnu.org> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UrNSrN44rnbLesJmNfV5sabLbufgBBINK" X-Spam-Score: -0.3 (/) X-Debbugs-Envelope-To: 17215 Cc: 17215@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.3 (/) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --UrNSrN44rnbLesJmNfV5sabLbufgBBINK Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 04/08/2014 03:42 AM, David Kastrup wrote: > Glenn Morris writes: >=20 >> 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.) >=20 > With regard to relating to the other bug: I reverted the respective par= t > in subr.el of (git commit) Try it with the current trunk. --UrNSrN44rnbLesJmNfV5sabLbufgBBINK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTQ9SJAAoJEMAaIROpHW7I3jEP/AyV345ddhamnU9BdyDLOpUp QRVJTmeKSYxzD3e/ihsX93HmstSOXJkMe3hndXeZoxx2YjudQF0ciHHaBQVOOsbt 5OiXsylDCJ+CyLVT2XLg4n+nGwAhv9RN61ftajq0Ecu0ZCKbZ5yVVP/wmYqN+k4v SsmTZt4aiHlbu01qp7oHiOwLyD1dZHf3FM7nF55Ws9fkZWkcjZ4Do0/wnh3cilYR EA3SE/TFEMpkDevUT7Kv/rfgM+LtVWLdowaqWogShGs3nanYfAXpC1xKKpdApogA ioHGHUS7pfmTZZPiqIcH5Zj32d2YlLrr/sV3ha6hCNpMZnQlZ9vOA2m7pKY+iKUl gsrDlOtQV0KlatSjIflMi1wQE3yN1VfGv78pDT5/94NeKjHh5rbFdRVBVlZs3a40 XJ8vFHPPLmCar49VGcshkuLiLJn42hCX+ecQbYzRa3wmyDB8ewgQOaallQiGVE5K 8OwKOrFmp9haDo1MXXt3NB1pR/c087t+WGdzH99Ip7atwAYygmhnkQi8/BT0W5bS cfw5f+/8zywUpQ/O+ji5KrJqEPZsMqzB2SVtonp9KkVnEMYNSW2onFnc+7z7O1mA RPCqfsaWZcISjrXzGjIhiROT2vfMe20SQCXMdZhBl8mJziQskb08S+TWKKIfsoLV qydz7p4Arh5wNyBcwDvA =RZzk -----END PGP SIGNATURE----- --UrNSrN44rnbLesJmNfV5sabLbufgBBINK-- From debbugs-submit-bounces@debbugs.gnu.org Tue Apr 08 07:36:37 2014 Received: (at 17215) by debbugs.gnu.org; 8 Apr 2014 11:36:37 +0000 Received: from localhost ([127.0.0.1]:40356 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WXUKR-0005BF-QQ for submit@debbugs.gnu.org; Tue, 08 Apr 2014 07:36:37 -0400 Received: from fencepost.gnu.org ([208.118.235.10]:39767) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WXUKP-0005B6-2e for 17215@debbugs.gnu.org; Tue, 08 Apr 2014 07:36:34 -0400 Received: from localhost ([127.0.0.1]:47072 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WXUKM-0005FT-OX; Tue, 08 Apr 2014 07:36:31 -0400 Received: by lola (Postfix, from userid 1000) id 50492E04FB; Tue, 8 Apr 2014 13:36:30 +0200 (CEST) From: David Kastrup To: Daniel Colascione Subject: Re: bug#17215: Build failure References: <871tx9k1dy.fsf@fencepost.gnu.org> <4d2gshnon.fsf@fencepost.gnu.org> <87ob0cgl0g.fsf@fencepost.gnu.org> <5343D489.7080409@dancol.org> Date: Tue, 08 Apr 2014 13:36:30 +0200 In-Reply-To: <5343D489.7080409@dancol.org> (Daniel Colascione's message of "Tue, 08 Apr 2014 03:50:49 -0700") Message-ID: <87k3b0giip.fsf@fencepost.gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -5.3 (-----) X-Debbugs-Envelope-To: 17215 Cc: Glenn Morris , 17215@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.3 (-----) Daniel Colascione writes: > On 04/08/2014 03:42 AM, David Kastrup wrote: >> Glenn Morris 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 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=, args=) 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=, args=) 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=, 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=, handlers=) 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=, handlers=) 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=, handlers=) 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 ) 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=, args=) 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 , handlers=138956090, hfun=hfun@entry=0x81249f0 ) 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 , 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=, argv=0xbfda77d4) at ../../emacs/src/emacs.c:1654 -- David Kastrup From debbugs-submit-bounces@debbugs.gnu.org Wed Apr 09 06:19:03 2014 Received: (at 17215) by debbugs.gnu.org; 9 Apr 2014 10:19:03 +0000 Received: from localhost ([127.0.0.1]:38482 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WXpaw-0004Dv-Ky for submit@debbugs.gnu.org; Wed, 09 Apr 2014 06:19:02 -0400 Received: from mxin.ulb.ac.be ([164.15.128.112]:52102) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WXpau-0004DU-7R for 17215@debbugs.gnu.org; Wed, 09 Apr 2014 06:19:01 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqgEAHYdRVOkD4Xx/2dsb2JhbABZg0GrOgWZNIE1dIIlAQEBAwF5BQsIAw4TJQ8BBEkTCYdeAQMJCKoKmhUBhyIXh2eEbIIZB4Q4AQOWdoFohjyGNwOFTIMyOw Received: from mathsrv4.ulb.ac.be (HELO geodiff-mac3) ([164.15.133.241]) by smtp.ulb.ac.be with ESMTP; 09 Apr 2014 12:18:58 +0200 From: Nicolas Richard To: David Kastrup Subject: Re: bug#17215: Build failure References: <871tx9k1dy.fsf@fencepost.gnu.org> <4d2gshnon.fsf@fencepost.gnu.org> <87ob0cgl0g.fsf@fencepost.gnu.org> <5343D489.7080409@dancol.org> <87k3b0giip.fsf@fencepost.gnu.org> Date: Wed, 09 Apr 2014 12:19:26 +0200 In-Reply-To: <87k3b0giip.fsf@fencepost.gnu.org> (David Kastrup's message of "Tue, 08 Apr 2014 13:36:30 +0200") Message-ID: <87mwfurej5.fsf@yahoo.fr> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 17215 Cc: bzg@altern.org, 17215@debbugs.gnu.org, Daniel Colascione X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) [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 + + * puresize.h (BASE_PURESIZE): Increase to 1720000. + 2014-04-09 Stefan Monnier * 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 . */ #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. From debbugs-submit-bounces@debbugs.gnu.org Wed Apr 09 06:49:00 2014 Received: (at 17215) by debbugs.gnu.org; 9 Apr 2014 10:49:01 +0000 Received: from localhost ([127.0.0.1]:38490 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WXq3w-00053y-0E for submit@debbugs.gnu.org; Wed, 09 Apr 2014 06:49:00 -0400 Received: from dancol.org ([96.126.100.184]:54758) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WXq3q-00053m-Dl for 17215@debbugs.gnu.org; Wed, 09 Apr 2014 06:48:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=xWSEaLJCGGSO3kI0seYALEoFCzXotxAQC6GOWLA/weo=; b=YC3Pk/u7CgXQvFXrOYzMICEZKGNjXi/H15+jIFDFVw4ARng63QcnjvNNdSPbOxbIqUZPNZF2spu0o848A8U7biKi9m/OwCuE9wVlolheuHJwe1hwesffJ/0On/WoiTeM7KvhAGMl+Mhq2vsAE0m10MfRS7Mvjt+WfEDqok0wHy90ke4qJugcmQNO8ag4yY6c3X2kgFoTcCWGQWHHjG/bbBnIDKnqAdX5cI3xEnP6FjhC6R1k32NIpTT8sZmCG0J8SG6gzg/oV6CHFqhlAnkRWgEH7Od6BWMofSopVypGQOH9TvuJxpC8pDJywFszZbJE8sy0Mu5RS8MFtfXUhsN5qg==; Received: from c-67-161-115-61.hsd1.wa.comcast.net ([67.161.115.61] helo=[192.168.1.50]) by dancol.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1WXq3m-0007sM-A8; Wed, 09 Apr 2014 03:48:50 -0700 Message-ID: <53452591.1040505@dancol.org> Date: Wed, 09 Apr 2014 03:48:49 -0700 From: Daniel Colascione User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Nicolas Richard , David Kastrup Subject: Re: bug#17215: Build failure References: <871tx9k1dy.fsf@fencepost.gnu.org> <4d2gshnon.fsf@fencepost.gnu.org> <87ob0cgl0g.fsf@fencepost.gnu.org> <5343D489.7080409@dancol.org> <87k3b0giip.fsf@fencepost.gnu.org> <87mwfurej5.fsf@yahoo.fr> In-Reply-To: <87mwfurej5.fsf@yahoo.fr> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PjmpSdwgWOCmPURIunX31xC3i7fCVV2JC" X-Spam-Score: -0.3 (/) X-Debbugs-Envelope-To: 17215 Cc: bzg@altern.org, 17215@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.3 (/) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --PjmpSdwgWOCmPURIunX31xC3i7fCVV2JC Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 04/09/2014 03:19 AM, Nicolas Richard wrote: > [I'm cc-ing Bastien because he had a similar problem IIRC] >=20 > Hi David, >=20 >> Still dumps core. Looks pretty much the same to me: >> #0 0x40022424 in __kernel_vsyscall () >> #1 0x416b60c6 in raise (sig=3Dsig@entry=3D6) >> at ../nptl/sysdeps/unix/sysv/linux/pt-raise.c:37 >=20 > You could try Daniel's suggestion to bug#17184, i.e. compile with > -DSYSTEM_PURESIZE_EXTRA=3D10000000 >=20 > Perhaps it is time to increase BASE_PURESIZE ? FWIW I applied this patc= h > to my local branch : >=20 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? --PjmpSdwgWOCmPURIunX31xC3i7fCVV2JC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTRSWRAAoJEMAaIROpHW7I8jsP/1PS4Fz5vunVVolzzNYTf21S nCPgzQ2JdxWk2oP+eUt6r/nIHrQASWEOFWR8x1LnrXVki9gXysT6OWgYqdrZo1qf zgXdoYamuZ72f4DnJdDKutd7+M37/gN6SnV/XBloUfPRGlB9U+Lc6BINnKuN5EPO CkHqP9ZqHguO4n6fhiUzuB5ppIFc3X8vEAT4UUdneXPQA0AtKWYhpLgFnJH+i8FS Z/9+oPufYduH61Cr7G5MQ6I/eWKUtn+aLfGIpnFOtb5hlg2olu00xWNvJjXKfkaW jtPbOL+TGTW3n0YjBSX0VGfwuo/b2MMqlrVoYXEXwEHN64L89MKuY8UcxDf3Ak+j 3jxs4+7402sG4h255CG/je3qtoiOHgJP1uodJ99eRZlRt+GbkKOx9ExkW7xDYQcj CB5MJKi8ETHbk+43H0qZcUfCSMKLSC5hcpqU78c4L0EpgTgqT8v8LrB5BT/2EEGJ c1TUjgnpC/5gKlu41oYqu6Fi6BWu6hugOVnL+nQ7w/3h0OE1cyYY7Sxye4r22k9t HEHlSc4Zd+cbqAAQW0f4Ouawktw5UxrfnMe6CZVyxj7KfIfizCcOaQuDhTONQnFo UZvGEqKZ7Nctn+PRAbDmYdaZYzEu1h4qWjOpnBMfBU9JAqBBxpqhlLbrXvwuUyyN iBrl8FqZ5kkgRvGLObU9 =xFQg -----END PGP SIGNATURE----- --PjmpSdwgWOCmPURIunX31xC3i7fCVV2JC-- From debbugs-submit-bounces@debbugs.gnu.org Wed Apr 09 08:43:16 2014 Received: (at 17215) by debbugs.gnu.org; 9 Apr 2014 12:43:16 +0000 Received: from localhost ([127.0.0.1]:38576 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WXrqV-0000pb-W8 for submit@debbugs.gnu.org; Wed, 09 Apr 2014 08:43:16 -0400 Received: from pruche.dit.umontreal.ca ([132.204.246.22]:39236) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WXrqT-0000pR-1r for 17215@debbugs.gnu.org; Wed, 09 Apr 2014 08:43:13 -0400 Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id s39Ch9Fo000588; Wed, 9 Apr 2014 08:43:09 -0400 Received: by pastel.home (Postfix, from userid 20848) id 5517D602DA; Wed, 9 Apr 2014 08:43:09 -0400 (EDT) From: Stefan Monnier To: Daniel Colascione Subject: Re: bug#17215: Build failure Message-ID: References: <871tx9k1dy.fsf@fencepost.gnu.org> <4d2gshnon.fsf@fencepost.gnu.org> <87ob0cgl0g.fsf@fencepost.gnu.org> <5343D489.7080409@dancol.org> <87k3b0giip.fsf@fencepost.gnu.org> <87mwfurej5.fsf@yahoo.fr> <53452591.1040505@dancol.org> Date: Wed, 09 Apr 2014 08:43:09 -0400 In-Reply-To: <53452591.1040505@dancol.org> (Daniel Colascione's message of "Wed, 09 Apr 2014 03:48:49 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0.2 X-NAI-Spam-Rules: 2 Rules triggered GEN_SPAM_FEATRE=0.2, RV4906=0 X-NAI-Spam-Version: 2.3.0.9378 : core <4906> : inlines <707> : streams <1155104> : uri <1724682> X-Spam-Score: -1.6 (-) X-Debbugs-Envelope-To: 17215 Cc: Nicolas Richard , 17215@debbugs.gnu.org, David Kastrup , bzg@altern.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.6 (-) >> Perhaps it is time to increase BASE_PURESIZE ? Apparently. Stefan From debbugs-submit-bounces@debbugs.gnu.org Wed Apr 09 11:38:51 2014 Received: (at 17215) by debbugs.gnu.org; 9 Apr 2014 15:38:51 +0000 Received: from localhost ([127.0.0.1]:39189 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WXuaQ-0005OR-TM for submit@debbugs.gnu.org; Wed, 09 Apr 2014 11:38:51 -0400 Received: from mail-s76.mailgun.info ([184.173.153.204]:38521) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WXuaN-0005OI-KC for 17215@debbugs.gnu.org; Wed, 09 Apr 2014 11:38:48 -0400 DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=mail.kickhub.com; q=dns/txt; s=k1; t=1397057927; h=From: To: Cc: Subject: In-Reply-To: References: Date: Message-Id: Mime-Version: Content-Type: Sender; bh=wd0mRP69vx1+M0KvZkcKWFBQSbAqLmopTXq7qhWs0co=; b=kkrLHbSVWb6+6Y/KlnQFp/bEBNTDdmDPP80x+oal/0DgoPZSJOBWLL0wE08Td5I2b6cCYMB1 U29J0pOA2ULmErngKymtxTuOyoXmQ1Ym5ZFZAVcI55vJ0MMtE/5Wbm4vnyDT34nyO6ZIea0s Vbia5jVOOVSUlr1bBsg5z/T63z8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=mail.kickhub.com; s=k1; q=dns; h=From: To: Cc: Subject: In-Reply-To: References: Date: Message-Id: Mime-Version: Content-Type: Sender; b=eLrrGZUDlwbF1DT5ixjo5vjbCSiqFGdnw7noi9A88ha4PPy15r5ZxpejZtHgMWUwKCbJ+i eVUAvn++mzN7bLxBVEYkkG47wzJkGcK1RNN5Uxsv5X+M2/iwQZj2nBpXBWfXRxxvPN+7qhx1 ziUKWjbM6HugfqoeSQroD/sn1rJ64= Received: from bzg.localdomain (Unknown [90.24.196.242]) by mxa.mailgun.org with ESMTP id 53456981.7faadcaa40d8-in3; Wed, 09 Apr 2014 15:38:41 -0000 (UTC) Received: by bzg.localdomain (Postfix, from userid 1000) id 48B0C1C20065; Wed, 9 Apr 2014 17:38:40 +0200 (CEST) From: Bastien To: Nicolas Richard Subject: Re: bug#17215: Build failure In-Reply-To: <87mwfurej5.fsf@yahoo.fr> (Nicolas Richard's message of "Wed, 09 Apr 2014 12:19:26 +0200") References: <871tx9k1dy.fsf@fencepost.gnu.org> <4d2gshnon.fsf@fencepost.gnu.org> <87ob0cgl0g.fsf@fencepost.gnu.org> <5343D489.7080409@dancol.org> <87k3b0giip.fsf@fencepost.gnu.org> <87mwfurej5.fsf@yahoo.fr> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) Date: Wed, 09 Apr 2014 17:38:40 +0200 Message-Id: <87d2gqtsvz.fsf@bzg.ath.cx> Mime-Version: 1.0 Content-Type: text/plain X-Mailgun-Sid: WyIxYThlZiIsICIxNzIxNUBkZWJidWdzLmdudS5vcmciLCAiOTA2OTEiXQ== X-Spam-Score: 0.4 (/) X-Debbugs-Envelope-To: 17215 Cc: 17215@debbugs.gnu.org, David Kastrup X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.4 (/) Hi Nicolas, Nicolas Richard 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 From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 11 11:51:28 2014 Received: (at 17215) by debbugs.gnu.org; 11 Apr 2014 15:51:28 +0000 Received: from localhost ([127.0.0.1]:45560 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WYdjj-0003UB-P7 for submit@debbugs.gnu.org; Fri, 11 Apr 2014 11:51:28 -0400 Received: from fencepost.gnu.org ([208.118.235.10]:54923 ident=Debian-exim) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WYdjc-0003Th-TK for 17215@debbugs.gnu.org; Fri, 11 Apr 2014 11:51:26 -0400 Received: from localhost ([127.0.0.1]:33997 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WYdjc-0001Yu-85 for 17215@debbugs.gnu.org; Fri, 11 Apr 2014 11:51:20 -0400 Received: by lola (Postfix, from userid 1000) id C0EFAE0531; Fri, 11 Apr 2014 17:51:19 +0200 (CEST) From: David Kastrup To: 17215@debbugs.gnu.org Subject: Re: bug#17215: Acknowledgement (Build failure) References: <871tx9k1dy.fsf@fencepost.gnu.org> Date: Fri, 11 Apr 2014 17:51:19 +0200 In-Reply-To: (GNU bug Tracking System's message of "Mon, 07 Apr 2014 08:09:03 +0000") Message-ID: <87ioqfdfuw.fsf@fencepost.gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -5.4 (-----) X-Debbugs-Envelope-To: 17215 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.4 (-----) 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 From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 11 12:32:42 2014 Received: (at control) by debbugs.gnu.org; 11 Apr 2014 16:32:43 +0000 Received: from localhost ([127.0.0.1]:45583 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WYeNe-0005NZ-2i for submit@debbugs.gnu.org; Fri, 11 Apr 2014 12:32:42 -0400 Received: from fencepost.gnu.org ([208.118.235.10]:56658 ident=Debian-exim) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WYeNY-0005NE-Ua for control@debbugs.gnu.org; Fri, 11 Apr 2014 12:32:37 -0400 Received: from rgm by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1WYeNY-0002no-Oz for control@debbugs.gnu.org; Fri, 11 Apr 2014 12:32:36 -0400 Date: Fri, 11 Apr 2014 12:32:36 -0400 Message-Id: Subject: control message for bug 17215 To: X-Mailer: mail (GNU Mailutils 2.1) From: Glenn Morris X-Spam-Score: -5.4 (-----) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.4 (-----) close 17215 From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 11 15:11:39 2014 Received: (at 17215) by debbugs.gnu.org; 11 Apr 2014 19:11:39 +0000 Received: from localhost ([127.0.0.1]:45652 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WYgrS-0004Ks-Vr for submit@debbugs.gnu.org; Fri, 11 Apr 2014 15:11:39 -0400 Received: from dancol.org ([96.126.100.184]:42044) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WYgrQ-0004Kj-Mt for 17215@debbugs.gnu.org; Fri, 11 Apr 2014 15:11:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=ogHoy8dnK649azP4x00sW3kWBWzZ/1kSGNbUaqCQVvY=; b=Zij5YUJXCYnt7naGcwEmc2CbS9tOhdG9aUWMsnt0Wkl1V0ShNOFXMeYmD+aeZLtRqKcDuLDeVCJZG+EY1T+nabD9K6WRWqIouTPH3pzdjmCe78rYxRfuQghLH2odZ+A4C9UEXy3FgwGUFOi+bbaJxq7zUnr4RRWc6ubwFEJrwQd1qUylLk1lVHzvL/XgevUsPJaXL+FvQNX5dJz49ysxeorWzu92zJR20EqYcT8o/cHbJ/h96OowdfP4VJb5XS5i6OqehyPiJzmI7J8srR7cbY0EyBuAEJzONEALeDFHhxHmkuXIZckam722pcntCKvLWVO1mP14zlvcdud900vq+g==; Received: from [2620:0:1cfe:a1:2b5:6dff:fe00:f9a6] by dancol.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1WYgrP-0000BD-KL; Fri, 11 Apr 2014 12:11:35 -0700 Message-ID: <53483E5E.8020705@dancol.org> Date: Fri, 11 Apr 2014 12:11:26 -0700 From: Daniel Colascione User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: David Kastrup , 17215@debbugs.gnu.org Subject: Re: bug#17215: Acknowledgement (Build failure) References: <871tx9k1dy.fsf@fencepost.gnu.org> <87ioqfdfuw.fsf@fencepost.gnu.org> In-Reply-To: <87ioqfdfuw.fsf@fencepost.gnu.org> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="BpdvsrpGH2nQ9ml16HR3ofhNtDgowjaih" X-Spam-Score: -0.4 (/) X-Debbugs-Envelope-To: 17215 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.4 (/) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --BpdvsrpGH2nQ9ml16HR3ofhNtDgowjaih Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 04/11/2014 08:51 AM, David Kastrup wrote: >=20 > 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. --BpdvsrpGH2nQ9ml16HR3ofhNtDgowjaih Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTSD5eAAoJEMAaIROpHW7I6SMP/jeB6iZw/tx2veFsRGi3lDgU RVioV8YJJiL1q30cZ4nzneyfJDp6SEZsthFLivZgFuBCIakdX/98+HGJfYIk+DXM SPcKL84p2eZFVVrJpyEyPxuSVkSAMVg5qKTke7z97NunfrIwx/ssNvQ0WxnNlm9G w7D4aU/U/KQHhTMs291YVUVWs9FGX+z2KW5PDt38txwPSOaMlyzQZP3tGznHmM/q eiu+44WN4rtDpLT4LWGFQTDvm5Mrg6CQXkopF2cF4Qaz5J3NYcO6tPzWwApG271q KAQdjjHHrDn4V83HrkmWnIDiNI2I5FD48q5/oj3MEqfdV0S5ZXYDYkS/3n4ihSKi eXeEQu8vvAVY4OCnZiR75waxphjfel2kmp0TzGhFqEqNIQRSfvbMh/whSRxxkIIj SpjMFXPYenZ8uxdzdfjrJZinOxcNImmYyigdF2oywDwP0kbwdAFMVZohAislWxVw ezgO++ms5fri6W+hA6xWYaqAIdK2Uogtjzm/zxTpiZqiZ+TcH8zD1utW7d8TqSt1 rWDBIo/DaJ+VHR1EaJT6r2v4I/iq68bvcZf2PHY8eF75p3yFaVMKnSq5ljkrVE2o p8Q6uWqtyMcmPDDQF0N1B3KKyHwnY757aMx7q/2MWXDsha1SsXhmr+ny8ZudIQCR I4fOtuEzv1BkbnTNHzhA =Wqqh -----END PGP SIGNATURE----- --BpdvsrpGH2nQ9ml16HR3ofhNtDgowjaih-- From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 11 16:10:26 2014 Received: (at 17215) by debbugs.gnu.org; 11 Apr 2014 20:10:27 +0000 Received: from localhost ([127.0.0.1]:45684 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WYhmM-0007Do-2W for submit@debbugs.gnu.org; Fri, 11 Apr 2014 16:10:26 -0400 Received: from mtaout27.012.net.il ([80.179.55.183]:37786) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WYhmH-0007DX-Uf for 17215@debbugs.gnu.org; Fri, 11 Apr 2014 16:10:23 -0400 Received: from conversion-daemon.mtaout27.012.net.il by mtaout27.012.net.il (HyperSendmail v2007.08) id <0N3V00H00TL8JQ00@mtaout27.012.net.il> for 17215@debbugs.gnu.org; Fri, 11 Apr 2014 23:06:59 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout27.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N3V00ITXUJN6Q20@mtaout27.012.net.il>; Fri, 11 Apr 2014 23:06:59 +0300 (IDT) Date: Fri, 11 Apr 2014 23:10:17 +0300 From: Eli Zaretskii Subject: Re: bug#17215: Acknowledgement (Build failure) In-reply-to: <53483E5E.8020705@dancol.org> X-012-Sender: halo1@inter.net.il To: Daniel Colascione Message-id: <83ha5ztyom.fsf@gnu.org> References: <871tx9k1dy.fsf@fencepost.gnu.org> <87ioqfdfuw.fsf@fencepost.gnu.org> <53483E5E.8020705@dancol.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 17215 Cc: 17215@debbugs.gnu.org, dak@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Fri, 11 Apr 2014 12:11:26 -0700 > From: Daniel Colascione > > 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. From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 11 16:12:38 2014 Received: (at 17215) by debbugs.gnu.org; 11 Apr 2014 20:12:38 +0000 Received: from localhost ([127.0.0.1]:45688 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WYhoQ-0007Hh-5D for submit@debbugs.gnu.org; Fri, 11 Apr 2014 16:12:38 -0400 Received: from mercure.iro.umontreal.ca ([132.204.24.67]:34359) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WYhoE-0007HG-Rx for 17215@debbugs.gnu.org; Fri, 11 Apr 2014 16:12:31 -0400 Received: from hidalgo.iro.umontreal.ca (hidalgo.iro.umontreal.ca [132.204.27.50]) by mercure.iro.umontreal.ca (Postfix) with ESMTP id 403A684D8C; Fri, 11 Apr 2014 16:12:22 -0400 (EDT) Received: from lechon.iro.umontreal.ca (lechon.iro.umontreal.ca [132.204.27.242]) by hidalgo.iro.umontreal.ca (Postfix) with ESMTP id 0CCB61E5874; Fri, 11 Apr 2014 16:11:59 -0400 (EDT) Received: by lechon.iro.umontreal.ca (Postfix, from userid 20848) id DE5E3B4180; Fri, 11 Apr 2014 16:11:58 -0400 (EDT) From: Stefan Monnier To: Daniel Colascione Subject: Re: bug#17215: Acknowledgement (Build failure) Message-ID: References: <871tx9k1dy.fsf@fencepost.gnu.org> <87ioqfdfuw.fsf@fencepost.gnu.org> <53483E5E.8020705@dancol.org> Date: Fri, 11 Apr 2014 16:11:58 -0400 In-Reply-To: <53483E5E.8020705@dancol.org> (Daniel Colascione's message of "Fri, 11 Apr 2014 12:11:26 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-DIRO-MailScanner-Information: Please contact the ISP for more information X-DIRO-MailScanner: Found to be clean X-DIRO-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=-2.49, requis 5, autolearn=not spam, ALL_TRUSTED -2.82, MC_REPONSE 0.33, MC_TSTLAST 0.00) X-DIRO-MailScanner-From: monnier@iro.umontreal.ca X-Spam-Status: No X-Spam-Score: -2.7 (--) X-Debbugs-Envelope-To: 17215 Cc: 17215@debbugs.gnu.org, David Kastrup X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.7 (--) >> 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 From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 11 16:19:14 2014 Received: (at 17215) by debbugs.gnu.org; 11 Apr 2014 20:19:15 +0000 Received: from localhost ([127.0.0.1]:45695 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WYhus-0007Tl-Ao for submit@debbugs.gnu.org; Fri, 11 Apr 2014 16:19:14 -0400 Received: from mercure.iro.umontreal.ca ([132.204.24.67]:48497) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WYhuq-0007Tb-JV for 17215@debbugs.gnu.org; Fri, 11 Apr 2014 16:19:13 -0400 Received: from hidalgo.iro.umontreal.ca (hidalgo.iro.umontreal.ca [132.204.27.50]) by mercure.iro.umontreal.ca (Postfix) with ESMTP id F07DA84D8C; Fri, 11 Apr 2014 16:19:11 -0400 (EDT) Received: from lechon.iro.umontreal.ca (lechon.iro.umontreal.ca [132.204.27.242]) by hidalgo.iro.umontreal.ca (Postfix) with ESMTP id 11A611E5874; Fri, 11 Apr 2014 16:18:49 -0400 (EDT) Received: by lechon.iro.umontreal.ca (Postfix, from userid 20848) id DECE8B4180; Fri, 11 Apr 2014 16:18:48 -0400 (EDT) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#17215: Acknowledgement (Build failure) Message-ID: References: <871tx9k1dy.fsf@fencepost.gnu.org> <87ioqfdfuw.fsf@fencepost.gnu.org> <53483E5E.8020705@dancol.org> <83ha5ztyom.fsf@gnu.org> Date: Fri, 11 Apr 2014 16:18:48 -0400 In-Reply-To: <83ha5ztyom.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 11 Apr 2014 23:10:17 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-DIRO-MailScanner-Information: Please contact the ISP for more information X-DIRO-MailScanner: Found to be clean X-DIRO-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=-2.82, requis 5, autolearn=not spam, ALL_TRUSTED -2.82, MC_TSTLAST 0.00) X-DIRO-MailScanner-From: monnier@iro.umontreal.ca X-Spam-Status: No X-Spam-Score: -2.7 (--) X-Debbugs-Envelope-To: 17215 Cc: 17215@debbugs.gnu.org, Daniel Colascione , dak@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.7 (--) > 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 From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 11 16:58:24 2014 Received: (at 17215) by debbugs.gnu.org; 11 Apr 2014 20:58:24 +0000 Received: from localhost ([127.0.0.1]:45728 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WYiWl-00009j-JJ for submit@debbugs.gnu.org; Fri, 11 Apr 2014 16:58:24 -0400 Received: from fencepost.gnu.org ([208.118.235.10]:35856 ident=Debian-exim) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WYiWj-00009Z-BQ for 17215@debbugs.gnu.org; Fri, 11 Apr 2014 16:58:21 -0400 Received: from localhost ([127.0.0.1]:43161 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WYiWi-0005I0-10; Fri, 11 Apr 2014 16:58:20 -0400 Received: by lola (Postfix, from userid 1000) id 794FCE0531; Fri, 11 Apr 2014 22:58:19 +0200 (CEST) From: David Kastrup To: Stefan Monnier Subject: Re: bug#17215: Acknowledgement (Build failure) References: <871tx9k1dy.fsf@fencepost.gnu.org> <87ioqfdfuw.fsf@fencepost.gnu.org> <53483E5E.8020705@dancol.org> Date: Fri, 11 Apr 2014 22:58:19 +0200 In-Reply-To: (Stefan Monnier's message of "Fri, 11 Apr 2014 16:11:58 -0400") Message-ID: <87a9brd1n8.fsf@fencepost.gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -5.4 (-----) X-Debbugs-Envelope-To: 17215 Cc: 17215@debbugs.gnu.org, Daniel Colascione X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.4 (-----) Stefan Monnier 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 From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 11 17:35:12 2014 Received: (at 17215) by debbugs.gnu.org; 11 Apr 2014 21:35:12 +0000 Received: from localhost ([127.0.0.1]:45776 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WYj6L-0001EU-JW for submit@debbugs.gnu.org; Fri, 11 Apr 2014 17:35:11 -0400 Received: from dancol.org ([96.126.100.184]:42752) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WYj6I-0001EK-9z for 17215@debbugs.gnu.org; Fri, 11 Apr 2014 17:35:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=vp0DwkFwK0lDQe0X7ZgB9/RL/NXnY71Jj+aTmcMvyPg=; b=hVX1hpk7x7rFi5ZiLXdqtF4IU8cVAKIUaU52UFmwREwNDxj3UBZHX6oMfLp1xEwVaYcRYUzXVi78F/EsYfA40g/7WvCtL2xvdvezs+JlaMXfh+JUsmtoCCmI5pMmrKjRzqK+mwulhJrrtCM0GDAJULFJ/IF32T4Bae23uK0iM6J1aQjb8Ca53S6DIJh9TjJH2ayUci+h/s5SWIWRdsDd1ccVp3pQpuVR4j3FvLcBPkWOHQIl71k4vsqwZJ0J+mzbZqG1F1bwmKtJhh+pE6PuyqGjEneNtqqyuldkzjIVhRxWn1idU1qawf5yh+E3rHsFahqbrRU326wTrqpIVAaVBQ==; Received: from [2620:0:1cfe:a1:2b5:6dff:fe00:f9a6] by dancol.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1WYj6F-0000oQ-Tk; Fri, 11 Apr 2014 14:35:03 -0700 Message-ID: <53485FFF.3050301@dancol.org> Date: Fri, 11 Apr 2014 14:34:55 -0700 From: Daniel Colascione User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: David Kastrup , Stefan Monnier Subject: Re: bug#17215: Acknowledgement (Build failure) References: <871tx9k1dy.fsf@fencepost.gnu.org> <87ioqfdfuw.fsf@fencepost.gnu.org> <53483E5E.8020705@dancol.org> <87a9brd1n8.fsf@fencepost.gnu.org> In-Reply-To: <87a9brd1n8.fsf@fencepost.gnu.org> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="hKkGdGDFTcGugJEIhLs8ReUldcu6W48UB" X-Spam-Score: -0.4 (/) X-Debbugs-Envelope-To: 17215 Cc: 17215@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.4 (/) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --hKkGdGDFTcGugJEIhLs8ReUldcu6W48UB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 04/11/2014 01:58 PM, David Kastrup wrote: > Stefan Monnier writes: >=20 >>>> It would appear that this particular bug yielded to the pure size >>>> increase. What a singularly useless error behavior for a problem th= at >>>> is expected to reoccur with some regularity! >>> Still waiting to hear a response to my previous question on why we do= n'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 t= o >> just abort. >=20 > 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. --hKkGdGDFTcGugJEIhLs8ReUldcu6W48UB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTSGAAAAoJEMAaIROpHW7IO5kQAMVf+PYiJI7/jy7FmdESLtvM Hm71zloob6oOYDRKojj8umXDbCu1toNzy+nt3M37KysKeYH8wL+arAsRX4Qr9VC5 9UHMNGgbnhRh6ZQr0Eni7yr1aBdfEVxCcpDq14bnh/29yZaJrczVuAK92/ny4Hx2 tFsNYYY5k37EN77rMqKdDOqLydswnn+b8cca53gGwTjlYrsCUv+EtALBqfsO1/dg 1UnBm9Qktqa2lsTW1qYhFfq/eP7Lb79zjJ2ClpIDU+NhzmE+CNqFxkyrn8rFDXA4 IN2kLANxc42m6ssa3l97W5u9MkpfCNDsP4CNrmMY7stdB4Q4rvu4wlztPPVbN/wq HtUyDqMqwVChArF7frqu/atAlb6Aj0H2aB7VX1ttUA7n+RMl54PeaXQ52kvOpzeZ qHaKH9D9APYfYYfd/t16u1hLZVV05V/Fljvcn6kHpkBXvklGL7zeUjXlDHSqPlYl 2atSPsX/WpabGzBXTJEnFiHziG2mr6a/5eAjj9IrLMk36nYUgJoH+7YjNGvSbJM0 LXphefSP2ZmsYoPVonmb6nUMOHyIv4uULcWhDpzdbL2kPjBxFPXy2HmsrvIEkvrv VNd83Rh9NmWaVqEv3jdO3vNO/V/P/sbL7LBQQ/a5ZDMBIJPLYyqWdkIbwOVmypSM wEaPKCROHr4D9vi8c4hx =TF4N -----END PGP SIGNATURE----- --hKkGdGDFTcGugJEIhLs8ReUldcu6W48UB-- From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 12 04:35:15 2014 Received: (at 17215) by debbugs.gnu.org; 12 Apr 2014 08:35:15 +0000 Received: from localhost ([127.0.0.1]:45997 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WYtP8-00048v-0o for submit@debbugs.gnu.org; Sat, 12 Apr 2014 04:35:14 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]:46570) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WYtP4-00048Z-1Q for 17215@debbugs.gnu.org; Sat, 12 Apr 2014 04:35:11 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0N3W00300SY3L900@a-mtaout22.012.net.il> for 17215@debbugs.gnu.org; Sat, 12 Apr 2014 11:35:03 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N3W003OET6EHX30@a-mtaout22.012.net.il>; Sat, 12 Apr 2014 11:35:03 +0300 (IDT) Date: Sat, 12 Apr 2014 11:35:06 +0300 From: Eli Zaretskii Subject: Re: bug#17215: Acknowledgement (Build failure) In-reply-to: X-012-Sender: halo1@inter.net.il To: Stefan Monnier Message-id: <837g6vt079.fsf@gnu.org> References: <871tx9k1dy.fsf@fencepost.gnu.org> <87ioqfdfuw.fsf@fencepost.gnu.org> <53483E5E.8020705@dancol.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 17215 Cc: 17215@debbugs.gnu.org, dancol@dancol.org, dak@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Stefan Monnier > Date: Fri, 11 Apr 2014 16:11:58 -0400 > Cc: 17215@debbugs.gnu.org, 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. 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. From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 12 09:20:05 2014 Received: (at 17215) by debbugs.gnu.org; 12 Apr 2014 13:20:05 +0000 Received: from localhost ([127.0.0.1]:46095 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WYxqm-0005DM-Qn for submit@debbugs.gnu.org; Sat, 12 Apr 2014 09:20:05 -0400 Received: from chene.dit.umontreal.ca ([132.204.246.20]:40278) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WYxqj-0005Cp-OY for 17215@debbugs.gnu.org; Sat, 12 Apr 2014 09:20:02 -0400 Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id s3CDJvgX023773; Sat, 12 Apr 2014 09:19:57 -0400 Received: by pastel.home (Postfix, from userid 20848) id 4575860228; Sat, 12 Apr 2014 09:19:57 -0400 (EDT) From: Stefan Monnier To: Daniel Colascione Subject: Re: bug#17215: Acknowledgement (Build failure) Message-ID: References: <871tx9k1dy.fsf@fencepost.gnu.org> <87ioqfdfuw.fsf@fencepost.gnu.org> <53483E5E.8020705@dancol.org> <87a9brd1n8.fsf@fencepost.gnu.org> <53485FFF.3050301@dancol.org> Date: Sat, 12 Apr 2014 09:19:57 -0400 In-Reply-To: <53485FFF.3050301@dancol.org> (Daniel Colascione's message of "Fri, 11 Apr 2014 14:34:55 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV4910=0 X-NAI-Spam-Version: 2.3.0.9378 : core <4910> : inlines <726> : streams <1157498> : uri <1727338> X-Spam-Score: -1.7 (-) X-Debbugs-Envelope-To: 17215 Cc: 17215@debbugs.gnu.org, David Kastrup X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) >>> 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 From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 12 09:21:23 2014 Received: (at 17215) by debbugs.gnu.org; 12 Apr 2014 13:21:23 +0000 Received: from localhost ([127.0.0.1]:46099 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WYxs2-0005Fm-BK for submit@debbugs.gnu.org; Sat, 12 Apr 2014 09:21:22 -0400 Received: from pruche.dit.umontreal.ca ([132.204.246.22]:55071) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WYxrz-0005Fc-QY for 17215@debbugs.gnu.org; Sat, 12 Apr 2014 09:21:20 -0400 Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id s3CDLFLn028867; Sat, 12 Apr 2014 09:21:15 -0400 Received: by pastel.home (Postfix, from userid 20848) id 3A12360228; Sat, 12 Apr 2014 09:21:15 -0400 (EDT) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#17215: Acknowledgement (Build failure) Message-ID: References: <871tx9k1dy.fsf@fencepost.gnu.org> <87ioqfdfuw.fsf@fencepost.gnu.org> <53483E5E.8020705@dancol.org> <837g6vt079.fsf@gnu.org> Date: Sat, 12 Apr 2014 09:21:15 -0400 In-Reply-To: <837g6vt079.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 12 Apr 2014 11:35:06 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV4910=0 X-NAI-Spam-Version: 2.3.0.9378 : core <4910> : inlines <726> : streams <1157500> : uri <1727339> X-Spam-Score: -1.7 (-) X-Debbugs-Envelope-To: 17215 Cc: 17215@debbugs.gnu.org, dancol@dancol.org, dak@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > 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 From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 12 10:18:40 2014 Received: (at 17215) by debbugs.gnu.org; 12 Apr 2014 14:18:41 +0000 Received: from localhost ([127.0.0.1]:46301 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WYylU-0006oZ-6B for submit@debbugs.gnu.org; Sat, 12 Apr 2014 10:18:40 -0400 Received: from mtaout26.012.net.il ([80.179.55.182]:36955) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WYylQ-0006oF-LZ for 17215@debbugs.gnu.org; Sat, 12 Apr 2014 10:18:38 -0400 Received: from conversion-daemon.mtaout26.012.net.il by mtaout26.012.net.il (HyperSendmail v2007.08) id <0N3X00O0089V4N00@mtaout26.012.net.il> for 17215@debbugs.gnu.org; Sat, 12 Apr 2014 17:16:49 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout26.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N3X001KJ901F000@mtaout26.012.net.il>; Sat, 12 Apr 2014 17:16:49 +0300 (IDT) Date: Sat, 12 Apr 2014 17:18:29 +0300 From: Eli Zaretskii Subject: Re: bug#17215: Acknowledgement (Build failure) In-reply-to: X-012-Sender: halo1@inter.net.il To: Stefan Monnier Message-id: <831tx2tyve.fsf@gnu.org> References: <871tx9k1dy.fsf@fencepost.gnu.org> <87ioqfdfuw.fsf@fencepost.gnu.org> <53483E5E.8020705@dancol.org> <837g6vt079.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 17215 Cc: 17215@debbugs.gnu.org, dancol@dancol.org, dak@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Stefan Monnier > 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? From unknown Tue Aug 19 21:52:50 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sun, 11 May 2014 11:24:03 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator