* bug#16603: 24.3.50; Segfault when viewing a backtrace
@ 2014-01-31 2:20 Lars Ingebrigtsen
2014-01-31 7:03 ` Dmitry Antipov
0 siblings, 1 reply; 13+ messages in thread
From: Lars Ingebrigtsen @ 2014-01-31 2:20 UTC (permalink / raw)
To: 16603
(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=<optimized out>,
data=<optimized out>) 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=<optimized out>,
args=<optimized out>) 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=<optimized out>, arg1=<optimized out>)
at eval.c:2605
#798 0x00000000004e6a1d in command_loop_1 () at keyboard.c:1552
#799 0x0000000000546dae in internal_condition_case (
bfun=bfun@entry=0x4e6690 <command_loop_1>, handlers=<optimized out>,
---Type <return> to continue, or q <return> to quit---
hfun=hfun@entry=0x4dd760 <cmd_error>) 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 <command_loop_2>, 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=<optimized out>, 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:
<help-echo> M-x m <return> <return> <switch-frame>
M-x r e p o r <tab> <return>
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/
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#16603: 24.3.50; Segfault when viewing a backtrace
2014-01-31 2:20 bug#16603: 24.3.50; Segfault when viewing a backtrace Lars Ingebrigtsen
@ 2014-01-31 7:03 ` Dmitry Antipov
2014-01-31 8:10 ` Eli Zaretskii
0 siblings, 1 reply; 13+ messages in thread
From: Dmitry Antipov @ 2014-01-31 7:03 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 16603
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 <restore_stack_limits>, 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
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#16603: 24.3.50; Segfault when viewing a backtrace
2014-01-31 7:03 ` Dmitry Antipov
@ 2014-01-31 8:10 ` Eli Zaretskii
2014-01-31 8:11 ` Lars Ingebrigtsen
0 siblings, 1 reply; 13+ messages in thread
From: Eli Zaretskii @ 2014-01-31 8:10 UTC (permalink / raw)
To: Dmitry Antipov; +Cc: larsi, 16603
> Date: Fri, 31 Jan 2014 11:03:16 +0400
> From: Dmitry Antipov <dmantipov@yandex.ru>
> 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=<optimized out>,
> data=<optimized out>) 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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#16603: 24.3.50; Segfault when viewing a backtrace
2014-01-31 8:10 ` Eli Zaretskii
@ 2014-01-31 8:11 ` Lars Ingebrigtsen
2014-01-31 8:37 ` Eli Zaretskii
0 siblings, 1 reply; 13+ messages in thread
From: Lars Ingebrigtsen @ 2014-01-31 8:11 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Dmitry Antipov, 16603
Eli Zaretskii <eliz@gnu.org> 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/
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#16603: 24.3.50; Segfault when viewing a backtrace
2014-01-31 8:11 ` Lars Ingebrigtsen
@ 2014-01-31 8:37 ` Eli Zaretskii
2014-02-07 3:44 ` Lars Ingebrigtsen
0 siblings, 1 reply; 13+ messages in thread
From: Eli Zaretskii @ 2014-01-31 8:37 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: dmantipov, 16603
> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Dmitry Antipov <dmantipov@yandex.ru>, 16603@debbugs.gnu.org
> Date: Fri, 31 Jan 2014 00:11:25 -0800
>
> Eli Zaretskii <eliz@gnu.org> 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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#16603: 24.3.50; Segfault when viewing a backtrace
2014-01-31 8:37 ` Eli Zaretskii
@ 2014-02-07 3:44 ` Lars Ingebrigtsen
2014-02-07 3:50 ` Lars Ingebrigtsen
0 siblings, 1 reply; 13+ messages in thread
From: Lars Ingebrigtsen @ 2014-02-07 3:44 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: dmantipov, 16603
This has been fixed now.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog http://lars.ingebrigtsen.no/
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#16603: 24.3.50; Segfault when viewing a backtrace
2014-02-07 3:44 ` Lars Ingebrigtsen
@ 2014-02-07 3:50 ` Lars Ingebrigtsen
2014-02-07 5:48 ` Dmitry Antipov
0 siblings, 1 reply; 13+ messages in thread
From: Lars Ingebrigtsen @ 2014-02-07 3:50 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: dmantipov, 16603
Lars Ingebrigtsen <larsi@gnus.org> 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=<optimized out>,
args=<optimized out>) 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=<optimized out>,
data=<optimized out>) 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/
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#16603: 24.3.50; Segfault when viewing a backtrace
2014-02-07 3:50 ` Lars Ingebrigtsen
@ 2014-02-07 5:48 ` Dmitry Antipov
2014-02-08 1:23 ` Lars Ingebrigtsen
0 siblings, 1 reply; 13+ messages in thread
From: Dmitry Antipov @ 2014-02-07 5:48 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 16603
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#16603: 24.3.50; Segfault when viewing a backtrace
2014-02-07 5:48 ` Dmitry Antipov
@ 2014-02-08 1:23 ` Lars Ingebrigtsen
2014-02-10 6:26 ` Dmitry Antipov
0 siblings, 1 reply; 13+ messages in thread
From: Lars Ingebrigtsen @ 2014-02-08 1:23 UTC (permalink / raw)
To: Dmitry Antipov; +Cc: 16603
Dmitry Antipov <dmantipov@yandex.ru> 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/
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#16603: 24.3.50; Segfault when viewing a backtrace
2014-02-08 1:23 ` Lars Ingebrigtsen
@ 2014-02-10 6:26 ` Dmitry Antipov
2014-02-10 6:37 ` Lars Ingebrigtsen
0 siblings, 1 reply; 13+ messages in thread
From: Dmitry Antipov @ 2014-02-10 6:26 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 16603
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#16603: 24.3.50; Segfault when viewing a backtrace
2014-02-10 6:26 ` Dmitry Antipov
@ 2014-02-10 6:37 ` Lars Ingebrigtsen
2014-02-10 9:30 ` Dmitry Antipov
0 siblings, 1 reply; 13+ messages in thread
From: Lars Ingebrigtsen @ 2014-02-10 6:37 UTC (permalink / raw)
To: Dmitry Antipov; +Cc: 16603
Dmitry Antipov <dmantipov@yandex.ru> 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/
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#16603: 24.3.50; Segfault when viewing a backtrace
2014-02-10 6:37 ` Lars Ingebrigtsen
@ 2014-02-10 9:30 ` Dmitry Antipov
2014-02-10 9:32 ` Lars Ingebrigtsen
0 siblings, 1 reply; 13+ messages in thread
From: Dmitry Antipov @ 2014-02-10 9:30 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 16603
[-- Attachment #1: Type: text/plain, Size: 357 bytes --]
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
[-- Attachment #2: bug16603.patch --]
[-- Type: text/x-patch, Size: 1163 bytes --]
=== 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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#16603: 24.3.50; Segfault when viewing a backtrace
2014-02-10 9:30 ` Dmitry Antipov
@ 2014-02-10 9:32 ` Lars Ingebrigtsen
0 siblings, 0 replies; 13+ messages in thread
From: Lars Ingebrigtsen @ 2014-02-10 9:32 UTC (permalink / raw)
To: Dmitry Antipov; +Cc: 16603
Dmitry Antipov <dmantipov@yandex.ru> 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/
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2014-02-10 9:32 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-01-31 2:20 bug#16603: 24.3.50; Segfault when viewing a backtrace Lars Ingebrigtsen
2014-01-31 7:03 ` Dmitry Antipov
2014-01-31 8:10 ` Eli Zaretskii
2014-01-31 8:11 ` Lars Ingebrigtsen
2014-01-31 8:37 ` Eli Zaretskii
2014-02-07 3:44 ` Lars Ingebrigtsen
2014-02-07 3:50 ` Lars Ingebrigtsen
2014-02-07 5:48 ` Dmitry Antipov
2014-02-08 1:23 ` Lars Ingebrigtsen
2014-02-10 6:26 ` Dmitry Antipov
2014-02-10 6:37 ` Lars Ingebrigtsen
2014-02-10 9:30 ` Dmitry Antipov
2014-02-10 9:32 ` Lars Ingebrigtsen
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).