From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 30 21:21:59 2014 Received: (at submit) by debbugs.gnu.org; 31 Jan 2014 02:21:59 +0000 Received: from localhost ([127.0.0.1]:42096 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W93jw-00079R-W2 for submit@debbugs.gnu.org; Thu, 30 Jan 2014 21:21:59 -0500 Received: from eggs.gnu.org ([208.118.235.92]:42034) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W93jq-00079E-QY for submit@debbugs.gnu.org; Thu, 30 Jan 2014 21:21:54 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W93jl-0006YO-0q for submit@debbugs.gnu.org; Thu, 30 Jan 2014 21:21:50 -0500 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_50 autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:41004) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W93jk-0006YJ-UL for submit@debbugs.gnu.org; Thu, 30 Jan 2014 21:21:44 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43726) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W93jd-0006OO-FP for bug-gnu-emacs@gnu.org; Thu, 30 Jan 2014 21:21:44 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W93jX-0006ST-M9 for bug-gnu-emacs@gnu.org; Thu, 30 Jan 2014 21:21:37 -0500 Received: from hermes.netfonds.no ([80.91.224.195]:41653) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W93jX-0006RS-7e for bug-gnu-emacs@gnu.org; Thu, 30 Jan 2014 21:21:31 -0500 Received: from [204.14.154.233] (helo=building.gnus.org) by hermes.netfonds.no with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1W93jE-0004Jf-GK for bug-gnu-emacs@gnu.org; Fri, 31 Jan 2014 03:21:13 +0100 From: Lars Ingebrigtsen To: bug-gnu-emacs@gnu.org Subject: 24.3.50; Segfault when viewing a backtrace Date: Thu, 30 Jan 2014 18:20:22 -0800 Message-ID: <878utw28pl.fsf@building.gnus.org> MIME-Version: 1.0 Content-Type: text/plain X-MailScanner-ID: 1W93jE-0004Jf-GK X-Netfonds-MailScanner: Found to be clean X-Netfonds-MailScanner-From: larsi@gnus.org MailScanner-NULL-Check: 1391739674.03066@GM3OB/FVaccstYpiNB0igg X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. 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.0 (-----) 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.0 (-----) (require 'gnus-group) (setq debug-on-error t) (gnus-read-ephemeral-emacs-bug-group 16577) Choose Rotem's article, and my Emacs crashes: #0 0x0000003f49a359e9 in raise () from /lib64/libc.so.6 #1 0x0000003f49a370f8 in abort () from /lib64/libc.so.6 #2 0x0000003f49a75d17 in __libc_message () from /lib64/libc.so.6 #3 0x0000003f49a7d0b8 in _int_free () from /lib64/libc.so.6 #4 0x000000000052d1d9 in lisp_free (block=0x27b78c0) at alloc.c:931 #5 0x00000000005320b6 in free_large_strings () at alloc.c:1909 #6 sweep_strings () at alloc.c:1889 #7 gc_sweep () at alloc.c:6333 #8 Fgarbage_collect () at alloc.c:5572 #9 0x000000000057c31b in maybe_gc () at lisp.h:4518 #10 exec_byte_code (bytestr=0, vector=9402, maxdepth=6, args_template=-1, nargs=140737488221432, args=0x82) at bytecode.c:954 #11 0x0000000000548467 in funcall_lambda (fun=8682901, nargs=nargs@entry=2, arg_vector=0x7ffffffdf740, arg_vector@entry=0x7ffffffdf698) at eval.c:2974 #12 0x000000000054872b in Ffuncall (nargs=3, args=0x7ffffffdf690) at eval.c:2867 #13 0x000000000057c1cd in exec_byte_code (bytestr=0, vector=9402, maxdepth=6, args_template=-1, nargs=172, args=0x3) at bytecode.c:919 #14 0x0000000000548467 in funcall_lambda (fun=41324685, nargs=nargs@entry=0, arg_vector=0x7ffffffdf8c0, arg_vector@entry=0x7ffffffdf838) at eval.c:2974 #15 0x000000000054872b in Ffuncall (nargs=1, args=0x7ffffffdf830) at eval.c:2867 #16 0x000000000057c1cd in exec_byte_code (bytestr=0, vector=9402, maxdepth=6, args_template=-1, nargs=140737488222256, args=0x1) at bytecode.c:919 #17 0x0000000000548467 in funcall_lambda (fun=41324373, nargs=nargs@entry=1, arg_vector=0x7ffffffdfb60, arg_vector@entry=0x7ffffffdfaa8) at eval.c:2974 #18 0x000000000054872b in Ffuncall (nargs=2, args=0x7ffffffdfaa0) at eval.c:2867 #19 0x000000000057c1cd in exec_byte_code (bytestr=0, vector=9402, maxdepth=6, args_template=-1, nargs=140737488222872, args=0x2) at bytecode.c:919 #20 0x0000000000548467 in funcall_lambda (fun=41323997, nargs=nargs@entry=2, arg_vector=0x7ffffffdff80, arg_vector@entry=0x7ffffffdfc48) at eval.c:2974 #21 0x000000000054872b in Ffuncall (nargs=nargs@entry=3, args=args@entry=0x7ffffffdfc40) at eval.c:2867 #22 0x0000000000549b1c in Fapply (nargs=nargs@entry=2, args=args@entry=0x7ffffffdfce0) at eval.c:2345 #23 0x0000000000549d50 in apply1 (fn=12149570, arg=arg@entry=42128966) at eval.c:2579 #24 0x0000000000549f06 in call_debugger (arg=42128966) at eval.c:323 #25 0x0000000000548e6d in maybe_call_debugger (data=42128918, sig=12077586, conditions=8579966) at eval.c:1724 #26 Fsignal (error_symbol=12077586, data=42128918) at eval.c:1542 #27 0x0000000000549039 in xsignal (error_symbol=, data=) at eval.c:1579 #28 0x0000000000549704 in signal_error ( s=0x5ddc38 "Variable binding depth exceeds max-specpdl-size", arg=12026162) at eval.c:1634 #29 0x0000000000549792 in grow_specpdl () at eval.c:2023 #30 0x0000000000549886 in specbind (symbol=41539506, value=41896998) at eval.c:3138 #31 0x00000000005482d5 in funcall_lambda (fun=41546861, nargs=nargs@entry=1, arg_vector=arg_vector@entry=0x7ffffffdff10) at eval.c:3019 #32 0x000000000054872b in Ffuncall (nargs=2, args=0x7ffffffdff08) at eval.c:2867 #33 0x000000000057c1cd in exec_byte_code (bytestr=0, vector=9402, maxdepth=6, args_template=-1, nargs=140737488224000, args=0x2) at bytecode.c:919 #34 0x00000000005483cf in funcall_lambda (fun=41546965, nargs=nargs@entry=1, arg_vector=arg_vector@entry=0x7ffffffe00e0) at eval.c:3040 #35 0x000000000054872b in Ffuncall (nargs=2, args=0x7ffffffe00d8) at eval.c:2867 #36 0x000000000057c1cd in exec_byte_code (bytestr=0, vector=9402, maxdepth=6, args_template=-1, nargs=140737488224464, args=0x2) at bytecode.c:919 #37 0x00000000005483cf in funcall_lambda (fun=41546861, nargs=nargs@entry=1, arg_vector=arg_vector@entry=0x7ffffffe02d0) at eval.c:3040 #38 0x000000000054872b in Ffuncall (nargs=2, args=0x7ffffffe02c8) at eval.c:2867 #39 0x000000000057c1cd in exec_byte_code (bytestr=0, vector=9402, maxdepth=6, args_template=-1, nargs=140737488224960, args=0x2) at bytecode.c:919 #40 0x00000000005483cf in funcall_lambda (fun=41546965, nargs=nargs@entry=1, arg_vector=arg_vector@entry=0x7ffffffe04a0) at eval.c:3040 #41 0x000000000054872b in Ffuncall (nargs=2, args=0x7ffffffe0498) at eval.c:2867 #42 0x000000000057c1cd in exec_byte_code (bytestr=0, vector=9402, maxdepth=6, args_template=-1, nargs=140737488225424, args=0x2) at bytecode.c:919 #43 0x00000000005483cf in funcall_lambda (fun=41546861, nargs=nargs@entry=1, arg_vector=arg_vector@entry=0x7ffffffe0690) at eval.c:3040 #44 0x000000000054872b in Ffuncall (nargs=2, args=0x7ffffffe0688) at eval.c:2867 #45 0x000000000057c1cd in exec_byte_code (bytestr=0, vector=9402, maxdepth=6, args_template=-1, nargs=140737488225920, args=0x2) at bytecode.c:919 #46 0x00000000005483cf in funcall_lambda (fun=41546965, nargs=nargs@entry=1, arg_vector=arg_vector@entry=0x7ffffffe0860) at eval.c:3040 #47 0x000000000054872b in Ffuncall (nargs=2, args=0x7ffffffe0858) at eval.c:2867 #48 0x000000000057c1cd in exec_byte_code (bytestr=0, vector=9402, maxdepth=6, args_template=-1, nargs=140737488226384, args=0x2) at bytecode.c:919 #49 0x00000000005483cf in funcall_lambda (fun=41546861, nargs=nargs@entry=1, arg_vector=arg_vector@entry=0x7ffffffe0a50) at eval.c:3040 #50 0x000000000054872b in Ffuncall (nargs=2, args=0x7ffffffe0a48) at eval.c:2867 #51 0x000000000057c1cd in exec_byte_code (bytestr=0, vector=9402, maxdepth=6, args_template=-1, nargs=140737488226880, args=0x2) at bytecode.c:919 ... #793 0x00000000005488e8 in Ffuncall (nargs=, args=) at eval.c:2813 #794 0x000000000057c1cd in exec_byte_code (bytestr=0, vector=9402, maxdepth=6, args_template=-1, nargs=140737488346112, args=0x4) at bytecode.c:919 #795 0x0000000000548467 in funcall_lambda (fun=9480117, nargs=nargs@entry=1, arg_vector=0x0, arg_vector@entry=0x7fffffffdd88) at eval.c:2974 #796 0x000000000054872b in Ffuncall (nargs=nargs@entry=2, args=args@entry=0x7fffffffdd80) at eval.c:2867 #797 0x0000000000548a4a in call1 (fn=, arg1=) at eval.c:2605 #798 0x00000000004e6a1d in command_loop_1 () at keyboard.c:1552 #799 0x0000000000546dae in internal_condition_case ( bfun=bfun@entry=0x4e6690 , handlers=, ---Type to continue, or q to quit--- hfun=hfun@entry=0x4dd760 ) at eval.c:1345 #800 0x00000000004d8f1e in command_loop_2 (ignore=ignore@entry=12026162) at keyboard.c:1170 #801 0x0000000000546cbb in internal_catch (tag=12073522, func=func@entry=0x4d8f00 , arg=12026162) at eval.c:1109 #802 0x00000000004dd387 in command_loop () at keyboard.c:1149 #803 recursive_edit_1 () at keyboard.c:777 #804 0x00000000004dd672 in Frecursive_edit () at keyboard.c:841 #805 0x0000000000415af5 in main (argc=, argv=0x7fffffffe128) at emacs.c:1643 In GNU Emacs 24.3.50.5 (x86_64-unknown-linux-gnu, GTK+ Version 3.8.8) of 2014-01-30 on building.gnus.org Repository revision: 116212 rgm@gnu.org-20140131015851-wo40jqmjm0xj6yl0 Windowing system distributor `Fedora Project', version 11.0.11404000 Important settings: value of $LANG: en_GB.utf8 value of $XMODIFIERS: @im=ibus locale-coding-system: utf-8-unix Major mode: Group Minor modes in effect: gnus-topic-mode: t gnus-undo-mode: t tooltip-mode: t electric-indent-mode: t mouse-wheel-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t buffer-read-only: t line-number-mode: t Recent input: M-x m M-x r e p o r Recent messages: No new newsgroups Checking new news... nnimap hermes.netfonds.no splitting mail... nnimap read 0k from hermes.netfonds.no nnimap hermes.netfonds.no splitting mail...done nnimap read 0k from hermes.netfonds.no Reading active file from archive via nnfolder...done Reading active file from archive via nnfolder...done Reading active file via nndraft...done Checking new news...done Load-path shadows: /home/larsi/mgnus/lisp/hex-util hides /home/larsi/src/emacs/trunk/lisp/hex-util /home/larsi/mgnus/lisp/md4 hides /home/larsi/src/emacs/trunk/lisp/md4 /home/larsi/mgnus/lisp/format-spec hides /home/larsi/src/emacs/trunk/lisp/format-spec /home/larsi/mgnus/lisp/password-cache hides /home/larsi/src/emacs/trunk/lisp/password-cache /home/larsi/mgnus/lisp/color hides /home/larsi/src/emacs/trunk/lisp/color /home/larsi/mgnus/lisp/dns-mode hides /home/larsi/src/emacs/trunk/lisp/textmodes/dns-mode /home/larsi/mgnus/lisp/sasl-digest hides /home/larsi/src/emacs/trunk/lisp/net/sasl-digest /home/larsi/mgnus/lisp/hmac-md5 hides /home/larsi/src/emacs/trunk/lisp/net/hmac-md5 /home/larsi/mgnus/lisp/sasl-ntlm hides /home/larsi/src/emacs/trunk/lisp/net/sasl-ntlm /home/larsi/mgnus/lisp/dns hides /home/larsi/src/emacs/trunk/lisp/net/dns /home/larsi/mgnus/lisp/hmac-def hides /home/larsi/src/emacs/trunk/lisp/net/hmac-def /home/larsi/mgnus/lisp/sasl hides /home/larsi/src/emacs/trunk/lisp/net/sasl /home/larsi/mgnus/lisp/sasl-cram hides /home/larsi/src/emacs/trunk/lisp/net/sasl-cram /home/larsi/mgnus/lisp/ntlm hides /home/larsi/src/emacs/trunk/lisp/net/ntlm /home/larsi/mgnus/lisp/tls hides /home/larsi/src/emacs/trunk/lisp/net/tls /home/larsi/mgnus/lisp/dig hides /home/larsi/src/emacs/trunk/lisp/net/dig /home/larsi/mgnus/lisp/netrc hides /home/larsi/src/emacs/trunk/lisp/net/netrc /home/larsi/mgnus/lisp/uudecode hides /home/larsi/src/emacs/trunk/lisp/mail/uudecode /home/larsi/mgnus/lisp/hashcash hides /home/larsi/src/emacs/trunk/lisp/mail/hashcash /home/larsi/mgnus/lisp/binhex hides /home/larsi/src/emacs/trunk/lisp/mail/binhex /home/larsi/mgnus/lisp/gnus-sieve hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-sieve /home/larsi/mgnus/lisp/gnus hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus /home/larsi/mgnus/lisp/nnmh hides /home/larsi/src/emacs/trunk/lisp/gnus/nnmh /home/larsi/mgnus/lisp/nndir hides /home/larsi/src/emacs/trunk/lisp/gnus/nndir /home/larsi/mgnus/lisp/gnus-kill hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-kill /home/larsi/mgnus/lisp/deuglify hides /home/larsi/src/emacs/trunk/lisp/gnus/deuglify /home/larsi/mgnus/lisp/mm-archive hides /home/larsi/src/emacs/trunk/lisp/gnus/mm-archive /home/larsi/mgnus/lisp/gnus-gravatar hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-gravatar /home/larsi/mgnus/lisp/mm-decode hides /home/larsi/src/emacs/trunk/lisp/gnus/mm-decode /home/larsi/mgnus/lisp/yenc hides /home/larsi/src/emacs/trunk/lisp/gnus/yenc /home/larsi/mgnus/lisp/mm-extern hides /home/larsi/src/emacs/trunk/lisp/gnus/mm-extern /home/larsi/mgnus/lisp/qp hides /home/larsi/src/emacs/trunk/lisp/gnus/qp /home/larsi/mgnus/lisp/gnus-diary hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-diary /home/larsi/mgnus/lisp/gnus-fun hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-fun /home/larsi/mgnus/lisp/gnus-vm hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-vm /home/larsi/mgnus/lisp/registry hides /home/larsi/src/emacs/trunk/lisp/gnus/registry /home/larsi/mgnus/lisp/nnrss hides /home/larsi/src/emacs/trunk/lisp/gnus/nnrss /home/larsi/mgnus/lisp/rfc2231 hides /home/larsi/src/emacs/trunk/lisp/gnus/rfc2231 /home/larsi/mgnus/lisp/mml-sec hides /home/larsi/src/emacs/trunk/lisp/gnus/mml-sec /home/larsi/mgnus/lisp/gssapi hides /home/larsi/src/emacs/trunk/lisp/gnus/gssapi /home/larsi/mgnus/lisp/gnus-bookmark hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-bookmark /home/larsi/mgnus/lisp/nnagent hides /home/larsi/src/emacs/trunk/lisp/gnus/nnagent /home/larsi/mgnus/lisp/gnus-topic hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-topic /home/larsi/mgnus/lisp/gnus-bcklg hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-bcklg /home/larsi/mgnus/lisp/gnus-uu hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-uu /home/larsi/mgnus/lisp/nnbabyl hides /home/larsi/src/emacs/trunk/lisp/gnus/nnbabyl /home/larsi/mgnus/lisp/gnus-ml hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-ml /home/larsi/mgnus/lisp/nnmbox hides /home/larsi/src/emacs/trunk/lisp/gnus/nnmbox /home/larsi/mgnus/lisp/nnvirtual hides /home/larsi/src/emacs/trunk/lisp/gnus/nnvirtual /home/larsi/mgnus/lisp/rfc1843 hides /home/larsi/src/emacs/trunk/lisp/gnus/rfc1843 /home/larsi/mgnus/lisp/sieve-mode hides /home/larsi/src/emacs/trunk/lisp/gnus/sieve-mode /home/larsi/mgnus/lisp/nnregistry hides /home/larsi/src/emacs/trunk/lisp/gnus/nnregistry /home/larsi/mgnus/lisp/gravatar hides /home/larsi/src/emacs/trunk/lisp/gnus/gravatar /home/larsi/mgnus/lisp/score-mode hides /home/larsi/src/emacs/trunk/lisp/gnus/score-mode /home/larsi/mgnus/lisp/gnus-notifications hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-notifications /home/larsi/mgnus/lisp/rtree hides /home/larsi/src/emacs/trunk/lisp/gnus/rtree /home/larsi/mgnus/lisp/gnus-mh hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-mh /home/larsi/mgnus/lisp/mail-parse hides /home/larsi/src/emacs/trunk/lisp/gnus/mail-parse /home/larsi/mgnus/lisp/mm-uu hides /home/larsi/src/emacs/trunk/lisp/gnus/mm-uu /home/larsi/mgnus/lisp/nnmairix hides /home/larsi/src/emacs/trunk/lisp/gnus/nnmairix /home/larsi/mgnus/lisp/gnus-agent hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-agent /home/larsi/mgnus/lisp/message hides /home/larsi/src/emacs/trunk/lisp/gnus/message /home/larsi/mgnus/lisp/gnus-async hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-async /home/larsi/mgnus/lisp/spam-report hides /home/larsi/src/emacs/trunk/lisp/gnus/spam-report /home/larsi/mgnus/lisp/mm-encode hides /home/larsi/src/emacs/trunk/lisp/gnus/mm-encode /home/larsi/mgnus/lisp/smime hides /home/larsi/src/emacs/trunk/lisp/gnus/smime /home/larsi/mgnus/lisp/mm-url hides /home/larsi/src/emacs/trunk/lisp/gnus/mm-url /home/larsi/mgnus/lisp/smiley hides /home/larsi/src/emacs/trunk/lisp/gnus/smiley /home/larsi/mgnus/lisp/plstore hides /home/larsi/src/emacs/trunk/lisp/gnus/plstore /home/larsi/mgnus/lisp/nngateway hides /home/larsi/src/emacs/trunk/lisp/gnus/nngateway /home/larsi/mgnus/lisp/gnus-picon hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-picon /home/larsi/mgnus/lisp/gnus-range hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-range /home/larsi/mgnus/lisp/mailcap hides /home/larsi/src/emacs/trunk/lisp/gnus/mailcap /home/larsi/mgnus/lisp/gnus-sync hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-sync /home/larsi/mgnus/lisp/sieve hides /home/larsi/src/emacs/trunk/lisp/gnus/sieve /home/larsi/mgnus/lisp/nntp hides /home/larsi/src/emacs/trunk/lisp/gnus/nntp /home/larsi/mgnus/lisp/gnus-logic hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-logic /home/larsi/mgnus/lisp/rfc2047 hides /home/larsi/src/emacs/trunk/lisp/gnus/rfc2047 /home/larsi/mgnus/lisp/mml2015 hides /home/larsi/src/emacs/trunk/lisp/gnus/mml2015 /home/larsi/mgnus/lisp/gnus-html hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-html /home/larsi/mgnus/lisp/gnus-undo hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-undo /home/larsi/mgnus/lisp/utf7 hides /home/larsi/src/emacs/trunk/lisp/gnus/utf7 /home/larsi/mgnus/lisp/gmm-utils hides /home/larsi/src/emacs/trunk/lisp/gnus/gmm-utils /home/larsi/mgnus/lisp/gnus-icalendar hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-icalendar /home/larsi/mgnus/lisp/gnus-salt hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-salt /home/larsi/mgnus/lisp/mml-smime hides /home/larsi/src/emacs/trunk/lisp/gnus/mml-smime /home/larsi/mgnus/lisp/mm-view hides /home/larsi/src/emacs/trunk/lisp/gnus/mm-view /home/larsi/mgnus/lisp/gnus-demon hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-demon /home/larsi/mgnus/lisp/gnus-cus hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-cus /home/larsi/mgnus/lisp/nnmaildir hides /home/larsi/src/emacs/trunk/lisp/gnus/nnmaildir /home/larsi/mgnus/lisp/gnus-art hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-art /home/larsi/mgnus/lisp/sieve-manage hides /home/larsi/src/emacs/trunk/lisp/gnus/sieve-manage /home/larsi/mgnus/lisp/gnus-group hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-group /home/larsi/mgnus/lisp/gnus-msg hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-msg /home/larsi/mgnus/lisp/spam-stat hides /home/larsi/src/emacs/trunk/lisp/gnus/spam-stat /home/larsi/mgnus/lisp/mml hides /home/larsi/src/emacs/trunk/lisp/gnus/mml /home/larsi/mgnus/lisp/rfc2104 hides /home/larsi/src/emacs/trunk/lisp/gnus/rfc2104 /home/larsi/mgnus/lisp/gnus-registry hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-registry /home/larsi/mgnus/lisp/nnheader hides /home/larsi/src/emacs/trunk/lisp/gnus/nnheader /home/larsi/mgnus/lisp/compface hides /home/larsi/src/emacs/trunk/lisp/gnus/compface /home/larsi/mgnus/lisp/nnnil hides /home/larsi/src/emacs/trunk/lisp/gnus/nnnil /home/larsi/mgnus/lisp/mml1991 hides /home/larsi/src/emacs/trunk/lisp/gnus/mml1991 /home/larsi/mgnus/lisp/mail-prsvr hides /home/larsi/src/emacs/trunk/lisp/gnus/mail-prsvr /home/larsi/mgnus/lisp/ecomplete hides /home/larsi/src/emacs/trunk/lisp/gnus/ecomplete /home/larsi/mgnus/lisp/gnus-win hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-win /home/larsi/mgnus/lisp/nneething hides /home/larsi/src/emacs/trunk/lisp/gnus/nneething /home/larsi/mgnus/lisp/nndoc hides /home/larsi/src/emacs/trunk/lisp/gnus/nndoc /home/larsi/mgnus/lisp/gnus-srvr hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-srvr /home/larsi/mgnus/lisp/nnoo hides /home/larsi/src/emacs/trunk/lisp/gnus/nnoo /home/larsi/mgnus/lisp/spam hides /home/larsi/src/emacs/trunk/lisp/gnus/spam /home/larsi/mgnus/lisp/nnfolder hides /home/larsi/src/emacs/trunk/lisp/gnus/nnfolder /home/larsi/mgnus/lisp/messcompat hides /home/larsi/src/emacs/trunk/lisp/gnus/messcompat /home/larsi/mgnus/lisp/html2text hides /home/larsi/src/emacs/trunk/lisp/gnus/html2text /home/larsi/mgnus/lisp/starttls hides /home/larsi/src/emacs/trunk/lisp/gnus/starttls /home/larsi/mgnus/lisp/auth-source hides /home/larsi/src/emacs/trunk/lisp/gnus/auth-source /home/larsi/mgnus/lisp/canlock hides /home/larsi/src/emacs/trunk/lisp/gnus/canlock /home/larsi/mgnus/lisp/pop3 hides /home/larsi/src/emacs/trunk/lisp/gnus/pop3 /home/larsi/mgnus/lisp/gnus-score hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-score /home/larsi/mgnus/lisp/mm-util hides /home/larsi/src/emacs/trunk/lisp/gnus/mm-util /home/larsi/mgnus/lisp/gnus-sum hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-sum /home/larsi/mgnus/lisp/nndiary hides /home/larsi/src/emacs/trunk/lisp/gnus/nndiary /home/larsi/mgnus/lisp/gnus-start hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-start /home/larsi/mgnus/lisp/gnus-int hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-int /home/larsi/mgnus/lisp/rfc2045 hides /home/larsi/src/emacs/trunk/lisp/gnus/rfc2045 /home/larsi/mgnus/lisp/gnus-cache hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-cache /home/larsi/mgnus/lisp/nnweb hides /home/larsi/src/emacs/trunk/lisp/gnus/nnweb /home/larsi/mgnus/lisp/mail-source hides /home/larsi/src/emacs/trunk/lisp/gnus/mail-source /home/larsi/mgnus/lisp/gnus-eform hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-eform /home/larsi/mgnus/lisp/gnus-mlspl hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-mlspl /home/larsi/mgnus/lisp/gnus-util hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-util /home/larsi/mgnus/lisp/mm-partial hides /home/larsi/src/emacs/trunk/lisp/gnus/mm-partial /home/larsi/mgnus/lisp/nnimap hides /home/larsi/src/emacs/trunk/lisp/gnus/nnimap /home/larsi/mgnus/lisp/.dir-locals hides /home/larsi/src/emacs/trunk/lisp/gnus/.dir-locals /home/larsi/mgnus/lisp/nnir hides /home/larsi/src/emacs/trunk/lisp/gnus/nnir /home/larsi/mgnus/lisp/gnus-spec hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-spec /home/larsi/mgnus/lisp/legacy-gnus-agent hides /home/larsi/src/emacs/trunk/lisp/gnus/legacy-gnus-agent /home/larsi/mgnus/lisp/gnus-cite hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-cite /home/larsi/mgnus/lisp/gnus-dup hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-dup /home/larsi/mgnus/lisp/spam-wash hides /home/larsi/src/emacs/trunk/lisp/gnus/spam-wash /home/larsi/mgnus/lisp/ietf-drums hides /home/larsi/src/emacs/trunk/lisp/gnus/ietf-drums /home/larsi/mgnus/lisp/nnml hides /home/larsi/src/emacs/trunk/lisp/gnus/nnml /home/larsi/mgnus/lisp/nnmail hides /home/larsi/src/emacs/trunk/lisp/gnus/nnmail /home/larsi/mgnus/lisp/nndraft hides /home/larsi/src/emacs/trunk/lisp/gnus/nndraft /home/larsi/mgnus/lisp/nnspool hides /home/larsi/src/emacs/trunk/lisp/gnus/nnspool /home/larsi/mgnus/lisp/gnus-setup hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-setup /home/larsi/mgnus/lisp/gnus-ems hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-ems /home/larsi/mgnus/lisp/gnus-draft hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-draft /home/larsi/mgnus/lisp/flow-fill hides /home/larsi/src/emacs/trunk/lisp/gnus/flow-fill /home/larsi/mgnus/lisp/mm-bodies hides /home/larsi/src/emacs/trunk/lisp/gnus/mm-bodies /home/larsi/mgnus/lisp/gnus-delay hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-delay /home/larsi/mgnus/lisp/gnus-dired hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-dired /home/larsi/mgnus/lisp/time-date hides /home/larsi/src/emacs/trunk/lisp/calendar/time-date /home/larsi/mgnus/lisp/parse-time hides /home/larsi/src/emacs/trunk/lisp/calendar/parse-time Features: (shadow sort ecomplete emacsbug sendmail gnus-fun gnus-mdrtn gnus-topic nndraft nnmh utf-7 nnimap utf7 nnfolder parse-time netrc gnutls network-stream starttls tls nnir spam-report spam spam-stat gnus-uu yenc gnus-agent gnus-srvr gnus-score score-mode nnvirtual gnus-msg gnus-art mm-uu mml2015 epg-config mm-view mml-smime smime dig nntp gnus-cache gnus-sum nnoo gnus-group gnus-undo nnmail mail-source gnus-start gnus-spec gnus-int gnus-range message format-spec rfc822 mml easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045 ietf-drums mailabbrev gmm-utils mailheader gnus-win gnus-load gnus gnus-ems gnus-compat url url-proxy url-privacy url-expand url-methods url-history url-cookie url-domsuf url-util url-parse auth-source eieio byte-opt bytecomp byte-compile cconv eieio-core password-cache url-vars mailcap nnheader gnus-util mail-utils mm-util help-fns mail-prsvr wid-edit package ido flyspell ispell dired cl-macs gv add-log mail-extr jka-compr cl cl-loaddefs cl-lib time-date tooltip electric uniquify ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment lisp-mode prog-mode register page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer nadvice loaddefs button faces cus-face macroexp files text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote make-network-process gfilenotify dynamic-setting system-font-setting font-render-setting move-toolbar gtk x-toolkit x multi-tty emacs) -- (domestic pets only, the antidote for overdose, milk.) bloggy blog http://lars.ingebrigtsen.no/ From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 31 02:03:24 2014 Received: (at 16603) by debbugs.gnu.org; 31 Jan 2014 07:03:24 +0000 Received: from localhost ([127.0.0.1]:42245 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W988J-0006uf-Cs for submit@debbugs.gnu.org; Fri, 31 Jan 2014 02:03:23 -0500 Received: from forward6l.mail.yandex.net ([84.201.143.139]:47024) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W988G-0006uW-2O for 16603@debbugs.gnu.org; Fri, 31 Jan 2014 02:03:21 -0500 Received: from smtp2o.mail.yandex.net (smtp2o.mail.yandex.net [37.140.190.27]) by forward6l.mail.yandex.net (Yandex) with ESMTP id 79A6614E140D; Fri, 31 Jan 2014 11:03:18 +0400 (MSK) Received: from smtp2o.mail.yandex.net (localhost [127.0.0.1]) by smtp2o.mail.yandex.net (Yandex) with ESMTP id 24E9D36A0DA4; Fri, 31 Jan 2014 11:03:18 +0400 (MSK) Received: from unknown (unknown [37.139.80.10]) by smtp2o.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id oar8ejrx0m-3HZiSFhT; Fri, 31 Jan 2014 11:03:17 +0400 (using TLSv1 with cipher CAMELLIA256-SHA (256/256 bits)) (Client certificate not present) X-Yandex-Uniq: 0baea5e0-2a5a-4d35-a3f9-e65726988ac0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1391151797; bh=VJk2RYVI7gk+806K1uvoCRkNH+5Uy/cbdgX6ANuDH7I=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=D/OX6rsbRKjiHAAg3djCJNsriu6Xh01xDnxdsHgTp8rAKDKRq8iAP9f5PZHGLmLGw c1kYTntfRlUSuKc6fJzzT2YTrGgvFfOzKrLHYYkGX0VPstmtf9/K8NP1AZCQstJ8vP dTtPkXlvmx0P8GETVgXJRPgl/wokuodfJ6IcC0yE= Authentication-Results: smtp2o.mail.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <52EB4AB4.8040004@yandex.ru> Date: Fri, 31 Jan 2014 11:03:16 +0400 From: Dmitry Antipov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Lars Ingebrigtsen Subject: Re: bug#16603: 24.3.50; Segfault when viewing a backtrace References: <878utw28pl.fsf@building.gnus.org> In-Reply-To: <878utw28pl.fsf@building.gnus.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 16603 Cc: 16603@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.0 (/) On 01/31/2014 06:20 AM, Lars Ingebrigtsen wrote: > (require 'gnus-group) > (setq debug-on-error t) > (gnus-read-ephemeral-emacs-bug-group 16577) > > Choose Rotem's article, and my Emacs crashes: Reproduced. With the only extra eassert: === modified file 'src/eval.c' --- src/eval.c 2014-01-25 03:48:29 +0000 +++ src/eval.c 2014-01-31 06:49:49 +0000 @@ -3191,6 +3191,7 @@ void record_unwind_protect (void (*function) (Lisp_Object), Lisp_Object arg) { + eassert (specpdl_ptr < specpdl + specpdl_size); specpdl_ptr->unwind.kind = SPECPDL_UNWIND; specpdl_ptr->unwind.func = function; specpdl_ptr->unwind.arg = arg; I got the following backtrace: #14 0x00000000005eafb9 in die (msg=0x70d440 "specpdl_ptr < specpdl + specpdl_size", file=0x70c498 "../../trunk/src/eval.c", line=3194) at ../../trunk/src/alloc.c:6761 #15 0x000000000060d987 in record_unwind_protect (function=0x605b1a , arg=...) at ../../trunk/src/eval.c:3194 #16 0x0000000000605c1f in call_debugger (arg=...) at ../../trunk/src/eval.c:290 #17 0x0000000000609b3b in maybe_call_debugger (conditions=..., sig=..., data=...) at ../../trunk/src/eval.c:1724 #18 0x00000000006093a5 in Fsignal (error_symbol=..., data=...) at ../../trunk/src/eval.c:1542 #19 0x00000000006094be in xsignal (error_symbol=..., data=...) at ../../trunk/src/eval.c:1579 #20 0x00000000006096e3 in signal_error (s=0x70d008 "Variable binding depth exceeds max-specpdl-size", arg=...) at ../../trunk/src/eval.c:1634 #21 0x000000000060a6f6 in grow_specpdl () at ../../trunk/src/eval.c:2023 #22 0x000000000060a7e3 in record_in_backtrace (function=..., args=0x7ffffff78020, nargs=1) at ../../trunk/src/eval.c:2042 #23 0x000000000060c383 in Ffuncall (nargs=2, args=0x7ffffff78018) at ../../trunk/src/eval.c:2754 IIUC this is a kind of chicken-egg problem: when we're running out of specpdl stack, we want to run a debugger, which, in turn, needs some specpdl space to run. Dmitry From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 31 03:10:18 2014 Received: (at 16603) by debbugs.gnu.org; 31 Jan 2014 08:10:18 +0000 Received: from localhost ([127.0.0.1]:42311 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W99B3-0002SI-OK for submit@debbugs.gnu.org; Fri, 31 Jan 2014 03:10:18 -0500 Received: from mtaout29.012.net.il ([80.179.55.185]:40523) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W99B1-0002S8-R0 for 16603@debbugs.gnu.org; Fri, 31 Jan 2014 03:10:16 -0500 Received: from conversion-daemon.mtaout29.012.net.il by mtaout29.012.net.il (HyperSendmail v2007.08) id <0N0900C00ALZV300@mtaout29.012.net.il> for 16603@debbugs.gnu.org; Fri, 31 Jan 2014 10:11:51 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout29.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N09004O6ARQIS90@mtaout29.012.net.il>; Fri, 31 Jan 2014 10:11:50 +0200 (IST) Date: Fri, 31 Jan 2014 10:10:17 +0200 From: Eli Zaretskii Subject: Re: bug#16603: 24.3.50; Segfault when viewing a backtrace In-reply-to: <52EB4AB4.8040004@yandex.ru> X-012-Sender: halo1@inter.net.il To: Dmitry Antipov Message-id: <83eh3o7es6.fsf@gnu.org> References: <878utw28pl.fsf@building.gnus.org> <52EB4AB4.8040004@yandex.ru> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 16603 Cc: larsi@gnus.org, 16603@debbugs.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, 31 Jan 2014 11:03:16 +0400 > From: Dmitry Antipov > Cc: 16603@debbugs.gnu.org > > On 01/31/2014 06:20 AM, Lars Ingebrigtsen wrote: > > > (require 'gnus-group) > > (setq debug-on-error t) > > (gnus-read-ephemeral-emacs-bug-group 16577) > > > > Choose Rotem's article, and my Emacs crashes: > > Reproduced. With the only extra eassert: > > === modified file 'src/eval.c' > --- src/eval.c 2014-01-25 03:48:29 +0000 > +++ src/eval.c 2014-01-31 06:49:49 +0000 > @@ -3191,6 +3191,7 @@ > void > record_unwind_protect (void (*function) (Lisp_Object), Lisp_Object arg) > { > + eassert (specpdl_ptr < specpdl + specpdl_size); > specpdl_ptr->unwind.kind = SPECPDL_UNWIND; > specpdl_ptr->unwind.func = function; > specpdl_ptr->unwind.arg = arg; > > I got the following backtrace: > > #14 0x00000000005eafb9 in die (msg=0x70d440 "specpdl_ptr < specpdl + specpdl_size", file=0x70c498 "../../trunk/src/eval.c", > line=3194) at ../../trunk/src/alloc.c:6761 Of course. This can be seen in Lars's backtrace (note the error Emacs is signaling in frame #28): > #24 0x0000000000549f06 in call_debugger (arg=42128966) at eval.c:323 > #25 0x0000000000548e6d in maybe_call_debugger (data=42128918, sig=12077586, > conditions=8579966) at eval.c:1724 > #26 Fsignal (error_symbol=12077586, data=42128918) at eval.c:1542 > #27 0x0000000000549039 in xsignal (error_symbol=, > data=) at eval.c:1579 > #28 0x0000000000549704 in signal_error ( > s=0x5ddc38 "Variable binding depth exceeds max-specpdl-size", arg=12026162) > at eval.c:1634 > #29 0x0000000000549792 in grow_specpdl () at eval.c:2023 > #30 0x0000000000549886 in specbind (symbol=41539506, value=41896998) > at eval.c:3138 > IIUC this is a kind of chicken-egg problem: when we're running out of specpdl > stack, we want to run a debugger, which, in turn, needs some specpdl space to run. So either we should reserve some space for the debugger, or enlarge max-specpdl-size before running the debugger, or refrain from running the debugger in this specific case. From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 31 03:12:33 2014 Received: (at 16603) by debbugs.gnu.org; 31 Jan 2014 08:12:33 +0000 Received: from localhost ([127.0.0.1]:42318 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W99DE-0002WQ-RT for submit@debbugs.gnu.org; Fri, 31 Jan 2014 03:12:33 -0500 Received: from hermes.netfonds.no ([80.91.224.195]:51085) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W99DC-0002WI-Tb for 16603@debbugs.gnu.org; Fri, 31 Jan 2014 03:12:31 -0500 Received: from [204.14.154.233] (helo=building.gnus.org) by hermes.netfonds.no with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1W99Cx-0000zL-Hs; Fri, 31 Jan 2014 09:12:15 +0100 From: Lars Ingebrigtsen To: Eli Zaretskii Subject: Re: bug#16603: 24.3.50; Segfault when viewing a backtrace References: <878utw28pl.fsf@building.gnus.org> <52EB4AB4.8040004@yandex.ru> <83eh3o7es6.fsf@gnu.org> Date: Fri, 31 Jan 2014 00:11:25 -0800 In-Reply-To: <83eh3o7es6.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 31 Jan 2014 10:10:17 +0200") Message-ID: <87ha8klgeq.fsf@building.gnus.org> User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-MailScanner-ID: 1W99Cx-0000zL-Hs X-Netfonds-MailScanner: Found to be clean X-Netfonds-MailScanner-From: larsi@gnus.org MailScanner-NULL-Check: 1391760736.77869@/kuFZawSGONPyukqiqrokg X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 16603 Cc: Dmitry Antipov , 16603@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.0 (/) Eli Zaretskii writes: > So either we should reserve some space for the debugger, or enlarge > max-specpdl-size before running the debugger, or refrain from running > the debugger in this specific case. Being able to run the debugger seems kinda nice. >"? So I think enlarging before running the debugger sounds like the right solution. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog http://lars.ingebrigtsen.no/ From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 31 03:37:29 2014 Received: (at 16603) by debbugs.gnu.org; 31 Jan 2014 08:37:29 +0000 Received: from localhost ([127.0.0.1]:42340 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W99bJ-0005RD-Ho for submit@debbugs.gnu.org; Fri, 31 Jan 2014 03:37:29 -0500 Received: from mtaout20.012.net.il ([80.179.55.166]:44449) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W99bD-0005Qy-JW for 16603@debbugs.gnu.org; Fri, 31 Jan 2014 03:37:23 -0500 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0N0900A00BNGSD00@a-mtaout20.012.net.il> for 16603@debbugs.gnu.org; Fri, 31 Jan 2014 10:37:18 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N0900A9OBY5SO10@a-mtaout20.012.net.il>; Fri, 31 Jan 2014 10:37:18 +0200 (IST) Date: Fri, 31 Jan 2014 10:37:21 +0200 From: Eli Zaretskii Subject: Re: bug#16603: 24.3.50; Segfault when viewing a backtrace In-reply-to: <87ha8klgeq.fsf@building.gnus.org> X-012-Sender: halo1@inter.net.il To: Lars Ingebrigtsen Message-id: <838utw7dj2.fsf@gnu.org> References: <878utw28pl.fsf@building.gnus.org> <52EB4AB4.8040004@yandex.ru> <83eh3o7es6.fsf@gnu.org> <87ha8klgeq.fsf@building.gnus.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 16603 Cc: dmantipov@yandex.ru, 16603@debbugs.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: Lars Ingebrigtsen > Cc: Dmitry Antipov , 16603@debbugs.gnu.org > Date: Fri, 31 Jan 2014 00:11:25 -0800 > > Eli Zaretskii writes: > > > So either we should reserve some space for the debugger, or enlarge > > max-specpdl-size before running the debugger, or refrain from running > > the debugger in this specific case. > > Being able to run the debugger seems kinda nice. >"? So I think > enlarging before running the debugger sounds like the right solution. Yes, assuming we can make sure the debugger itself does not try to traverse a circular structure. Also, we should disallow recursive re-entering the debugger in this case. But perhaps there are already facilities for that, I don't really know this area all that well. From debbugs-submit-bounces@debbugs.gnu.org Thu Feb 06 22:46:08 2014 Received: (at 16603) by debbugs.gnu.org; 7 Feb 2014 03:46:08 +0000 Received: from localhost ([127.0.0.1]:54015 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WBcOF-0005xh-FD for submit@debbugs.gnu.org; Thu, 06 Feb 2014 22:46:08 -0500 Received: from hermes.netfonds.no ([80.91.224.195]:35887) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WBcOD-0005xW-7P for 16603@debbugs.gnu.org; Thu, 06 Feb 2014 22:46:05 -0500 Received: from [204.14.154.233] (helo=building.gnus.org) by hermes.netfonds.no with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1WBcNy-000294-FW; Fri, 07 Feb 2014 04:45:50 +0100 From: Lars Ingebrigtsen To: Eli Zaretskii Subject: Re: bug#16603: 24.3.50; Segfault when viewing a backtrace References: <878utw28pl.fsf@building.gnus.org> <52EB4AB4.8040004@yandex.ru> <83eh3o7es6.fsf@gnu.org> <87ha8klgeq.fsf@building.gnus.org> <838utw7dj2.fsf@gnu.org> Date: Thu, 06 Feb 2014 19:44:44 -0800 In-Reply-To: <838utw7dj2.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 31 Jan 2014 10:37:21 +0200") Message-ID: <878utnk2mr.fsf@building.gnus.org> User-Agent: Gnus/5.13001 (Ma Gnus v0.10) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-MailScanner-ID: 1WBcNy-000294-FW X-Netfonds-MailScanner: Found to be clean X-Netfonds-MailScanner-From: larsi@gnus.org MailScanner-NULL-Check: 1392349550.91929@qCkYTorEg/mgog6AO9H3IQ X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 16603 Cc: dmantipov@yandex.ru, 16603@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.0 (/) This has been fixed now. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog http://lars.ingebrigtsen.no/ From debbugs-submit-bounces@debbugs.gnu.org Thu Feb 06 22:46:11 2014 Received: (at control) by debbugs.gnu.org; 7 Feb 2014 03:46:11 +0000 Received: from localhost ([127.0.0.1]:54019 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WBcOJ-0005y4-6z for submit@debbugs.gnu.org; Thu, 06 Feb 2014 22:46:11 -0500 Received: from hermes.netfonds.no ([80.91.224.195]:35898) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WBcOI-0005xv-78 for control@debbugs.gnu.org; Thu, 06 Feb 2014 22:46:10 -0500 Received: from [204.14.154.233] (helo=building.gnus.org) by hermes.netfonds.no with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1WBcO4-00029D-92 for control@debbugs.gnu.org; Fri, 07 Feb 2014 04:45:56 +0100 Date: Thu, 06 Feb 2014 19:44:50 -0800 Message-Id: <877g97k2ml.fsf@building.gnus.org> To: control@debbugs.gnu.org From: Lars Ingebrigtsen Subject: control message for bug #16603 X-MailScanner-ID: 1WBcO4-00029D-92 X-Netfonds-MailScanner: Found to be clean X-Netfonds-MailScanner-From: larsi@gnus.org MailScanner-NULL-Check: 1392349556.93167@jvuFJMhod1sLCMIZO8a2Dw X-Spam-Status: No X-Spam-Score: 0.0 (/) 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: 0.0 (/) close 16603 24.4 From debbugs-submit-bounces@debbugs.gnu.org Thu Feb 06 22:51:55 2014 Received: (at 16603) by debbugs.gnu.org; 7 Feb 2014 03:51:55 +0000 Received: from localhost ([127.0.0.1]:54030 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WBcTn-00068G-FH for submit@debbugs.gnu.org; Thu, 06 Feb 2014 22:51:55 -0500 Received: from hermes.netfonds.no ([80.91.224.195]:59287) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WBcTc-00067c-OC for 16603@debbugs.gnu.org; Thu, 06 Feb 2014 22:51:49 -0500 Received: from [204.14.154.233] (helo=building.gnus.org) by hermes.netfonds.no with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1WBcTF-0002Cg-03; Fri, 07 Feb 2014 04:51:17 +0100 From: Lars Ingebrigtsen To: Eli Zaretskii Subject: Re: bug#16603: 24.3.50; Segfault when viewing a backtrace References: <878utw28pl.fsf@building.gnus.org> <52EB4AB4.8040004@yandex.ru> <83eh3o7es6.fsf@gnu.org> <87ha8klgeq.fsf@building.gnus.org> <838utw7dj2.fsf@gnu.org> <878utnk2mr.fsf@building.gnus.org> Date: Thu, 06 Feb 2014 19:50:11 -0800 In-Reply-To: <878utnk2mr.fsf@building.gnus.org> (Lars Ingebrigtsen's message of "Thu, 06 Feb 2014 19:44:44 -0800") Message-ID: <8738jvk2do.fsf@building.gnus.org> User-Agent: Gnus/5.13001 (Ma Gnus v0.10) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-MailScanner-ID: 1WBcTF-0002Cg-03 X-Netfonds-MailScanner: Found to be clean X-Netfonds-MailScanner-From: larsi@gnus.org MailScanner-NULL-Check: 1392349878.07332@uvV+7bgrhTlXiYbb5gF/7w X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 16603 Cc: dmantipov@yandex.ru, 16603@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.0 (/) Lars Ingebrigtsen writes: > This has been fixed now. Oops. No, it hasn't. Or... uhm... I got a backtrace once (so that's fine), but then Emacs segfaulted. So it's changed, but the problem is still there. #0 mem_insert (start=start@entry=0x2089000, end=end@entry=0x20893e0, type=type@entry=MEM_TYPE_CONS) at alloc.c:3850 #1 0x000000000052f5fe in lisp_align_malloc (nbytes=nbytes@entry=992, type=type@entry=MEM_TYPE_CONS) at alloc.c:1134 #2 0x000000000052f80f in Fcons (car=car@entry=12217682, cdr=33946566) at alloc.c:2461 #3 0x000000000059497c in add_properties (plist=plist@entry=33946518, i=i@entry=0x1056618, object=object@entry=34019941, set_type=set_type@entry= TEXT_PROPERTY_REPLACE) at textprop.c:471 #4 0x0000000000596501 in add_text_properties_1 (start=6432, end=6476, properties=33946518, object=34019941, set_type=TEXT_PROPERTY_REPLACE) at textprop.c:1276 #5 0x0000000000548e14 in Ffuncall (nargs=, args=) at eval.c:2824 #6 0x000000000057c81d in exec_byte_code (bytestr=-6847441758440128512, vector=34116576, maxdepth=2, args_template=61, nargs=140737488257904, args=0x5) at bytecode.c:919 #7 0x000000000054890f in funcall_lambda (fun=9116093, nargs=nargs@entry=6, arg_vector=arg_vector@entry=0x7ffffffe8550) at eval.c:3047 #8 0x0000000000548c6b in Ffuncall (nargs=7, args=0x7ffffffe8548) at eval.c:2874 #9 0x000000000057c81d in exec_byte_code (bytestr=-6847441758440128512, vector=34116576, maxdepth=2, args_template=61, nargs=19, args=0x7) at bytecode.c:919 #10 0x000000000054890f in funcall_lambda (fun=34271429, nargs=nargs@entry=4, arg_vector=arg_vector@entry=0x7ffffffe8780) at eval.c:3047 #11 0x0000000000548c6b in Ffuncall (nargs=5, args=0x7ffffffe8778) at eval.c:2874 #12 0x000000000057c81d in exec_byte_code (bytestr=-6847441758440128512, vector=34116576, maxdepth=2, args_template=61, nargs=140737488258928, args=0x5) at bytecode.c:919 #13 0x00000000005489a7 in funcall_lambda (fun=31437373, nargs=nargs@entry=0, arg_vector=0x7ffffffe89a0, arg_vector@entry=0x7ffffffe8918) at eval.c:2981 #14 0x0000000000548c6b in Ffuncall (nargs=1, args=0x7ffffffe8910) at eval.c:2874 #15 0x000000000057c81d in exec_byte_code (bytestr=-6847441758440128512, vector=34116576, maxdepth=2, args_template=61, nargs=140737488259344, args=0x1) at bytecode.c:919 #16 0x00000000005489a7 in funcall_lambda (fun=31437037, nargs=nargs@entry=1, arg_vector=0x7ffffffe8c40, arg_vector@entry=0x7ffffffe8b88) at eval.c:2981 #17 0x0000000000548c6b in Ffuncall (nargs=2, args=0x7ffffffe8b80) at eval.c:2874 #18 0x000000000057c81d in exec_byte_code (bytestr=-6847441758440128512, vector=34116576, maxdepth=2, args_template=61, nargs=140737488259960, args=0x2) at bytecode.c:919 #19 0x00000000005489a7 in funcall_lambda (fun=31436661, nargs=nargs@entry=2, arg_vector=0x7ffffffe8fb0, arg_vector@entry=0x7ffffffe8d28) at eval.c:2981 #20 0x0000000000548c6b in Ffuncall (nargs=nargs@entry=3, args=args@entry=0x7ffffffe8d20) at eval.c:2874 #21 0x000000000054a05c in Fapply (nargs=nargs@entry=2, args=args@entry=0x7ffffffe8dc0) at eval.c:2352 #22 0x000000000054a290 in apply1 (fn=12153762, arg=arg@entry=34361910) at eval.c:2586 #23 0x000000000054a436 in call_debugger (arg=34361910) at eval.c:330 #24 0x00000000005493ad in maybe_call_debugger (data=34361958, sig=12081778, conditions=8584158) at eval.c:1731 #25 Fsignal (error_symbol=12081778, data=34361958) at eval.c:1549 #26 0x0000000000549579 in xsignal (error_symbol=, data=) at eval.c:1586 #27 0x0000000000549c44 in signal_error ( s=0x5de958 "Variable binding depth exceeds max-specpdl-size", arg=12030258) at eval.c:1641 #28 0x0000000000549cd2 in grow_specpdl () at eval.c:2030 #29 0x0000000000549dc6 in specbind (symbol=16201218, value=12030258) at eval.c:3145 #30 0x000000000057c7e3 in exec_byte_code (bytestr=-6847441758440128512, vector=34116576, maxdepth=2, args_template=61, nargs=140737488260888, args=0x5) at bytecode.c:881 #31 0x000000000054890f in funcall_lambda (fun=31472749, nargs=nargs@entry=1, etc It's a very very deep backtrace. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog http://lars.ingebrigtsen.no/ From unknown Mon Jun 23 22:04:42 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug No longer marked as fixed in versions 24.4 and reopened. Date: Fri, 07 Feb 2014 03:52:02 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug No longer marked as fixed in versions 24.4 and reopened. thanks # This fakemail brought to you by your local debbugs # administrator From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 07 00:48:14 2014 Received: (at 16603) by debbugs.gnu.org; 7 Feb 2014 05:48:15 +0000 Received: from localhost ([127.0.0.1]:54090 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WBeIQ-0001po-GL for submit@debbugs.gnu.org; Fri, 07 Feb 2014 00:48:14 -0500 Received: from forward1l.mail.yandex.net ([84.201.143.144]:44249) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WBeIN-0001pe-0y for 16603@debbugs.gnu.org; Fri, 07 Feb 2014 00:48:12 -0500 Received: from smtp4o.mail.yandex.net (smtp4o.mail.yandex.net [37.140.190.29]) by forward1l.mail.yandex.net (Yandex) with ESMTP id 664871520D02; Fri, 7 Feb 2014 09:48:09 +0400 (MSK) Received: from smtp4o.mail.yandex.net (localhost [127.0.0.1]) by smtp4o.mail.yandex.net (Yandex) with ESMTP id 10EEC232102E; Fri, 7 Feb 2014 09:48:08 +0400 (MSK) Received: from unknown (unknown [37.139.80.10]) by smtp4o.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id sO2T2oTggJ-m8S0Y7Ha; Fri, 7 Feb 2014 09:48:08 +0400 (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: 48e3e14f-db73-4f85-abdd-de03e6f17035 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1391752088; bh=MaO1rDGvektz2lsaeuiPm4uaj4lQeA7h/G397zzWFiA=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=WOjfO9DSNVBxFrNF7kWYOUU6i9l87kgbH6hhT+jUShdELnv34oHC5Wz2PG5Yagp1Y W/bsbn74YygDGF9YY+o63TlRCd6pAA2kxeMQPskyrshA5LNz4DFs5aZNgNCflLr4kX 4h1lSYZSGY6MWg8KqafIBNy/U8c81Y8Hkv3WoRhQ= Authentication-Results: smtp4o.mail.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <52F47397.5030509@yandex.ru> Date: Fri, 07 Feb 2014 09:48:07 +0400 From: Dmitry Antipov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Lars Ingebrigtsen Subject: Re: bug#16603: 24.3.50; Segfault when viewing a backtrace References: <878utw28pl.fsf@building.gnus.org> <52EB4AB4.8040004@yandex.ru> <83eh3o7es6.fsf@gnu.org> <87ha8klgeq.fsf@building.gnus.org> <838utw7dj2.fsf@gnu.org> <878utnk2mr.fsf@building.gnus.org> <8738jvk2do.fsf@building.gnus.org> In-Reply-To: <8738jvk2do.fsf@building.gnus.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 16603 Cc: 16603@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.0 (/) On 02/07/2014 07:50 AM, Lars Ingebrigtsen wrote: > Oops. No, it hasn't. Or... uhm... I got a backtrace once (so that's > fine), but then Emacs segfaulted. Doesn't crash for me. At least I can walk through *Backtrace* buffer and visit functions reported in the backtrace. > #0 mem_insert (start=start@entry=0x2089000, end=end@entry=0x20893e0, > type=type@entry=MEM_TYPE_CONS) at alloc.c:3850 This probably indicates a heap corruption. Could you please try to reproduce this crash with temacs under valgrind? I tried two times and there was nothing suspicious, BTW. Dmitry From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 07 20:24:58 2014 Received: (at 16603) by debbugs.gnu.org; 8 Feb 2014 01:24:58 +0000 Received: from localhost ([127.0.0.1]:55568 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WBwfA-0005SZ-3I for submit@debbugs.gnu.org; Fri, 07 Feb 2014 20:24:58 -0500 Received: from hermes.netfonds.no ([80.91.224.195]:35098) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WBwf5-0005SO-TN for 16603@debbugs.gnu.org; Fri, 07 Feb 2014 20:24:54 -0500 Received: from [204.14.154.233] (helo=building.gnus.org) by hermes.netfonds.no with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1WBwep-0002lz-R6; Sat, 08 Feb 2014 02:24:36 +0100 From: Lars Ingebrigtsen To: Dmitry Antipov Subject: Re: bug#16603: 24.3.50; Segfault when viewing a backtrace References: <878utw28pl.fsf@building.gnus.org> <52EB4AB4.8040004@yandex.ru> <83eh3o7es6.fsf@gnu.org> <87ha8klgeq.fsf@building.gnus.org> <838utw7dj2.fsf@gnu.org> <878utnk2mr.fsf@building.gnus.org> <8738jvk2do.fsf@building.gnus.org> <52F47397.5030509@yandex.ru> Date: Fri, 07 Feb 2014 17:23:28 -0800 In-Reply-To: <52F47397.5030509@yandex.ru> (Dmitry Antipov's message of "Fri, 07 Feb 2014 09:48:07 +0400") Message-ID: <87eh3ecs8f.fsf@building.gnus.org> User-Agent: Gnus/5.13001 (Ma Gnus v0.10) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-MailScanner-ID: 1WBwep-0002lz-R6 X-Netfonds-MailScanner: Found to be clean X-Netfonds-MailScanner-From: larsi@gnus.org MailScanner-NULL-Check: 1392427476.94523@xzeMv16G9qf+cvsijYhIVQ X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 16603 Cc: 16603@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.0 (/) Dmitry Antipov writes: > On 02/07/2014 07:50 AM, Lars Ingebrigtsen wrote: > >> Oops. No, it hasn't. Or... uhm... I got a backtrace once (so that's >> fine), but then Emacs segfaulted. > > Doesn't crash for me. At least I can walk through *Backtrace* buffer > and visit functions reported in the backtrace. Yeah, that works fine. But: >> #0 mem_insert (start=start@entry=0x2089000, end=end@entry=0x20893e0, >> type=type@entry=MEM_TYPE_CONS) at alloc.c:3850 > > This probably indicates a heap corruption. Could you please try > to reproduce this crash with temacs under valgrind? I tried two > times and there was nothing suspicious, BTW. If you select Rotem's article three times (jumping out of the backtrace the first two times), Emacs will segfault the third time. It seems to be totally reproducible for me. I don't know how much of the valgrind output to include. It's 15K lines. Before the crash, I get lots of the following: ==13139== Invalid read of size 8 ==13139== at 0x547BA7: unbind_to (eval.c:3299) ==13139== by 0x547CB2: unwind_to_catch (eval.c:1165) ==13139== by 0x549B9E: Fthrow (eval.c:1195) ==13139== by 0x4E14F6: Ftop_level (keyboard.c:1209) ==13139== by 0x548E4B: Ffuncall (eval.c:2810) ==13139== by 0x54528F: Fcall_interactively (callint.c:836) ==13139== by 0x548E27: Ffuncall (eval.c:2820) ==13139== by 0x57C81C: exec_byte_code (bytecode.c:919) ==13139== by 0x548C6A: Ffuncall (eval.c:2874) ==13139== by 0x548F89: call1 (eval.c:2612) ==13139== by 0x4E6F5C: command_loop_1 (keyboard.c:1552) ==13139== by 0x5472ED: internal_condition_case (eval.c:1352) ==13139== Address 0x21f315e8 is 1,352 bytes inside a block of size 65,536 free'd ==13139== at 0x4A074C4: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==13139== by 0x547AFD: unbind_to (eval.c:3307) ==13139== by 0x48A5C9: decode_coding (coding.c:7468) ==13139== by 0x48EBB1: decode_coding_object (coding.c:8125) ==13139== by 0x490C54: code_convert_string (coding.c:9472) ==13139== by 0x508315: Fexpand_file_name (fileio.c:1178) ==13139== by 0x507CD6: Fexpand_file_name (fileio.c:982) ==13139== by 0x507CD6: Fexpand_file_name (fileio.c:982) ==13139== by 0x567E41: openp (lread.c:1500) ==13139== by 0x56B0B5: Fload (lread.c:1137) ==13139== by 0x54A59F: Fautoload_do_load (eval.c:1968) ==13139== by 0x548BA2: Ffuncall (eval.c:2877) ==13139== ==13139== Invalid read of size 8 ==13139== at 0x547BBA: unbind_to (eval.c:3334) ==13139== by 0x547CB2: unwind_to_catch (eval.c:1165) ==13139== by 0x549B9E: Fthrow (eval.c:1195) ==13139== by 0x4E14F6: Ftop_level (keyboard.c:1209) ==13139== by 0x548E4B: Ffuncall (eval.c:2810) ==13139== by 0x54528F: Fcall_interactively (callint.c:836) ==13139== by 0x548E27: Ffuncall (eval.c:2820) ==13139== by 0x57C81C: exec_byte_code (bytecode.c:919) ==13139== by 0x548C6A: Ffuncall (eval.c:2874) ==13139== by 0x548F89: call1 (eval.c:2612) ==13139== by 0x4E6F5C: command_loop_1 (keyboard.c:1552) ==13139== by 0x5472ED: internal_condition_case (eval.c:1352) ==13139== Address 0x21f315f0 is 1,360 bytes inside a block of size 65,536 free'd ==13139== at 0x4A074C4: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==13139== by 0x547AFD: unbind_to (eval.c:3307) ==13139== by 0x48A5C9: decode_coding (coding.c:7468) ==13139== by 0x48EBB1: decode_coding_object (coding.c:8125) ==13139== by 0x490C54: code_convert_string (coding.c:9472) ==13139== by 0x508315: Fexpand_file_name (fileio.c:1178) ==13139== by 0x507CD6: Fexpand_file_name (fileio.c:982) ==13139== by 0x507CD6: Fexpand_file_name (fileio.c:982) ==13139== by 0x567E41: openp (lread.c:1500) ==13139== by 0x56B0B5: Fload (lread.c:1137) ==13139== by 0x54A59F: Fautoload_do_load (eval.c:1968) ==13139== by 0x548BA2: Ffuncall (eval.c:2877) ==13139== ==13139== Invalid read of size 8 ==13139== at 0x547BF7: unbind_to (eval.c:3313) ==13139== by 0x547CB2: unwind_to_catch (eval.c:1165) ==13139== by 0x549B9E: Fthrow (eval.c:1195) ==13139== by 0x4E14F6: Ftop_level (keyboard.c:1209) ==13139== by 0x548E4B: Ffuncall (eval.c:2810) ==13139== by 0x54528F: Fcall_interactively (callint.c:836) ==13139== by 0x548E27: Ffuncall (eval.c:2820) ==13139== by 0x57C81C: exec_byte_code (bytecode.c:919) ==13139== by 0x548C6A: Ffuncall (eval.c:2874) ==13139== by 0x548F89: call1 (eval.c:2612) ==13139== by 0x4E6F5C: command_loop_1 (keyboard.c:1552) ==13139== by 0x5472ED: internal_condition_case (eval.c:1352) ==13139== Address 0x21f31588 is 1,256 bytes inside a block of size 65,536 free'd ==13139== at 0x4A074C4: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==13139== by 0x547AFD: unbind_to (eval.c:3307) ==13139== by 0x48A5C9: decode_coding (coding.c:7468) ==13139== by 0x48EBB1: decode_coding_object (coding.c:8125) ==13139== by 0x490C54: code_convert_string (coding.c:9472) ==13139== by 0x508315: Fexpand_file_name (fileio.c:1178) ==13139== by 0x507CD6: Fexpand_file_name (fileio.c:982) ==13139== by 0x507CD6: Fexpand_file_name (fileio.c:982) ==13139== by 0x567E41: openp (lread.c:1500) ==13139== by 0x56B0B5: Fload (lread.c:1137) ==13139== by 0x54A59F: Fautoload_do_load (eval.c:1968) ==13139== by 0x548BA2: Ffuncall (eval.c:2877) ==13139== ==13139== Invalid read of size 8 ==13139== at 0x547AF7: unbind_to (eval.c:3307) ==13139== by 0x547CB2: unwind_to_catch (eval.c:1165) ==13139== by 0x549B9E: Fthrow (eval.c:1195) ==13139== by 0x4E14F6: Ftop_level (keyboard.c:1209) ==13139== by 0x548E4B: Ffuncall (eval.c:2810) ==13139== by 0x54528F: Fcall_interactively (callint.c:836) ==13139== by 0x548E27: Ffuncall (eval.c:2820) ==13139== by 0x57C81C: exec_byte_code (bytecode.c:919) ==13139== by 0x548C6A: Ffuncall (eval.c:2874) ==13139== by 0x548F89: call1 (eval.c:2612) ==13139== by 0x4E6F5C: command_loop_1 (keyboard.c:1552) ==13139== by 0x5472ED: internal_condition_case (eval.c:1352) ==13139== Address 0x21f31510 is 1,136 bytes inside a block of size 65,536 free'd ==13139== at 0x4A074C4: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==13139== by 0x547AFD: unbind_to (eval.c:3307) ==13139== by 0x48A5C9: decode_coding (coding.c:7468) ==13139== by 0x48EBB1: decode_coding_object (coding.c:8125) ==13139== by 0x490C54: code_convert_string (coding.c:9472) ==13139== by 0x508315: Fexpand_file_name (fileio.c:1178) ==13139== by 0x507CD6: Fexpand_file_name (fileio.c:982) ==13139== by 0x507CD6: Fexpand_file_name (fileio.c:982) ==13139== by 0x567E41: openp (lread.c:1500) ==13139== by 0x56B0B5: Fload (lread.c:1137) ==13139== by 0x54A59F: Fautoload_do_load (eval.c:1968) ==13139== by 0x548BA2: Ffuncall (eval.c:2877) ==13139== ==13139== Invalid read of size 8 ==13139== at 0x547AFB: unbind_to (eval.c:3307) ==13139== by 0x547CB2: unwind_to_catch (eval.c:1165) ==13139== by 0x549B9E: Fthrow (eval.c:1195) ==13139== by 0x4E14F6: Ftop_level (keyboard.c:1209) ==13139== by 0x548E4B: Ffuncall (eval.c:2810) ==13139== by 0x54528F: Fcall_interactively (callint.c:836) ==13139== by 0x548E27: Ffuncall (eval.c:2820) ==13139== by 0x57C81C: exec_byte_code (bytecode.c:919) ==13139== by 0x548C6A: Ffuncall (eval.c:2874) ==13139== by 0x548F89: call1 (eval.c:2612) ==13139== by 0x4E6F5C: command_loop_1 (keyboard.c:1552) ==13139== by 0x5472ED: internal_condition_case (eval.c:1352) ==13139== Address 0x21f31508 is 1,128 bytes inside a block of size 65,536 free'd ==13139== at 0x4A074C4: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==13139== by 0x547AFD: unbind_to (eval.c:3307) ==13139== by 0x48A5C9: decode_coding (coding.c:7468) ==13139== by 0x48EBB1: decode_coding_object (coding.c:8125) ==13139== by 0x490C54: code_convert_string (coding.c:9472) ==13139== by 0x508315: Fexpand_file_name (fileio.c:1178) ==13139== by 0x507CD6: Fexpand_file_name (fileio.c:982) ==13139== by 0x507CD6: Fexpand_file_name (fileio.c:982) ==13139== by 0x567E41: openp (lread.c:1500) ==13139== by 0x56B0B5: Fload (lread.c:1137) ==13139== by 0x54A59F: Fautoload_do_load (eval.c:1968) ==13139== by 0x548BA2: Ffuncall (eval.c:2877) ==13139== ==13139== Invalid read of size 8 ==13139== at 0x547B4F: unbind_to (eval.c:3299) ==13139== by 0x547CB2: unwind_to_catch (eval.c:1165) ==13139== by 0x549B9E: Fthrow (eval.c:1195) ==13139== by 0x4E14F6: Ftop_level (keyboard.c:1209) ==13139== by 0x548E4B: Ffuncall (eval.c:2810) ==13139== by 0x54528F: Fcall_interactively (callint.c:836) ==13139== by 0x548E27: Ffuncall (eval.c:2820) ==13139== by 0x57C81C: exec_byte_code (bytecode.c:919) ==13139== by 0x548C6A: Ffuncall (eval.c:2874) ==13139== by 0x548F89: call1 (eval.c:2612) ==13139== by 0x4E6F5C: command_loop_1 (keyboard.c:1552) ==13139== by 0x5472ED: internal_condition_case (eval.c:1352) ==13139== Address 0x21f31468 is 968 bytes inside a block of size 65,536 free'd ==13139== at 0x4A074C4: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==13139== by 0x547AFD: unbind_to (eval.c:3307) ==13139== by 0x48A5C9: decode_coding (coding.c:7468) ==13139== by 0x48EBB1: decode_coding_object (coding.c:8125) ==13139== by 0x490C54: code_convert_string (coding.c:9472) ==13139== by 0x508315: Fexpand_file_name (fileio.c:1178) ==13139== by 0x507CD6: Fexpand_file_name (fileio.c:982) ==13139== by 0x507CD6: Fexpand_file_name (fileio.c:982) ==13139== by 0x567E41: openp (lread.c:1500) ==13139== by 0x56B0B5: Fload (lread.c:1137) ==13139== by 0x54A59F: Fautoload_do_load (eval.c:1968) ==13139== by 0x548BA2: Ffuncall (eval.c:2877) ==13139== ==13139== Invalid read of size 8 ==13139== at 0x547B53: unbind_to (eval.c:3299) ==13139== by 0x547CB2: unwind_to_catch (eval.c:1165) ==13139== by 0x549B9E: Fthrow (eval.c:1195) ==13139== by 0x4E14F6: Ftop_level (keyboard.c:1209) ==13139== by 0x548E4B: Ffuncall (eval.c:2810) ==13139== by 0x54528F: Fcall_interactively (callint.c:836) ==13139== by 0x548E27: Ffuncall (eval.c:2820) ==13139== by 0x57C81C: exec_byte_code (bytecode.c:919) ==13139== by 0x548C6A: Ffuncall (eval.c:2874) ==13139== by 0x548F89: call1 (eval.c:2612) ==13139== by 0x4E6F5C: command_loop_1 (keyboard.c:1552) ==13139== by 0x5472ED: internal_condition_case (eval.c:1352) ==13139== Address 0x21f31478 is 984 bytes inside a block of size 65,536 free'd ==13139== at 0x4A074C4: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==13139== by 0x547AFD: unbind_to (eval.c:3307) ==13139== by 0x48A5C9: decode_coding (coding.c:7468) ==13139== by 0x48EBB1: decode_coding_object (coding.c:8125) ==13139== by 0x490C54: code_convert_string (coding.c:9472) ==13139== by 0x508315: Fexpand_file_name (fileio.c:1178) ==13139== by 0x507CD6: Fexpand_file_name (fileio.c:982) ==13139== by 0x507CD6: Fexpand_file_name (fileio.c:982) ==13139== by 0x567E41: openp (lread.c:1500) ==13139== by 0x56B0B5: Fload (lread.c:1137) ==13139== by 0x54A59F: Fautoload_do_load (eval.c:1968) ==13139== by 0x548BA2: Ffuncall (eval.c:2877) ==13139== ==13139== Invalid read of size 8 ==13139== at 0x547B57: unbind_to (eval.c:3299) ==13139== by 0x547CB2: unwind_to_catch (eval.c:1165) ==13139== by 0x549B9E: Fthrow (eval.c:1195) ==13139== by 0x4E14F6: Ftop_level (keyboard.c:1209) ==13139== by 0x548E4B: Ffuncall (eval.c:2810) ==13139== by 0x54528F: Fcall_interactively (callint.c:836) ==13139== by 0x548E27: Ffuncall (eval.c:2820) ==13139== by 0x57C81C: exec_byte_code (bytecode.c:919) ==13139== by 0x548C6A: Ffuncall (eval.c:2874) ==13139== by 0x548F89: call1 (eval.c:2612) ==13139== by 0x4E6F5C: command_loop_1 (keyboard.c:1552) ==13139== by 0x5472ED: internal_condition_case (eval.c:1352) ==13139== Address 0x21f31470 is 976 bytes inside a block of size 65,536 free'd ==13139== at 0x4A074C4: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==13139== by 0x547AFD: unbind_to (eval.c:3307) ==13139== by 0x48A5C9: decode_coding (coding.c:7468) ==13139== by 0x48EBB1: decode_coding_object (coding.c:8125) ==13139== by 0x490C54: code_convert_string (coding.c:9472) ==13139== by 0x508315: Fexpand_file_name (fileio.c:1178) ==13139== by 0x507CD6: Fexpand_file_name (fileio.c:982) ==13139== by 0x507CD6: Fexpand_file_name (fileio.c:982) ==13139== by 0x567E41: openp (lread.c:1500) ==13139== by 0x56B0B5: Fload (lread.c:1137) ==13139== by 0x54A59F: Fautoload_do_load (eval.c:1968) ==13139== by 0x548BA2: Ffuncall (eval.c:2877) ==13139== ==13139== Invalid read of size 8 ==13139== at 0x547C40: unbind_to (eval.c:3299) ==13139== by 0x547CB2: unwind_to_catch (eval.c:1165) ==13139== by 0x549B9E: Fthrow (eval.c:1195) ==13139== by 0x4E14F6: Ftop_level (keyboard.c:1209) ==13139== by 0x548E4B: Ffuncall (eval.c:2810) ==13139== by 0x54528F: Fcall_interactively (callint.c:836) ==13139== by 0x548E27: Ffuncall (eval.c:2820) ==13139== by 0x57C81C: exec_byte_code (bytecode.c:919) ==13139== by 0x548C6A: Ffuncall (eval.c:2874) ==13139== by 0x548F89: call1 (eval.c:2612) ==13139== by 0x4E6F5C: command_loop_1 (keyboard.c:1552) ==13139== by 0x5472ED: internal_condition_case (eval.c:1352) ==13139== Address 0x21f313b0 is 784 bytes inside a block of size 65,536 free'd ==13139== at 0x4A074C4: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==13139== by 0x547AFD: unbind_to (eval.c:3307) ==13139== by 0x48A5C9: decode_coding (coding.c:7468) ==13139== by 0x48EBB1: decode_coding_object (coding.c:8125) ==13139== by 0x490C54: code_convert_string (coding.c:9472) ==13139== by 0x508315: Fexpand_file_name (fileio.c:1178) ==13139== by 0x507CD6: Fexpand_file_name (fileio.c:982) ==13139== by 0x507CD6: Fexpand_file_name (fileio.c:982) ==13139== by 0x567E41: openp (lread.c:1500) ==13139== by 0x56B0B5: Fload (lread.c:1137) ==13139== by 0x54A59F: Fautoload_do_load (eval.c:1968) ==13139== by 0x548BA2: Ffuncall (eval.c:2877) ==13139== Then when it actually crashes, this is what's output: valgrind: m_mallocfree.c:294 (get_bszB_as_is): Assertion 'bszB_lo == bszB_hi' failed. valgrind: Heap block lo/hi size mismatch: lo = 65541, hi = 489626271855. This is probably caused by your program erroneously writing past the end of a heap block and corrupting heap metadata. If you fix any invalid writes reported by Memcheck, this assertion failure will probably go away. Please try that before reporting this as a bug. ==13139== at 0x38059B6F: ??? (in /usr/lib64/valgrind/memcheck-amd64-linux) ==13139== by 0x38059CB2: ??? (in /usr/lib64/valgrind/memcheck-amd64-linux) ==13139== by 0x38066556: ??? (in /usr/lib64/valgrind/memcheck-amd64-linux) ==13139== by 0x3802C465: ??? (in /usr/lib64/valgrind/memcheck-amd64-linux) ==13139== by 0x3802CA6B: ??? (in /usr/lib64/valgrind/memcheck-amd64-linux) ==13139== by 0x3802CC32: ??? (in /usr/lib64/valgrind/memcheck-amd64-linux) ==13139== by 0x3809F3AD: ??? (in /usr/lib64/valgrind/memcheck-amd64-linux) ==13139== by 0x380AE0FC: ??? (in /usr/lib64/valgrind/memcheck-amd64-linux) sched status: running_tid=1 Thread 1: status = VgTs_Runnable ==13139== at 0x4A06409: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==13139== by 0x52DC0C: xmalloc (alloc.c:677) ==13139== by 0x5640C9: Fprin1 (print.c:560) ==13139== by 0x546D14: Fbacktrace (eval.c:3414) ==13139== by 0x548E4B: Ffuncall (eval.c:2810) ==13139== by 0x57C81C: exec_byte_code (bytecode.c:919) ==13139== by 0x548C6A: Ffuncall (eval.c:2874) ==13139== by 0x57C81C: exec_byte_code (bytecode.c:919) ==13139== by 0x548C6A: Ffuncall (eval.c:2874) ==13139== by 0x54A05B: Fapply (eval.c:2352) ==13139== by 0x54A28F: apply1 (eval.c:2586) ==13139== by 0x54A435: call_debugger (eval.c:330) ==13139== by 0x5493AC: Fsignal (eval.c:1731) ==13139== by 0x549578: xsignal (eval.c:1586) ==13139== by 0x549C43: signal_error (eval.c:1641) ==13139== by 0x549CD1: grow_specpdl (eval.c:2030) ==13139== by 0x549DC5: specbind (eval.c:3145) ==13139== by 0x57C7E2: exec_byte_code (bytecode.c:881) ==13139== by 0x54890E: funcall_lambda (eval.c:3047) ==13139== by 0x548C6A: Ffuncall (eval.c:2874) ==13139== by 0x57C81C: exec_byte_code (bytecode.c:919) ==13139== by 0x54890E: funcall_lambda (eval.c:3047) ==13139== by 0x548C6A: Ffuncall (eval.c:2874) ==13139== by 0x57C81C: exec_byte_code (bytecode.c:919) ==13139== by 0x54890E: funcall_lambda (eval.c:3047) ==13139== by 0x548C6A: Ffuncall (eval.c:2874) ==13139== by 0x57C81C: exec_byte_code (bytecode.c:919) ==13139== by 0x54890E: funcall_lambda (eval.c:3047) ==13139== by 0x548C6A: Ffuncall (eval.c:2874) ==13139== by 0x57C81C: exec_byte_code (bytecode.c:919) ==13139== by 0x54890E: funcall_lambda (eval.c:3047) ==13139== by 0x548C6A: Ffuncall (eval.c:2874) ==13139== by 0x57C81C: exec_byte_code (bytecode.c:919) ==13139== by 0x54890E: funcall_lambda (eval.c:3047) ==13139== by 0x548C6A: Ffuncall (eval.c:2874) ==13139== by 0x57C81C: exec_byte_code (bytecode.c:919) ==13139== by 0x54890E: funcall_lambda (eval.c:3047) ==13139== by 0x548C6A: Ffuncall (eval.c:2874) ==13139== by 0x57C81C: exec_byte_code (bytecode.c:919) ==13139== by 0x54890E: funcall_lambda (eval.c:3047) ==13139== by 0x548C6A: Ffuncall (eval.c:2874) ==13139== by 0x57C81C: exec_byte_code (bytecode.c:919) ==13139== by 0x54890E: funcall_lambda (eval.c:3047) ==13139== by 0x548C6A: Ffuncall (eval.c:2874) ==13139== by 0x57C81C: exec_byte_code (bytecode.c:919) ==13139== by 0x54890E: funcall_lambda (eval.c:3047) ==13139== by 0x548C6A: Ffuncall (eval.c:2874) ==13139== by 0x57C81C: exec_byte_code (bytecode.c:919) ==13139== by 0x54890E: funcall_lambda (eval.c:3047) ==13139== by 0x548C6A: Ffuncall (eval.c:2874) ==13139== by 0x57C81C: exec_byte_code (bytecode.c:919) ==13139== by 0x54890E: funcall_lambda (eval.c:3047) ==13139== by 0x548C6A: Ffuncall (eval.c:2874) ==13139== by 0x57C81C: exec_byte_code (bytecode.c:919) ==13139== by 0x54890E: funcall_lambda (eval.c:3047) ==13139== by 0x548C6A: Ffuncall (eval.c:2874) ==13139== by 0x57C81C: exec_byte_code (bytecode.c:919) ==13139== by 0x54890E: funcall_lambda (eval.c:3047) ==13139== by 0x548C6A: Ffuncall (eval.c:2874) ==13139== by 0x57C81C: exec_byte_code (bytecode.c:919) ==13139== by 0x54890E: funcall_lambda (eval.c:3047) ==13139== by 0x548C6A: Ffuncall (eval.c:2874) ==13139== by 0x57C81C: exec_byte_code (bytecode.c:919) ==13139== by 0x54890E: funcall_lambda (eval.c:3047) ==13139== by 0x548C6A: Ffuncall (eval.c:2874) ==13139== by 0x57C81C: exec_byte_code (bytecode.c:919) ==13139== by 0x54890E: funcall_lambda (eval.c:3047) ==13139== by 0x548C6A: Ffuncall (eval.c:2874) ==13139== by 0x57C81C: exec_byte_code (bytecode.c:919) ==13139== by 0x54890E: funcall_lambda (eval.c:3047) ==13139== by 0x548C6A: Ffuncall (eval.c:2874) ==13139== by 0x57C81C: exec_byte_code (bytecode.c:919) ==13139== by 0x54890E: funcall_lambda (eval.c:3047) ==13139== by 0x548C6A: Ffuncall (eval.c:2874) ==13139== by 0x57C81C: exec_byte_code (bytecode.c:919) ==13139== by 0x54890E: funcall_lambda (eval.c:3047) ==13139== by 0x548C6A: Ffuncall (eval.c:2874) ==13139== by 0x57C81C: exec_byte_code (bytecode.c:919) ==13139== by 0x54890E: funcall_lambda (eval.c:3047) ==13139== by 0x548C6A: Ffuncall (eval.c:2874) ==13139== by 0x57C81C: exec_byte_code (bytecode.c:919) ==13139== by 0x54890E: funcall_lambda (eval.c:3047) ==13139== by 0x548C6A: Ffuncall (eval.c:2874) ==13139== by 0x57C81C: exec_byte_code (bytecode.c:919) ==13139== by 0x54890E: funcall_lambda (eval.c:3047) ==13139== by 0x548C6A: Ffuncall (eval.c:2874) ==13139== by 0x57C81C: exec_byte_code (bytecode.c:919) ==13139== by 0x54890E: funcall_lambda (eval.c:3047) ==13139== by 0x548C6A: Ffuncall (eval.c:2874) ==13139== by 0x57C81C: exec_byte_code (bytecode.c:919) ==13139== by 0x54890E: funcall_lambda (eval.c:3047) ==13139== by 0x548C6A: Ffuncall (eval.c:2874) ==13139== by 0x57C81C: exec_byte_code (bytecode.c:919) ==13139== by 0x54890E: funcall_lambda (eval.c:3047) ==13139== by 0x548C6A: Ffuncall (eval.c:2874) ==13139== by 0x57C81C: exec_byte_code (bytecode.c:919) ==13139== by 0x54890E: funcall_lambda (eval.c:3047) ==13139== by 0x548C6A: Ffuncall (eval.c:2874) ==13139== by 0x57C81C: exec_byte_code (bytecode.c:919) ==13139== by 0x54890E: funcall_lambda (eval.c:3047) Thread 2: status = VgTs_WaitSys ==13139== at 0x3F49AEB7FD: ??? (in /usr/lib64/libc-2.17.so) ==13139== by 0x3F4BE480E3: ??? (in /usr/lib64/libglib-2.0.so.0.3600.3) ==13139== by 0x3F4BE481EB: g_main_context_iteration (in /usr/lib64/libglib-2.0.so.0.3600.3) ==13139== by 0x3F4BE48238: ??? (in /usr/lib64/libglib-2.0.so.0.3600.3) ==13139== by 0x3F4BE6C164: ??? (in /usr/lib64/libglib-2.0.so.0.3600.3) ==13139== by 0x3F4A207C52: start_thread (in /usr/lib64/libpthread-2.17.so) ==13139== by 0x3F49AF5DBC: clone (in /usr/lib64/libc-2.17.so) Thread 3: status = VgTs_WaitSys ==13139== at 0x3F49AEB7FD: ??? (in /usr/lib64/libc-2.17.so) ==13139== by 0x3F4BE480E3: ??? (in /usr/lib64/libglib-2.0.so.0.3600.3) ==13139== by 0x3F4BE48549: g_main_loop_run (in /usr/lib64/libglib-2.0.so.0.3600.3) ==13139== by 0x3F4D2C6DB5: ??? (in /usr/lib64/libgio-2.0.so.0.3600.3) ==13139== by 0x3F4BE6C164: ??? (in /usr/lib64/libglib-2.0.so.0.3600.3) ==13139== by 0x3F4A207C52: start_thread (in /usr/lib64/libpthread-2.17.so) ==13139== by 0x3F49AF5DBC: clone (in /usr/lib64/libc-2.17.so) Thread 4: status = VgTs_WaitSys ==13139== at 0x3F49AEB7FD: ??? (in /usr/lib64/libc-2.17.so) ==13139== by 0x3F4BE480E3: ??? (in /usr/lib64/libglib-2.0.so.0.3600.3) ==13139== by 0x3F4BE481EB: g_main_context_iteration (in /usr/lib64/libglib-2.0.so.0.3600.3) ==13139== by 0x208B79CC: ??? (in /usr/lib64/gio/modules/libdconfsettings.so) ==13139== by 0x3F4BE6C164: ??? (in /usr/lib64/libglib-2.0.so.0.3600.3) ==13139== by 0x3F4A207C52: start_thread (in /usr/lib64/libpthread-2.17.so) ==13139== by 0x3F49AF5DBC: clone (in /usr/lib64/libc-2.17.so) Note: see also the FAQ in the source distribution. It contains workarounds to several common problems. In particular, if Valgrind aborted or crashed after identifying problems in your program, there's a good chance that fixing those problems will prevent Valgrind aborting or crashing, especially if it happened in m_mallocfree.c. If that doesn't help, please report this bug to: www.valgrind.org In the bug report, send all the above text, the valgrind version, and what OS and version you are using. Thanks. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog http://lars.ingebrigtsen.no/ From debbugs-submit-bounces@debbugs.gnu.org Mon Feb 10 01:26:48 2014 Received: (at 16603) by debbugs.gnu.org; 10 Feb 2014 06:26:48 +0000 Received: from localhost ([127.0.0.1]:33754 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WCkKM-0006TO-96 for submit@debbugs.gnu.org; Mon, 10 Feb 2014 01:26:47 -0500 Received: from forward9l.mail.yandex.net ([84.201.143.142]:46070) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WCkKH-0006T4-GB for 16603@debbugs.gnu.org; Mon, 10 Feb 2014 01:26:43 -0500 Received: from smtp19.mail.yandex.net (smtp19.mail.yandex.net [95.108.252.19]) by forward9l.mail.yandex.net (Yandex) with ESMTP id D7773E607F8; Mon, 10 Feb 2014 10:26:39 +0400 (MSK) Received: from smtp19.mail.yandex.net (localhost [127.0.0.1]) by smtp19.mail.yandex.net (Yandex) with ESMTP id 877AFBE00BB; Mon, 10 Feb 2014 10:26:39 +0400 (MSK) Received: from unknown (unknown [37.139.80.10]) by smtp19.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id QgyPxkcNWj-QdeKx9j5; Mon, 10 Feb 2014 10:26:39 +0400 (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: 270b7af3-8469-4857-9fa6-00188ae1e26a DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1392013599; bh=s6jY6sRxYGcVh+4R4MOgRAL/z/B18dBn+/8zfT7i+Rc=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=C9pqj3DDWuptnRl51gh9x5cda/2NKCqzOSCjalSOZsu7IqnaaXFSS3OViek5ftCxq c7lEiYMMGwzMtSolZG9knNi0TSQTw2XKFJIhQpJKXfcgOCLtt3It6yKdqXmkkqJh9v cKtVh0kev8sxuH58JGSXxChPS57LJoJs8Adq4ug8= Authentication-Results: smtp19.mail.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <52F8711E.7070602@yandex.ru> Date: Mon, 10 Feb 2014 10:26:38 +0400 From: Dmitry Antipov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Lars Ingebrigtsen Subject: Re: bug#16603: 24.3.50; Segfault when viewing a backtrace References: <878utw28pl.fsf@building.gnus.org> <52EB4AB4.8040004@yandex.ru> <83eh3o7es6.fsf@gnu.org> <87ha8klgeq.fsf@building.gnus.org> <838utw7dj2.fsf@gnu.org> <878utnk2mr.fsf@building.gnus.org> <8738jvk2do.fsf@building.gnus.org> <52F47397.5030509@yandex.ru> <87eh3ecs8f.fsf@building.gnus.org> In-Reply-To: <87eh3ecs8f.fsf@building.gnus.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 16603 Cc: 16603@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.0 (/) On 02/08/2014 05:23 AM, Lars Ingebrigtsen wrote: > If you select Rotem's article three times (jumping out of the backtrace > the first two times), Emacs will segfault the third time. It seems to > be totally reproducible for me. I have the varying results, but no crash. Can you provide an exact key/command sequence causing the crash? And, of course, do you start from 'emacs -Q'? Dmitry From debbugs-submit-bounces@debbugs.gnu.org Mon Feb 10 01:38:45 2014 Received: (at 16603) by debbugs.gnu.org; 10 Feb 2014 06:38:45 +0000 Received: from localhost ([127.0.0.1]:33767 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WCkVw-0006pz-Ea for submit@debbugs.gnu.org; Mon, 10 Feb 2014 01:38:44 -0500 Received: from hermes.netfonds.no ([80.91.224.195]:33658) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WCkVs-0006pn-HK for 16603@debbugs.gnu.org; Mon, 10 Feb 2014 01:38:43 -0500 Received: from [204.14.154.233] (helo=building.gnus.org) by hermes.netfonds.no with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1WCkVe-0007nu-6Z; Mon, 10 Feb 2014 07:38:26 +0100 From: Lars Ingebrigtsen To: Dmitry Antipov Subject: Re: bug#16603: 24.3.50; Segfault when viewing a backtrace References: <878utw28pl.fsf@building.gnus.org> <52EB4AB4.8040004@yandex.ru> <83eh3o7es6.fsf@gnu.org> <87ha8klgeq.fsf@building.gnus.org> <838utw7dj2.fsf@gnu.org> <878utnk2mr.fsf@building.gnus.org> <8738jvk2do.fsf@building.gnus.org> <52F47397.5030509@yandex.ru> <87eh3ecs8f.fsf@building.gnus.org> <52F8711E.7070602@yandex.ru> Date: Sun, 09 Feb 2014 22:37:12 -0800 In-Reply-To: <52F8711E.7070602@yandex.ru> (Dmitry Antipov's message of "Mon, 10 Feb 2014 10:26:38 +0400") Message-ID: <8761on5v8n.fsf@building.gnus.org> User-Agent: Gnus/5.13001 (Ma Gnus v0.10) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-MailScanner-ID: 1WCkVe-0007nu-6Z X-Netfonds-MailScanner: Found to be clean X-Netfonds-MailScanner-From: larsi@gnus.org MailScanner-NULL-Check: 1392619106.65438@eDm4iXcHrQyyettFtSVxUQ X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 16603 Cc: 16603@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.0 (/) Dmitry Antipov writes: > On 02/08/2014 05:23 AM, Lars Ingebrigtsen wrote: > >> If you select Rotem's article three times (jumping out of the backtrace >> the first two times), Emacs will segfault the third time. It seems to >> be totally reproducible for me. > > I have the varying results, but no crash. Can you provide an exact > key/command sequence causing the crash? And, of course, do you start > from 'emacs -Q'? Yup. I do (require 'gnus-group) (setq debug-on-error t) (gnus-read-ephemeral-emacs-bug-group 16577) select Rotem's article, `q' out of the backtrace, `g' Rotem's article, and I either get a segfault then, or after repeating this a couple of times. This is on 64-bit Fedora 19, if that's likely to make a difference... -- (domestic pets only, the antidote for overdose, milk.) bloggy blog http://lars.ingebrigtsen.no/ From debbugs-submit-bounces@debbugs.gnu.org Mon Feb 10 04:31:12 2014 Received: (at 16603) by debbugs.gnu.org; 10 Feb 2014 09:31:12 +0000 Received: from localhost ([127.0.0.1]:39110 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WCnCp-0003S5-EZ for submit@debbugs.gnu.org; Mon, 10 Feb 2014 04:31:11 -0500 Received: from forward20.mail.yandex.net ([95.108.253.145]:47138) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WCnCl-0003Rc-GR for 16603@debbugs.gnu.org; Mon, 10 Feb 2014 04:31:09 -0500 Received: from smtp16.mail.yandex.net (smtp16.mail.yandex.net [95.108.252.16]) by forward20.mail.yandex.net (Yandex) with ESMTP id 9CD7910413BC; Mon, 10 Feb 2014 13:31:00 +0400 (MSK) Received: from smtp16.mail.yandex.net (localhost [127.0.0.1]) by smtp16.mail.yandex.net (Yandex) with ESMTP id 5B7B16A06F2; Mon, 10 Feb 2014 13:31:00 +0400 (MSK) Received: from unknown (unknown [37.139.80.10]) by smtp16.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id RaEcTmYuPM-UxqaZkiX; Mon, 10 Feb 2014 13:30:59 +0400 (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: d15eb4f0-9ac1-4db9-bb84-6445f07c06f4 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1392024659; bh=4NYFCla74TVx1zVgcM0RTJYfpAnaNah8ZGyMmc7Vcvs=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type; b=YNS95uyatvF7sFLccZ+tCumwEAH8LS+zJGXqKdNRvQGDsUR3wVndZPeTFqhSHaNaQ uQY2fDknqU9Q9bWQKdLkSns7MhQzYF4NIAyDUj8jfok0/azsyO61ZecDyxZE8wxxaT YT2fhkXR+otHEI4qgQx5IHIZzcrYMRWG6gAbPesw= Authentication-Results: smtp16.mail.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <52F89C53.1090709@yandex.ru> Date: Mon, 10 Feb 2014 13:30:59 +0400 From: Dmitry Antipov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Lars Ingebrigtsen Subject: Re: bug#16603: 24.3.50; Segfault when viewing a backtrace References: <878utw28pl.fsf@building.gnus.org> <52EB4AB4.8040004@yandex.ru> <83eh3o7es6.fsf@gnu.org> <87ha8klgeq.fsf@building.gnus.org> <838utw7dj2.fsf@gnu.org> <878utnk2mr.fsf@building.gnus.org> <8738jvk2do.fsf@building.gnus.org> <52F47397.5030509@yandex.ru> <87eh3ecs8f.fsf@building.gnus.org> <52F8711E.7070602@yandex.ru> <8761on5v8n.fsf@building.gnus.org> In-Reply-To: <8761on5v8n.fsf@building.gnus.org> Content-Type: multipart/mixed; boundary="------------060707040000000806020408" X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 16603 Cc: 16603@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.7 (/) This is a multi-part message in MIME format. --------------060707040000000806020408 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 02/10/2014 10:37 AM, Lars Ingebrigtsen wrote: > I do > > (require 'gnus-group) > (setq debug-on-error t) > (gnus-read-ephemeral-emacs-bug-group 16577) > > select Rotem's article, `q' out of the backtrace, `g' Rotem's article, > and I either get a segfault then, or after repeating this a couple of > times. OK, I've got it. Can you try this? Dmitry --------------060707040000000806020408 Content-Type: text/x-patch; name="bug16603.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="bug16603.patch" === modified file 'src/eval.c' --- src/eval.c 2014-02-03 09:37:43 +0000 +++ src/eval.c 2014-02-10 09:19:39 +0000 @@ -283,7 +283,9 @@ bool debug_while_redisplaying; ptrdiff_t count = SPECPDL_INDEX (); Lisp_Object val; - EMACS_INT old_max = max_specpdl_size, old_depth = max_lisp_eval_depth; + EMACS_INT old_depth = max_lisp_eval_depth; + /* Do not allow max_specpdl_size less than actual depth (Bug#16603). */ + EMACS_INT old_max = max (max_specpdl_size, count); if (lisp_eval_depth + 40 > max_lisp_eval_depth) max_lisp_eval_depth = lisp_eval_depth + 40; @@ -3721,7 +3723,9 @@ an error is signaled. You can safely use a value considerably larger than the default value, if that proves inconveniently small. However, if you increase it too far, -Emacs could run out of memory trying to make the stack bigger. */); +Emacs could run out of memory trying to make the stack bigger. +Note that this limit may be silently increased by the debugger +if `debug-on-error' or `debug-on-quit' is set. */); DEFVAR_INT ("max-lisp-eval-depth", max_lisp_eval_depth, doc: /* Limit on depth in `eval', `apply' and `funcall' before error. --------------060707040000000806020408-- From debbugs-submit-bounces@debbugs.gnu.org Mon Feb 10 04:34:18 2014 Received: (at 16603) by debbugs.gnu.org; 10 Feb 2014 09:34:19 +0000 Received: from localhost ([127.0.0.1]:39115 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WCnFq-0003Xb-HU for submit@debbugs.gnu.org; Mon, 10 Feb 2014 04:34:18 -0500 Received: from hermes.netfonds.no ([80.91.224.195]:54204) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WCnFn-0003XR-S0 for 16603@debbugs.gnu.org; Mon, 10 Feb 2014 04:34:16 -0500 Received: from [204.14.154.233] (helo=building.gnus.org) by hermes.netfonds.no with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1WCnFY-00044x-Rh; Mon, 10 Feb 2014 10:34:01 +0100 From: Lars Ingebrigtsen To: Dmitry Antipov Subject: Re: bug#16603: 24.3.50; Segfault when viewing a backtrace References: <878utw28pl.fsf@building.gnus.org> <52EB4AB4.8040004@yandex.ru> <83eh3o7es6.fsf@gnu.org> <87ha8klgeq.fsf@building.gnus.org> <838utw7dj2.fsf@gnu.org> <878utnk2mr.fsf@building.gnus.org> <8738jvk2do.fsf@building.gnus.org> <52F47397.5030509@yandex.ru> <87eh3ecs8f.fsf@building.gnus.org> <52F8711E.7070602@yandex.ru> <8761on5v8n.fsf@building.gnus.org> <52F89C53.1090709@yandex.ru> Date: Mon, 10 Feb 2014 01:32:47 -0800 In-Reply-To: <52F89C53.1090709@yandex.ru> (Dmitry Antipov's message of "Mon, 10 Feb 2014 13:30:59 +0400") Message-ID: <87sirrwbwg.fsf@building.gnus.org> User-Agent: Gnus/5.13001 (Ma Gnus v0.10) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-MailScanner-ID: 1WCnFY-00044x-Rh X-Netfonds-MailScanner: Found to be clean X-Netfonds-MailScanner-From: larsi@gnus.org MailScanner-NULL-Check: 1392629642.16478@6JoOxE57UOoPuIUtOvd3nw X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 16603 Cc: 16603@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.0 (/) Dmitry Antipov writes: > OK, I've got it. > > Can you try this? Thanks; that fixes the bug. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog http://lars.ingebrigtsen.no/ From debbugs-submit-bounces@debbugs.gnu.org Mon Feb 10 04:50:10 2014 Received: (at control) by debbugs.gnu.org; 10 Feb 2014 09:50:10 +0000 Received: from localhost ([127.0.0.1]:39122 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WCnVB-0003zj-Vu for submit@debbugs.gnu.org; Mon, 10 Feb 2014 04:50:10 -0500 Received: from hermes.netfonds.no ([80.91.224.195]:53864) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WCnV2-0003z7-JZ for control@debbugs.gnu.org; Mon, 10 Feb 2014 04:50:04 -0500 Received: from [204.14.154.233] (helo=building.gnus.org) by hermes.netfonds.no with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1WCnUn-0004Og-NS for control@debbugs.gnu.org; Mon, 10 Feb 2014 10:49:46 +0100 Date: Mon, 10 Feb 2014 01:48:31 -0800 Message-Id: <87ppmvwb68.fsf@building.gnus.org> To: control@debbugs.gnu.org From: Lars Ingebrigtsen Subject: control message for bug #16603 X-MailScanner-ID: 1WCnUn-0004Og-NS X-Netfonds-MailScanner: Found to be clean X-Netfonds-MailScanner-From: larsi@gnus.org MailScanner-NULL-Check: 1392630587.19767@tkaWBl65mQkvXqh4FcKDqQ X-Spam-Status: No X-Spam-Score: 0.0 (/) 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: 0.0 (/) close 16603 24.4 From unknown Mon Jun 23 22:04:42 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Mon, 10 Mar 2014 11:24:05 +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