GNU bug report logs - #17215
Build failure

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 17215 in the body.
You can then email your comments to 17215 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: David Kastrup <dak <at> gnu.org>
To: bug-emacs <at> gnu.org
Subject: Build failure
Date: Mon, 07 Apr 2014 10:08:25 +0200

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

Message #8 received at 17215 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: David Kastrup <dak <at> gnu.org>
Cc: 17215 <at> debbugs.gnu.org
Subject: Re: bug#17215: Build failure
Date: Mon, 07 Apr 2014 16:47:20 -0400

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

Message #11 received at 17215 <at> debbugs.gnu.org (full text, mbox):

From: David Kastrup <dak <at> gnu.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 17215 <at> debbugs.gnu.org
Subject: Re: bug#17215: Build failure
Date: Tue, 08 Apr 2014 12:42:39 +0200

Glenn Morris <rgm <at> gnu.org> writes:

> David Kastrup wrote:
>
>> Any more information that you need?
>
> Please run addr2line as described in info node `Crashing'.
> Or get a backtrace from gdb.
>
> (But I'm going to guess that this is just
> http://debbugs.gnu.org/17178 aka 17168 again.)

With regard to relating to the other bug: I reverted the respective part
in subr.el of (git commit)

commit 099c333d57a88bf1ea2fee992c721225608303c9
Author: Richard Stallman <>
Date:   Wed Apr 2 13:21:34 2014 -0400

    Revert subr.el workaround for GC bug.
    
    * subr.el (set-transient-map): Comment out previous change.

But "make bootstrap" crashed at the same point, and lisp/subr.elc has a
modification date later than lisp/subr.el when the crash occurs.  Just
to be sure, I cleaned out the build directory and made a "make
distclean", then tried again.

Same outcome.  So at least this "workaround" does not apply to this
bug.  Here is a backtrace from the corresponding core dump (namely the
core dump of master from yesterday, with the revert of Richard's revert
on top):

#0  0x40022424 in __kernel_vsyscall ()
#1  0x416b60c6 in raise (sig=sig <at> entry=6)
    at ../nptl/sysdeps/unix/sysv/linux/pt-raise.c:37
#2  0x08120099 in terminate_due_to_signal (sig=sig <at> entry=6, 
    backtrace_limit=backtrace_limit <at> 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 <at> entry=1028, nargs=nargs <at> entry=1, 
    args=0xbfd90b98) at ../../emacs/src/bytecode.c:1322
#6  0x0818d79e in funcall_lambda (fun=178833477, nargs=nargs <at> entry=1, 
    arg_vector=arg_vector <at> 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 <at> entry=2056, nargs=nargs <at> entry=2, 
    args=0xbfd90d34) at ../../emacs/src/bytecode.c:919
#9  0x0818d79e in funcall_lambda (fun=fun <at> entry=137210677, 
    nargs=nargs <at> entry=2, arg_vector=arg_vector <at> entry=0xbfd90e70)
    at ../../emacs/src/eval.c:2983
#10 0x0818cc8c in apply_lambda (fun=<optimized out>, args=<optimized out>)
    at ../../emacs/src/eval.c:2924
#11 0x0818cfa4 in eval_sub (form=178737886) at ../../emacs/src/eval.c:2260
#12 0x0818d4a6 in Fprogn (body=178737910) at ../../emacs/src/eval.c:468
#13 0x0818c9d7 in unbind_to (count=count <at> 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 <at> entry=178735966, 
    nargs=nargs <at> entry=4, arg_vector=arg_vector <at> entry=0xbfd911e0)
    at ../../emacs/src/eval.c:3042
#21 0x0818cc8c in apply_lambda (fun=<optimized out>, args=<optimized out>)
    at ../../emacs/src/eval.c:2924
#22 0x0818cfa4 in eval_sub (form=178768494) at ../../emacs/src/eval.c:2260
#23 0x0818d28e in eval_sub (form=178768438) at ../../emacs/src/eval.c:2133
#24 0x0818fd33 in FletX (args=178802726) at ../../emacs/src/eval.c:881
#25 0x0818d28e in eval_sub (form=178802734) at ../../emacs/src/eval.c:2133
#26 0x0818d4a6 in Fprogn (body=178802774) at ../../emacs/src/eval.c:468
#27 0x0818d80f in funcall_lambda (fun=178802974, nargs=nargs <at> entry=4, 
    arg_vector=arg_vector <at> entry=0xbfd91514) at ../../emacs/src/eval.c:3042
#28 0x0818da53 in Ffuncall (nargs=5, args=args <at> entry=0xbfd91510)
    at ../../emacs/src/eval.c:2876
#29 0x0818ee5b in Fapply (nargs=nargs <at> entry=2, args=args <at> entry=0xbfd915a8)
    at ../../emacs/src/eval.c:2354
#30 0x0818f08f in apply1 (fn=178802982, arg=177536782)
    at ../../emacs/src/eval.c:2588
#31 0x0818f620 in Fmacroexpand (form=<optimized out>, environment=138922946)
    at ../../emacs/src/eval.c:1066
#32 0x0818dc70 in Ffuncall (nargs=3, args=0xbfd9166c)
    at ../../emacs/src/eval.c:2818
#33 0x081c07c3 in exec_byte_code (bytestr=0, vector=6, maxdepth=108, 
    args_template=args_template <at> entry=1028, nargs=nargs <at> entry=1, 
    args=0xbfd91668) at ../../emacs/src/bytecode.c:919
#34 0x0818d79e in funcall_lambda (fun=137023429, nargs=nargs <at> entry=1, 
    arg_vector=arg_vector <at> 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 <at> entry=2052, nargs=nargs <at> entry=2, 
    args=0xbfd9186c) at ../../emacs/src/bytecode.c:919
#37 0x0818d79e in funcall_lambda (fun=137022557, nargs=nargs <at> entry=2, 
    arg_vector=arg_vector <at> 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 <at> entry=2056, nargs=nargs <at> entry=2, 
    args=0xbfd91a0c) at ../../emacs/src/bytecode.c:919
#40 0x0818d79e in funcall_lambda (fun=137023621, nargs=nargs <at> entry=2, 
    arg_vector=arg_vector <at> 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 <at> entry=1028, nargs=nargs <at> entry=1, 
    args=0xbfd91bb8) at ../../emacs/src/bytecode.c:919
#43 0x0818d79e in funcall_lambda (fun=137023429, nargs=nargs <at> entry=1, 
    arg_vector=arg_vector <at> 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 <at> entry=2052, nargs=nargs <at> entry=2, 
    args=0xbfd91dbc) at ../../emacs/src/bytecode.c:919
#46 0x0818d79e in funcall_lambda (fun=137022557, nargs=nargs <at> entry=2, 
    arg_vector=arg_vector <at> 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 <at> entry=2056, nargs=nargs <at> entry=2, 
    args=0xbfd91f5c) at ../../emacs/src/bytecode.c:919
#49 0x0818d79e in funcall_lambda (fun=137023621, nargs=nargs <at> entry=2, 
    arg_vector=arg_vector <at> 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 <at> entry=1028, nargs=nargs <at> entry=1, 
    args=0xbfd92108) at ../../emacs/src/bytecode.c:919
#52 0x0818d79e in funcall_lambda (fun=137023429, nargs=nargs <at> entry=1, 
    arg_vector=arg_vector <at> 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 <at> entry=2052, nargs=nargs <at> entry=1, 
    args=0xbfd922f8) at ../../emacs/src/bytecode.c:919
#55 0x0818d79e in funcall_lambda (fun=137024085, nargs=nargs <at> entry=1, 
    arg_vector=arg_vector <at> 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 <at> entry=0, nargs=nargs <at> entry=0, args=0xbfd92490)
    at ../../emacs/src/bytecode.c:919
#58 0x0818d79e in funcall_lambda (fun=177520389, nargs=nargs <at> entry=0, 
    arg_vector=arg_vector <at> entry=0xbfd92634) at ../../emacs/src/eval.c:2983
#59 0x0818da53 in Ffuncall (nargs=1, args=0xbfd92630)
    at ../../emacs/src/eval.c:2876
#60 0x0818d350 in eval_sub (form=177535262) at ../../emacs/src/eval.c:2157
#61 0x081903eb in internal_lisp_condition_case (var=140664170, 
    bodyform=<optimized out>, handlers=<optimized out>)
    at ../../emacs/src/eval.c:1323
#62 0x081c1d9d in exec_byte_code (bytestr=0, vector=6, maxdepth=44, 
    args_template=args_template <at> entry=1028, nargs=nargs <at> entry=1, 
    args=0xbfd92748) at ../../emacs/src/bytecode.c:1169
#63 0x0818d79e in funcall_lambda (fun=137025397, nargs=nargs <at> entry=1, 
    arg_vector=arg_vector <at> entry=0xbfd928fc) at ../../emacs/src/eval.c:2983
#64 0x0818da53 in Ffuncall (nargs=nargs <at> entry=2, args=args <at> entry=0xbfd928f8)
    at ../../emacs/src/eval.c:2876
#65 0x0818dde7 in call1 (fn=fn <at> entry=139083706, arg1=arg1 <at> entry=177536726)
    at ../../emacs/src/eval.c:2614
#66 0x081aef73 in readevalloop (readcharfun=readcharfun <at> entry=176865173, 
    stream=stream <at> entry=0x0, sourcename=176867369, sourcename <at> entry=176966881, 
    printflag=false, unibyte=unibyte <at> 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 <at> entry=0, args=0xbfd92a2c)
    at ../../emacs/src/bytecode.c:919
#70 0x0818d71d in funcall_lambda (fun=136878341, nargs=nargs <at> entry=4, 
    arg_vector=arg_vector <at> entry=0xbfd92bd0) at ../../emacs/src/eval.c:3049
#71 0x0818da53 in Ffuncall (nargs=nargs <at> entry=5, args=args <at> entry=0xbfd92bcc)
    at ../../emacs/src/eval.c:2876
#72 0x0818f6ef in call4 (fn=140760930, arg1=arg1 <at> entry=176966881, 
    arg2=arg2 <at> entry=176966881, arg3=138922946, arg4=138922970)
    at ../../emacs/src/eval.c:2663
#73 0x081afd85 in Fload (file=176966257, noerror=noerror <at> entry=138922946, 
    nomessage=138922970, nosuffix=nosuffix <at> 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 <at> entry=176939310)
    at ../../emacs/src/eval.c:2191
#76 0x081aef7d in readevalloop (readcharfun=readcharfun <at> entry=176849653, 
    stream=stream <at> entry=0x0, sourcename=176854193, sourcename <at> entry=176848697, 
    printflag=false, unibyte=unibyte <at> 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 <at> entry=0, args=0xbfd92efc)
    at ../../emacs/src/bytecode.c:919
#80 0x0818d71d in funcall_lambda (fun=136878341, nargs=nargs <at> entry=4, 
    arg_vector=arg_vector <at> entry=0xbfd930a0) at ../../emacs/src/eval.c:3049
#81 0x0818da53 in Ffuncall (nargs=nargs <at> entry=5, args=args <at> entry=0xbfd9309c)
    at ../../emacs/src/eval.c:2876
#82 0x0818f6ef in call4 (fn=140760930, arg1=arg1 <at> entry=176848697, 
    arg2=arg2 <at> entry=176848697, arg3=138922946, arg4=138922970)
    at ../../emacs/src/eval.c:2663
#83 0x081afd85 in Fload (file=176846033, noerror=noerror <at> entry=138922946, 
    nomessage=138922970, nosuffix=nosuffix <at> 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 <at> entry=2, args=args <at> 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 <at> entry=1028, nargs=nargs <at> entry=1, args=0x1)
    at ../../emacs/src/bytecode.c:919
#89 0x0818d79e in funcall_lambda (fun=142657717, nargs=nargs <at> entry=1, 
    arg_vector=arg_vector <at> 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 <at> entry=1028, nargs=nargs <at> entry=1, 
    args=0xbfd93518) at ../../emacs/src/bytecode.c:919
#92 0x0818d79e in funcall_lambda (fun=142653581, nargs=nargs <at> entry=1, 
    arg_vector=arg_vector <at> 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 <at> entry=1028, nargs=nargs <at> entry=1, 
    args=0xbfd936b4) at ../../emacs/src/bytecode.c:919
#95 0x0818d79e in funcall_lambda (fun=142653533, nargs=nargs <at> entry=1, 
    arg_vector=arg_vector <at> 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 <at> entry=0, nargs=nargs <at> entry=0, args=0xbfd93854)
    at ../../emacs/src/bytecode.c:919
#98 0x0818d79e in funcall_lambda (fun=141433917, nargs=nargs <at> entry=0, 
    arg_vector=arg_vector <at> 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 <at> entry=0, nargs=nargs <at> entry=0, args=0x0)
    at ../../emacs/src/bytecode.c:919
#101 0x0818d79e in funcall_lambda (fun=141433957, nargs=nargs <at> entry=0, 
    arg_vector=arg_vector <at> entry=0xbfd93b94) at ../../emacs/src/eval.c:2983
#102 0x0818da53 in Ffuncall (nargs=1, args=0xbfd93b90)
    at ../../emacs/src/eval.c:2876
#103 0x0818d350 in eval_sub (form=176799150) at ../../emacs/src/eval.c:2157
#104 0x081903eb in internal_lisp_condition_case (var=143193746, 
    bodyform=<optimized out>, handlers=<optimized out>)
    at ../../emacs/src/eval.c:1323
#105 0x081c1d9d in exec_byte_code (bytestr=0, vector=6, maxdepth=64, 
    args_template=args_template <at> entry=1028, nargs=nargs <at> entry=1, 
    args=0xbfd93cb0) at ../../emacs/src/bytecode.c:1169
#106 0x0818d79e in funcall_lambda (fun=142641333, nargs=nargs <at> entry=1, 
    arg_vector=arg_vector <at> 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 <at> entry=2052, nargs=nargs <at> entry=1, 
    args=0xbfd93e90) at ../../emacs/src/bytecode.c:919
#109 0x0818d79e in funcall_lambda (fun=142633061, nargs=nargs <at> entry=1, 
    arg_vector=arg_vector <at> 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 <at> entry=0, nargs=nargs <at> entry=0, args=0x0)
    at ../../emacs/src/bytecode.c:919
#112 0x0818d79e in funcall_lambda (fun=141761653, nargs=nargs <at> entry=0, 
    arg_vector=arg_vector <at> entry=0xbfd941e4) at ../../emacs/src/eval.c:2983
#113 0x0818da53 in Ffuncall (nargs=1, args=0xbfd941e0)
    at ../../emacs/src/eval.c:2876
#114 0x0818d350 in eval_sub (form=176800838) at ../../emacs/src/eval.c:2157
#115 0x081903eb in internal_lisp_condition_case (var=143549378, 
    bodyform=<optimized out>, handlers=<optimized out>)
    at ../../emacs/src/eval.c:1323
#116 0x081c1d9d in exec_byte_code (bytestr=0, vector=6, maxdepth=48, 
    args_template=args_template <at> entry=1028, nargs=nargs <at> entry=1, 
    args=0xbfd942f8) at ../../emacs/src/bytecode.c:1169
#117 0x0818d79e in funcall_lambda (fun=141723053, nargs=nargs <at> entry=1, 
    arg_vector=arg_vector <at> 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 <at> entry=1024, nargs=nargs <at> entry=0, 
    args=0xbfd944b8) at ../../emacs/src/bytecode.c:919
#120 0x0818d79e in funcall_lambda (fun=141725101, nargs=nargs <at> entry=0, 
    arg_vector=arg_vector <at> 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 <at> entry=1028, nargs=nargs <at> entry=1, 
    args=0xbfd94678) at ../../emacs/src/bytecode.c:919
#123 0x0818d79e in funcall_lambda (fun=137084413, nargs=nargs <at> entry=1, 
    arg_vector=arg_vector <at> 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 <at> entry=0, nargs=nargs <at> entry=0, 
    args=0x82b8ba4 <pure+288068>) at ../../emacs/src/bytecode.c:919
#126 0x0818d79e in funcall_lambda (fun=137071485, nargs=nargs <at> entry=0, 
    arg_vector=arg_vector <at> 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 <at> entry=0, nargs=nargs <at> entry=0, args=0xbfd94a14)
    at ../../emacs/src/bytecode.c:919
#129 0x0818d79e in funcall_lambda (fun=fun <at> entry=137069733, 
    nargs=nargs <at> entry=0, arg_vector=arg_vector <at> entry=0xbfd94b70)
    at ../../emacs/src/eval.c:2983
#130 0x0818cc8c in apply_lambda (fun=<optimized out>, args=<optimized out>)
    at ../../emacs/src/eval.c:2924
#131 0x0818cfa4 in eval_sub (form=form <at> 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 <at> entry=0x8120540 <top_level_2>, handlers=138956090, 
    hfun=hfun <at> entry=0x81249f0 <cmd_error>) at ../../emacs/src/eval.c:1354
#135 0x08120535 in top_level_1 (ignore=138922946)
    at ../../emacs/src/keyboard.c:1191
#136 0x0818c143 in internal_catch (tag=138954138, 
    func=func <at> entry=0x81204d0 <top_level_1>, arg=138922946)
    at ../../emacs/src/eval.c:1118
#137 0x08124624 in command_loop () at ../../emacs/src/keyboard.c:1152
#138 recursive_edit_1 () at ../../emacs/src/keyboard.c:777
#139 0x08124903 in Frecursive_edit () at ../../emacs/src/keyboard.c:845
#140 0x08059578 in main (argc=<optimized out>, argv=0xbfd94e44)
    at ../../emacs/src/emacs.c:1654

-- 
David Kastrup

Message #14 received at 17215 <at> debbugs.gnu.org (full text, mbox):

From: Daniel Colascione <dancol <at> dancol.org>
To: David Kastrup <dak <at> gnu.org>, Glenn Morris <rgm <at> gnu.org>
Cc: 17215 <at> debbugs.gnu.org
Subject: Re: bug#17215: Build failure
Date: Tue, 08 Apr 2014 03:50:49 -0700

[Message part 1 (text/plain, inline)]

On 04/08/2014 03:42 AM, David Kastrup wrote:
> Glenn Morris <rgm <at> gnu.org> writes:
> 
>> David Kastrup wrote:
>>
>>> Any more information that you need?
>>
>> Please run addr2line as described in info node `Crashing'.
>> Or get a backtrace from gdb.
>>
>> (But I'm going to guess that this is just
>> http://debbugs.gnu.org/17178 aka 17168 again.)
> 
> With regard to relating to the other bug: I reverted the respective part
> in subr.el of (git commit)

Try it with the current trunk.

[signature.asc (application/pgp-signature, attachment)]

Message #17 received at 17215 <at> debbugs.gnu.org (full text, mbox):

From: David Kastrup <dak <at> gnu.org>
To: Daniel Colascione <dancol <at> dancol.org>
Cc: Glenn Morris <rgm <at> gnu.org>, 17215 <at> debbugs.gnu.org
Subject: Re: bug#17215: Build failure
Date: Tue, 08 Apr 2014 13:36:30 +0200

Daniel Colascione <dancol <at> dancol.org> writes:

> On 04/08/2014 03:42 AM, David Kastrup wrote:
>> Glenn Morris <rgm <at> gnu.org> writes:
>> 
>>> David Kastrup wrote:
>>>
>>>> Any more information that you need?
>>>
>>> Please run addr2line as described in info node `Crashing'.
>>> Or get a backtrace from gdb.
>>>
>>> (But I'm going to guess that this is just
>>> http://debbugs.gnu.org/17178 aka 17168 again.)
>> 
>> With regard to relating to the other bug: I reverted the respective part
>> in subr.el of (git commit)
>
> Try it with the current trunk.

I am using the Git mirror.  Last commit is
commit 2da406808826326ea46e43f8187a0451d0ef5303
Author: Daniel Colascione <dancol <at> dancol.org>
Date:   Tue Apr 8 03:33:48 2014 -0700

    Tweak completion documentation

Still dumps core.  Looks pretty much the same to me:
#0  0x40022424 in __kernel_vsyscall ()
#1  0x416b60c6 in raise (sig=sig <at> entry=6)
    at ../nptl/sysdeps/unix/sysv/linux/pt-raise.c:37
#2  0x08120099 in terminate_due_to_signal (sig=sig <at> entry=6, 
    backtrace_limit=backtrace_limit <at> 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 <at> entry=1028, nargs=nargs <at> entry=1, 
    args=0xbfda3528) at ../../emacs/src/bytecode.c:1322
#6  0x0818d84e in funcall_lambda (fun=162440189, nargs=nargs <at> entry=1, 
    arg_vector=arg_vector <at> 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 <at> entry=2056, nargs=nargs <at> entry=2, 
    args=0xbfda36c4) at ../../emacs/src/bytecode.c:919
#9  0x0818d84e in funcall_lambda (fun=fun <at> entry=137210773, 
    nargs=nargs <at> entry=2, arg_vector=arg_vector <at> entry=0xbfda3800)
    at ../../emacs/src/eval.c:2983
#10 0x0818cd3c in apply_lambda (fun=<optimized out>, args=<optimized out>)
    at ../../emacs/src/eval.c:2924
#11 0x0818d054 in eval_sub (form=162401054) at ../../emacs/src/eval.c:2260
#12 0x0818d556 in Fprogn (body=162401078) at ../../emacs/src/eval.c:468
#13 0x0818ca87 in unbind_to (count=count <at> 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 <at> entry=162399134, 
    nargs=nargs <at> entry=4, arg_vector=arg_vector <at> entry=0xbfda3b70)
    at ../../emacs/src/eval.c:3042
#21 0x0818cd3c in apply_lambda (fun=<optimized out>, args=<optimized out>)
    at ../../emacs/src/eval.c:2924
#22 0x0818d054 in eval_sub (form=162422446) at ../../emacs/src/eval.c:2260
#23 0x0818d33e in eval_sub (form=162422390) at ../../emacs/src/eval.c:2133
#24 0x0818fde3 in FletX (args=162468966) at ../../emacs/src/eval.c:881
#25 0x0818d33e in eval_sub (form=162468974) at ../../emacs/src/eval.c:2133
#26 0x0818d556 in Fprogn (body=162469014) at ../../emacs/src/eval.c:468
#27 0x0818d8bf in funcall_lambda (fun=162469214, nargs=nargs <at> entry=4, 
    arg_vector=arg_vector <at> entry=0xbfda3ea4) at ../../emacs/src/eval.c:3042
#28 0x0818db03 in Ffuncall (nargs=5, args=args <at> entry=0xbfda3ea0)
    at ../../emacs/src/eval.c:2876
#29 0x0818ef0b in Fapply (nargs=nargs <at> entry=2, args=args <at> entry=0xbfda3f38)
    at ../../emacs/src/eval.c:2354
#30 0x0818f13f in apply1 (fn=162469222, arg=161192782)
    at ../../emacs/src/eval.c:2588
#31 0x0818f6d0 in Fmacroexpand (form=<optimized out>, environment=138922946)
    at ../../emacs/src/eval.c:1066
#32 0x0818dd20 in Ffuncall (nargs=3, args=0xbfda3ffc)
    at ../../emacs/src/eval.c:2818
#33 0x081c0873 in exec_byte_code (bytestr=0, vector=6, maxdepth=108, 
    args_template=args_template <at> entry=1028, nargs=nargs <at> entry=1, 
    args=0xbfda3ff8) at ../../emacs/src/bytecode.c:919
#34 0x0818d84e in funcall_lambda (fun=137023405, nargs=nargs <at> entry=1, 
    arg_vector=arg_vector <at> 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 <at> entry=2052, nargs=nargs <at> entry=2, 
    args=0xbfda41fc) at ../../emacs/src/bytecode.c:919
#37 0x0818d84e in funcall_lambda (fun=137022533, nargs=nargs <at> entry=2, 
    arg_vector=arg_vector <at> 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 <at> entry=2056, nargs=nargs <at> entry=2, 
    args=0xbfda439c) at ../../emacs/src/bytecode.c:919
#40 0x0818d84e in funcall_lambda (fun=137023597, nargs=nargs <at> entry=2, 
    arg_vector=arg_vector <at> 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 <at> entry=1028, nargs=nargs <at> entry=1, 
    args=0xbfda4548) at ../../emacs/src/bytecode.c:919
#43 0x0818d84e in funcall_lambda (fun=137023405, nargs=nargs <at> entry=1, 
    arg_vector=arg_vector <at> 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 <at> entry=2052, nargs=nargs <at> entry=2, 
    args=0xbfda474c) at ../../emacs/src/bytecode.c:919
#46 0x0818d84e in funcall_lambda (fun=137022533, nargs=nargs <at> entry=2, 
    arg_vector=arg_vector <at> 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 <at> entry=2056, nargs=nargs <at> entry=2, 
    args=0xbfda48ec) at ../../emacs/src/bytecode.c:919
#49 0x0818d84e in funcall_lambda (fun=137023597, nargs=nargs <at> entry=2, 
    arg_vector=arg_vector <at> 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 <at> entry=1028, nargs=nargs <at> entry=1, 
    args=0xbfda4a98) at ../../emacs/src/bytecode.c:919
#52 0x0818d84e in funcall_lambda (fun=137023405, nargs=nargs <at> entry=1, 
    arg_vector=arg_vector <at> 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 <at> entry=2052, nargs=nargs <at> entry=1, 
    args=0xbfda4c88) at ../../emacs/src/bytecode.c:919
#55 0x0818d84e in funcall_lambda (fun=137024061, nargs=nargs <at> entry=1, 
    arg_vector=arg_vector <at> 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 <at> entry=0, nargs=nargs <at> entry=0, args=0xbfda4e20)
    at ../../emacs/src/bytecode.c:919
#58 0x0818d84e in funcall_lambda (fun=161202149, nargs=nargs <at> entry=0, 
    arg_vector=arg_vector <at> entry=0xbfda4fc4) at ../../emacs/src/eval.c:2983
#59 0x0818db03 in Ffuncall (nargs=1, args=0xbfda4fc0)
    at ../../emacs/src/eval.c:2876
#60 0x0818d400 in eval_sub (form=161191262) at ../../emacs/src/eval.c:2157
#61 0x0819049b in internal_lisp_condition_case (var=140664170, 
    bodyform=<optimized out>, handlers=<optimized out>)
    at ../../emacs/src/eval.c:1323
#62 0x081c1e4d in exec_byte_code (bytestr=0, vector=6, maxdepth=44, 
    args_template=args_template <at> entry=1028, nargs=nargs <at> entry=1, 
    args=0xbfda50d8) at ../../emacs/src/bytecode.c:1169
#63 0x0818d84e in funcall_lambda (fun=137025373, nargs=nargs <at> entry=1, 
    arg_vector=arg_vector <at> entry=0xbfda528c) at ../../emacs/src/eval.c:2983
#64 0x0818db03 in Ffuncall (nargs=nargs <at> entry=2, args=args <at> entry=0xbfda5288)
    at ../../emacs/src/eval.c:2876
#65 0x0818de97 in call1 (fn=fn <at> entry=139083706, arg1=arg1 <at> entry=161192726)
    at ../../emacs/src/eval.c:2614
#66 0x081af023 in readevalloop (readcharfun=readcharfun <at> entry=160515237, 
    stream=stream <at> entry=0x0, sourcename=160526257, sourcename <at> entry=160514841, 
    printflag=false, unibyte=unibyte <at> 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 <at> entry=0, args=0xbfda53bc)
    at ../../emacs/src/bytecode.c:919
#70 0x0818d7cd in funcall_lambda (fun=136878341, nargs=nargs <at> entry=4, 
    arg_vector=arg_vector <at> entry=0xbfda5560) at ../../emacs/src/eval.c:3049
#71 0x0818db03 in Ffuncall (nargs=nargs <at> entry=5, args=args <at> entry=0xbfda555c)
    at ../../emacs/src/eval.c:2876
#72 0x0818f79f in call4 (fn=140760930, arg1=arg1 <at> entry=160514841, 
    arg2=arg2 <at> entry=160514841, arg3=138922946, arg4=138922970)
    at ../../emacs/src/eval.c:2663
#73 0x081afe35 in Fload (file=160514217, noerror=noerror <at> entry=138922946, 
    nomessage=138922970, nosuffix=nosuffix <at> 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 <at> entry=160597358)
    at ../../emacs/src/eval.c:2191
#76 0x081af02d in readevalloop (readcharfun=readcharfun <at> entry=160498701, 
    stream=stream <at> entry=0x0, sourcename=160512097, sourcename <at> entry=160496369, 
    printflag=false, unibyte=unibyte <at> 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 <at> entry=0, args=0xbfda588c)
    at ../../emacs/src/bytecode.c:919
#80 0x0818d7cd in funcall_lambda (fun=136878341, nargs=nargs <at> entry=4, 
    arg_vector=arg_vector <at> entry=0xbfda5a30) at ../../emacs/src/eval.c:3049
#81 0x0818db03 in Ffuncall (nargs=nargs <at> entry=5, args=args <at> entry=0xbfda5a2c)
    at ../../emacs/src/eval.c:2876
#82 0x0818f79f in call4 (fn=140760930, arg1=arg1 <at> entry=160496369, 
    arg2=arg2 <at> entry=160496369, arg3=138922946, arg4=138922970)
    at ../../emacs/src/eval.c:2663
#83 0x081afe35 in Fload (file=160495745, noerror=noerror <at> entry=138922946, 
    nomessage=138922970, nosuffix=nosuffix <at> 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 <at> entry=2, args=args <at> 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 <at> entry=1028, nargs=nargs <at> entry=1, args=0x1)
    at ../../emacs/src/bytecode.c:919
#89 0x0818d84e in funcall_lambda (fun=141717197, nargs=nargs <at> entry=1, 
    arg_vector=arg_vector <at> 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 <at> entry=1028, nargs=nargs <at> entry=1, 
    args=0xbfda5ea8) at ../../emacs/src/bytecode.c:919
#92 0x0818d84e in funcall_lambda (fun=141675541, nargs=nargs <at> entry=1, 
    arg_vector=arg_vector <at> 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 <at> entry=1028, nargs=nargs <at> entry=1, 
    args=0xbfda6044) at ../../emacs/src/bytecode.c:919
#95 0x0818d84e in funcall_lambda (fun=141675493, nargs=nargs <at> entry=1, 
    arg_vector=arg_vector <at> 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 <at> entry=0, nargs=nargs <at> entry=0, args=0xbfda61e4)
    at ../../emacs/src/bytecode.c:919
#98 0x0818d84e in funcall_lambda (fun=143074821, nargs=nargs <at> entry=0, 
    arg_vector=arg_vector <at> 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 <at> entry=0, nargs=nargs <at> entry=0, args=0x0)
    at ../../emacs/src/bytecode.c:919
#101 0x0818d84e in funcall_lambda (fun=143074861, nargs=nargs <at> entry=0, 
    arg_vector=arg_vector <at> entry=0xbfda6524) at ../../emacs/src/eval.c:2983
#102 0x0818db03 in Ffuncall (nargs=1, args=0xbfda6520)
    at ../../emacs/src/eval.c:2876
#103 0x0818d400 in eval_sub (form=160449006) at ../../emacs/src/eval.c:2157
#104 0x0819049b in internal_lisp_condition_case (var=143210426, 
    bodyform=<optimized out>, handlers=<optimized out>)
    at ../../emacs/src/eval.c:1323
#105 0x081c1e4d in exec_byte_code (bytestr=0, vector=6, maxdepth=64, 
    args_template=args_template <at> entry=1028, nargs=nargs <at> entry=1, 
    args=0xbfda6640) at ../../emacs/src/bytecode.c:1169
#106 0x0818d84e in funcall_lambda (fun=141552629, nargs=nargs <at> entry=1, 
    arg_vector=arg_vector <at> 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 <at> entry=2052, nargs=nargs <at> entry=1, 
    args=0xbfda6820) at ../../emacs/src/bytecode.c:919
#109 0x0818d84e in funcall_lambda (fun=140938653, nargs=nargs <at> entry=1, 
    arg_vector=arg_vector <at> 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 <at> entry=0, nargs=nargs <at> entry=0, args=0x0)
    at ../../emacs/src/bytecode.c:919
#112 0x0818d84e in funcall_lambda (fun=142078949, nargs=nargs <at> entry=0, 
    arg_vector=arg_vector <at> entry=0xbfda6b74) at ../../emacs/src/eval.c:2983
#113 0x0818db03 in Ffuncall (nargs=1, args=0xbfda6b70)
    at ../../emacs/src/eval.c:2876
#114 0x0818d400 in eval_sub (form=160450694) at ../../emacs/src/eval.c:2157
#115 0x0819049b in internal_lisp_condition_case (var=143563674, 
    bodyform=<optimized out>, handlers=<optimized out>)
    at ../../emacs/src/eval.c:1323
#116 0x081c1e4d in exec_byte_code (bytestr=0, vector=6, maxdepth=48, 
    args_template=args_template <at> entry=1028, nargs=nargs <at> entry=1, 
    args=0xbfda6c88) at ../../emacs/src/bytecode.c:1169
#117 0x0818d84e in funcall_lambda (fun=142178453, nargs=nargs <at> entry=1, 
    arg_vector=arg_vector <at> 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 <at> entry=1024, nargs=nargs <at> entry=0, 
    args=0xbfda6e48) at ../../emacs/src/bytecode.c:919
#120 0x0818d84e in funcall_lambda (fun=142178429, nargs=nargs <at> entry=0, 
    arg_vector=arg_vector <at> 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 <at> entry=1028, nargs=nargs <at> entry=1, 
    args=0xbfda7008) at ../../emacs/src/bytecode.c:919
#123 0x0818d84e in funcall_lambda (fun=137084509, nargs=nargs <at> entry=1, 
    arg_vector=arg_vector <at> 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 <at> entry=0, nargs=nargs <at> entry=0, 
    args=0x82b8c04 <pure+288164>) at ../../emacs/src/bytecode.c:919
#126 0x0818d84e in funcall_lambda (fun=137071581, nargs=nargs <at> entry=0, 
    arg_vector=arg_vector <at> 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 <at> entry=0, nargs=nargs <at> entry=0, args=0xbfda73a4)
    at ../../emacs/src/bytecode.c:919
#129 0x0818d84e in funcall_lambda (fun=fun <at> entry=137069829, 
    nargs=nargs <at> entry=0, arg_vector=arg_vector <at> entry=0xbfda7500)
    at ../../emacs/src/eval.c:2983
#130 0x0818cd3c in apply_lambda (fun=<optimized out>, args=<optimized out>)
    at ../../emacs/src/eval.c:2924
#131 0x0818d054 in eval_sub (form=form <at> 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 <at> entry=0x8120540 <top_level_2>, handlers=138956090, 
    hfun=hfun <at> entry=0x81249f0 <cmd_error>) at ../../emacs/src/eval.c:1354
#135 0x08120535 in top_level_1 (ignore=138922946)
    at ../../emacs/src/keyboard.c:1190
#136 0x0818c1f3 in internal_catch (tag=138954138, 
    func=func <at> entry=0x81204d0 <top_level_1>, arg=138922946)
    at ../../emacs/src/eval.c:1118
#137 0x08124624 in command_loop () at ../../emacs/src/keyboard.c:1151
#138 recursive_edit_1 () at ../../emacs/src/keyboard.c:776
#139 0x08124903 in Frecursive_edit () at ../../emacs/src/keyboard.c:844
#140 0x08059578 in main (argc=<optimized out>, argv=0xbfda77d4)
    at ../../emacs/src/emacs.c:1654

-- 
David Kastrup

Message #20 received at 17215 <at> debbugs.gnu.org (full text, mbox):

From: Nicolas Richard <theonewiththeevillook <at> yahoo.fr>
To: David Kastrup <dak <at> gnu.org>
Cc: bzg <at> altern.org, 17215 <at> debbugs.gnu.org,
 Daniel Colascione <dancol <at> dancol.org>
Subject: Re: bug#17215: Build failure
Date: Wed, 09 Apr 2014 12:19:26 +0200

[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 <at> entry=6)
>     at ../nptl/sysdeps/unix/sysv/linux/pt-raise.c:37

You could try Daniel's suggestion to bug#17184, i.e. compile with
-DSYSTEM_PURESIZE_EXTRA=10000000

Perhaps it is time to increase BASE_PURESIZE ? FWIW I applied this patch
to my local branch :

	Modified   src/ChangeLog
diff --git a/src/ChangeLog b/src/ChangeLog
index 2b00e60..9d0d8f0 100644
--- a/src/ChangeLog
+++ b/src/ChangeLog
@@ -1,3 +1,7 @@
+2014-04-09  Nicolas Richard  <theonewiththeevillook <at> yahoo.fr>
+
+	* puresize.h (BASE_PURESIZE): Increase to 1720000.
+
 2014-04-09  Stefan Monnier  <monnier <at> iro.umontreal.ca>
 
 	* insdel.c (prepare_to_modify_buffer_1): Cancel lock-file checks and
	Modified   src/puresize.h
diff --git a/src/puresize.h b/src/puresize.h
index 0ee29d8..ad591c7 100644
--- a/src/puresize.h
+++ b/src/puresize.h
@@ -40,7 +40,7 @@ along with GNU Emacs.  If not, see <http://www.gnu.org/licenses/>.  */
 #endif
 
 #ifndef BASE_PURESIZE
-#define BASE_PURESIZE (1700000 + SYSTEM_PURESIZE_EXTRA + SITELOAD_PURESIZE_EXTRA)
+#define BASE_PURESIZE (1720000 + SYSTEM_PURESIZE_EXTRA + SITELOAD_PURESIZE_EXTRA)
 #endif
 
 /* Increase BASE_PURESIZE by a ratio depending on the machine's word size.  */

-- 
Nico.

Message #23 received at 17215 <at> debbugs.gnu.org (full text, mbox):

From: Daniel Colascione <dancol <at> dancol.org>
To: Nicolas Richard <theonewiththeevillook <at> yahoo.fr>, 
 David Kastrup <dak <at> gnu.org>
Cc: bzg <at> altern.org, 17215 <at> debbugs.gnu.org
Subject: Re: bug#17215: Build failure
Date: Wed, 09 Apr 2014 03:48:49 -0700

[Message part 1 (text/plain, inline)]

On 04/09/2014 03:19 AM, Nicolas Richard wrote:
> [I'm cc-ing Bastien because he had a similar problem IIRC]
> 
> Hi David,
> 
>> Still dumps core.  Looks pretty much the same to me:
>> #0  0x40022424 in __kernel_vsyscall ()
>> #1  0x416b60c6 in raise (sig=sig <at> entry=6)
>>     at ../nptl/sysdeps/unix/sysv/linux/pt-raise.c:37
> 
> You could try Daniel's suggestion to bug#17184, i.e. compile with
> -DSYSTEM_PURESIZE_EXTRA=10000000
> 
> Perhaps it is time to increase BASE_PURESIZE ? FWIW I applied this patch
> to my local branch :
> 

Probably a good idea, assuming the core size increase is natural and
doesn't reflect some deeper problem.

Aside: why do we even bother with the malloc-on-pure-overflow logic? We
can't GC once we've overflown pure storage (although that could be made
to work), so an Emacs in that condition isn't very useful. Wouldn't it
be simpler just to abort when we overflow pure storage?

[signature.asc (application/pgp-signature, attachment)]

Message #26 received at 17215 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Daniel Colascione <dancol <at> dancol.org>
Cc: Nicolas Richard <theonewiththeevillook <at> yahoo.fr>, 17215 <at> debbugs.gnu.org,
 David Kastrup <dak <at> gnu.org>, bzg <at> altern.org
Subject: Re: bug#17215: Build failure
Date: Wed, 09 Apr 2014 08:43:09 -0400

>> Perhaps it is time to increase BASE_PURESIZE ?

Apparently.


        Stefan

Message #29 received at 17215 <at> debbugs.gnu.org (full text, mbox):

From: Bastien <bzg <at> altern.org>
To: Nicolas Richard <theonewiththeevillook <at> yahoo.fr>
Cc: 17215 <at> debbugs.gnu.org, David Kastrup <dak <at> gnu.org>
Subject: Re: bug#17215: Build failure
Date: Wed, 09 Apr 2014 17:38:40 +0200

Hi Nicolas,

Nicolas Richard <theonewiththeevillook <at> yahoo.fr> writes:

> Perhaps it is time to increase BASE_PURESIZE ? FWIW I applied this patch
> to my local branch :

I'm using the same patch now, it works well, thanks!

-- 
 Bastien

Message #32 received at 17215 <at> debbugs.gnu.org (full text, mbox):

From: David Kastrup <dak <at> gnu.org>
To: 17215 <at> debbugs.gnu.org
Subject: Re: bug#17215: Acknowledgement (Build failure)
Date: Fri, 11 Apr 2014 17:51:19 +0200

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

Message #37 received at 17215 <at> debbugs.gnu.org (full text, mbox):

From: Daniel Colascione <dancol <at> dancol.org>
To: David Kastrup <dak <at> gnu.org>, 17215 <at> debbugs.gnu.org
Subject: Re: bug#17215: Acknowledgement (Build failure)
Date: Fri, 11 Apr 2014 12:11:26 -0700

[Message part 1 (text/plain, inline)]

On 04/11/2014 08:51 AM, David Kastrup wrote:
> 
> It would appear that this particular bug yielded to the pure size
> increase.  What a singularly useless error behavior for a problem that
> is expected to reoccur with some regularity!

Still waiting to hear a response to my previous question on why we don't
just abort as soon as we detect pure overflow.

[signature.asc (application/pgp-signature, attachment)]

Message #40 received at 17215 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Daniel Colascione <dancol <at> dancol.org>
Cc: 17215 <at> debbugs.gnu.org, dak <at> gnu.org
Subject: Re: bug#17215: Acknowledgement (Build failure)
Date: Fri, 11 Apr 2014 23:10:17 +0300

> Date: Fri, 11 Apr 2014 12:11:26 -0700
> From: Daniel Colascione <dancol <at> dancol.org>
> 
> Still waiting to hear a response to my previous question on why we don't
> just abort as soon as we detect pure overflow.

AFAIR, we used to do that in the past, but then an overflow during a
build would trap you.  So now we don't (and actually you have an
overflow every time you run "temacs -batch -load loadup bootstrap"
during a normal build.

Message #43 received at 17215 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Daniel Colascione <dancol <at> dancol.org>
Cc: 17215 <at> debbugs.gnu.org, David Kastrup <dak <at> gnu.org>
Subject: Re: bug#17215: Acknowledgement (Build failure)
Date: Fri, 11 Apr 2014 16:11:58 -0400

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

Message #46 received at 17215 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 17215 <at> debbugs.gnu.org, Daniel Colascione <dancol <at> dancol.org>, dak <at> gnu.org
Subject: Re: bug#17215: Acknowledgement (Build failure)
Date: Fri, 11 Apr 2014 16:18:48 -0400

> 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

Message #49 received at 17215 <at> debbugs.gnu.org (full text, mbox):

From: David Kastrup <dak <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 17215 <at> debbugs.gnu.org, Daniel Colascione <dancol <at> dancol.org>
Subject: Re: bug#17215: Acknowledgement (Build failure)
Date: Fri, 11 Apr 2014 22:58:19 +0200

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

>>> It would appear that this particular bug yielded to the pure size
>>> increase.  What a singularly useless error behavior for a problem that
>>> is expected to reoccur with some regularity!
>> Still waiting to hear a response to my previous question on why we don't
>> just abort as soon as we detect pure overflow.
>
> Good question.  The reason is largely histerical, where it was
> convenient to still have a partly usable Emacs.  Nowadays, many more
> people build their Emacs from trunk without having the technical
> knowledge to detect and handle this problem, so it's probably better to
> just abort.

I fail to see how an Emacs that segfaults during the build can be
considered usable to a degree making sense.

-- 
David Kastrup

Message #52 received at 17215 <at> debbugs.gnu.org (full text, mbox):

From: Daniel Colascione <dancol <at> dancol.org>
To: David Kastrup <dak <at> gnu.org>, 
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 17215 <at> debbugs.gnu.org
Subject: Re: bug#17215: Acknowledgement (Build failure)
Date: Fri, 11 Apr 2014 14:34:55 -0700

[Message part 1 (text/plain, inline)]

On 04/11/2014 01:58 PM, David Kastrup wrote:
> Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
> 
>>>> It would appear that this particular bug yielded to the pure size
>>>> increase.  What a singularly useless error behavior for a problem that
>>>> is expected to reoccur with some regularity!
>>> Still waiting to hear a response to my previous question on why we don't
>>> just abort as soon as we detect pure overflow.
>>
>> Good question.  The reason is largely histerical, where it was
>> convenient to still have a partly usable Emacs.  Nowadays, many more
>> people build their Emacs from trunk without having the technical
>> knowledge to detect and handle this problem, so it's probably better to
>> just abort.
> 
> I fail to see how an Emacs that segfaults during the build can be
> considered usable to a degree making sense.

Emacs didn't always segfault (well, abort, really) on pure overflow ---
I broke it. Before, when we noticed we oveflowed pure space, we would
continue (mallocing more pure space), then just refuse to GC. Ever.

The benefit of this scheme (as opposed to failing early) is that you can
tell *by how much* pure space overflowed, but I don't think that this
power is very useful given that users generally don't know how to find
this information. IMHO (and I think Stefan agrees), we should just abort
as soon as we detect pure space overflow and ask users to increase the
necessary constants in the source.

[signature.asc (application/pgp-signature, attachment)]

Message #55 received at 17215 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 17215 <at> debbugs.gnu.org, dancol <at> dancol.org, dak <at> gnu.org
Subject: Re: bug#17215: Acknowledgement (Build failure)
Date: Sat, 12 Apr 2014 11:35:06 +0300

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Date: Fri, 11 Apr 2014 16:11:58 -0400
> Cc: 17215 <at> debbugs.gnu.org, David Kastrup <dak <at> gnu.org>
> 
> >> It would appear that this particular bug yielded to the pure size
> >> increase.  What a singularly useless error behavior for a problem that
> >> is expected to reoccur with some regularity!
> > Still waiting to hear a response to my previous question on why we don't
> > just abort as soon as we detect pure overflow.
> 
> Good question.  The reason is largely histerical, where it was
> convenient to still have a partly usable Emacs.  Nowadays, many more
> people build their Emacs from trunk without having the technical
> knowledge to detect and handle this problem, so it's probably better to
> just abort.

More people building development code doesn't mean more people who
know what to do about pure storage.  So just aborting without any
helpful information (e.g., how much to enlarge the pure space, and
what macro to change) doesn't seem like progress to me.

Message #58 received at 17215 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Daniel Colascione <dancol <at> dancol.org>
Cc: 17215 <at> debbugs.gnu.org, David Kastrup <dak <at> gnu.org>
Subject: Re: bug#17215: Acknowledgement (Build failure)
Date: Sat, 12 Apr 2014 09:19:57 -0400

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

Message #61 received at 17215 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 17215 <at> debbugs.gnu.org, dancol <at> dancol.org, dak <at> gnu.org
Subject: Re: bug#17215: Acknowledgement (Build failure)
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.


        Stefan

Message #64 received at 17215 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: 17215 <at> debbugs.gnu.org, dancol <at> dancol.org, dak <at> gnu.org
Subject: Re: bug#17215: Acknowledgement (Build failure)
Date: Sat, 12 Apr 2014 17:18:29 +0300

> From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
> Cc: dancol <at> dancol.org, 17215 <at> debbugs.gnu.org, dak <at> 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?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.