Package: emacs;
Reported by: Jorgen Schaefer <Jorgen.Schaefer <at> gmail.com>
Date: Sun, 11 Oct 2015 17:09:02 UTC
Severity: normal
Tags: fixed
Found in version 25.0.50
Done: Noam Postavsky <npostavs <at> gmail.com>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 21666 in the body.
You can then email your comments to 21666 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
View this report as an mbox folder, status mbox, maintainer mbox
bug-gnu-emacs <at> gnu.org:bug#21666; Package emacs.
(Sun, 11 Oct 2015 17:09:02 GMT) Full text and rfc822 format available.Jorgen Schaefer <Jorgen.Schaefer <at> gmail.com>:bug-gnu-emacs <at> gnu.org.
(Sun, 11 Oct 2015 17:09:03 GMT) Full text and rfc822 format available.Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
From: Jorgen Schaefer <Jorgen.Schaefer <at> gmail.com> To: bug-gnu-emacs <at> gnu.org Subject: 25.0.50; Random segfaults Date: Sun, 11 Oct 2015 08:50:18 +0200
Hello!
I have seen repeated crashes by Emacs from (almost) current git. I can
not reproduce them, but they do happen regularly during normal
interaction. Backtrace at the end of the report.
I'll try and keep gdb attached to my Emacs session for when this happens
again. Let me know if I can do something to provide more information.
In GNU Emacs 25.0.50.1 (x86_64-unknown-linux-gnu)
of 2015-10-09
Repository revision: e6013e8c8f3de0ca39c17a2da95346b4a320e6d0
System Description: Debian GNU/Linux 8.2 (jessie)
Configured using:
'configure --without-x CFLAGS=-ggdb'
Configured features:
JPEG SOUND DBUS NOTIFY ACL GNUTLS LIBXML2 ZLIB
Important settings:
value of $LC_ALL:
value of $LC_COLLATE: de_DE.UTF-8
value of $LC_CTYPE: de_DE.UTF-8
value of $LC_MESSAGES: POSIX
value of $LC_MONETARY: POSIX
value of $LC_NUMERIC: POSIX
value of $LC_TIME: POSIX
value of $LANG: POSIX
locale-coding-system: utf-8-unix
Recent messages:
Ispell process killed
Local Ispell dictionary set to american
Starting new Ispell process /usr/bin/aspell with default dictionary...
Ispell process killed
Local Ispell dictionary set to american
Starting new Ispell process /usr/bin/aspell with default dictionary...
Ispell process killed
Local Ispell dictionary set to german8
Starting new Ispell process /usr/bin/aspell with american dictionary...
Making completion list...
Memory information:
((conses 16 506667 25645)
(symbols 48 50697 0)
(miscs 40 491 575)
(strings 32 127558 15042)
(string-bytes 1 3874485)
(vectors 16 48820)
(vector-slots 8 816309 4597)
(floats 8 686 1437)
(intervals 56 3007 158)
(buffers 976 29)
(heap 1024 39125 2060))
Program received signal SIGSEGV, Segmentation fault.
CAR (c=139) at lisp.h:1201
1201: NILP (c) ? Qniln];
(gdb) bt
#0 CAR (c=139) at lisp.h:1201
#1 0x0000000000557e10 in Fcar (list=136) at data.c:530
#2 0x000000000057575d in eval_sub (form=28413219) at eval.c:2123r
#3 0x00000000005756bc in eval_sub (form=28413203) at eval.c:2111
#4 0x0000000000571b2d in Fcond (args=28407859) at eval.c:405
#5 0x0000000000575476 in eval_sub (form=28407443) at eval.c:2085
#6 0x0000000000571bd2 in Fprogn (body=28407491) at eval.c:427
#7 0x000000000057762a in funcall_lambda (fun=44604627, nargs=1,
arg_vector=0x7fffffff4cc8) at eval.c:2869
#8 0x0000000000576ecd in Ffuncall (nargs=2, args=0x7fffffff4cc0)
at eval.c:2711
#9 0x00000000005765a4 in call1 (fn=44604611, arg1=139) at eval.c:2509
#10 0x0000000000581269 in mapcar1 (leni=2544, vals=0x3619420, fn=44604611,
seq=41799763) at fns.c:2530
#11 0x0000000000581621 in Fmapcar (function=44604611, sequence=41799763)
at fns.c:2595
#12 0x000000000057578c in eval_sub (form=28411379) at eval.c:2126
#13 0x0000000000571bd2 in Fprogn (body=28411427) at eval.c:427
#14 0x0000000000572952 in FletX (args=28407635) at eval.c:879
#15 0x0000000000575476 in eval_sub (form=28407651) at eval.c:2085
#16 0x0000000000571bd2 in Fprogn (body=28407715) at eval.c:427
#17 0x000000000057762a in funcall_lambda (fun=28405795, nargs=3,
arg_vector=0x7fffffff5100) at eval.c:2869
#18 0x0000000000577148 in apply_lambda (fun=28405811, args=28417283, count=92)
at eval.c:2751
#19 0x0000000000575b20 in eval_sub (form=28417299) at eval.c:2198
#20 0x0000000000571cfa in Fsetq (args=28417331) at eval.c:494
#21 0x0000000000575476 in eval_sub (form=28417347) at eval.c:2085
#22 0x0000000000571bd2 in Fprogn (body=28415683) at eval.c:427
#23 0x0000000000575476 in eval_sub (form=28415699) at eval.c:2085
#24 0x0000000000571ad3 in Fif (args=28415731) at eval.c:384
#25 0x0000000000575476 in eval_sub (form=28415747) at eval.c:2085
#26 0x0000000000571bd2 in Fprogn (body=28415939) at eval.c:427
#27 0x0000000000572d3f in Flet (args=28413955) at eval.c:943
#28 0x0000000000575476 in eval_sub (form=28413971) at eval.c:2085
#29 0x0000000000571bd2 in Fprogn (body=28414035) at eval.c:427
#30 0x000000000057762a in funcall_lambda (fun=28414131, nargs=2,
arg_vector=0x7fffffff58f0) at eval.c:2869
#31 0x0000000000577148 in apply_lambda (fun=28414147, args=29716595, count=85)
at eval.c:2751
#32 0x0000000000575b20 in eval_sub (form=29716579) at eval.c:2198
#33 0x0000000000571bd2 in Fprogn (body=29716675) at eval.c:427
#34 0x0000000000572952 in FletX (args=29714883) at eval.c:879
#35 0x0000000000575476 in eval_sub (form=29714899) at eval.c:2085
#36 0x0000000000571bd2 in Fprogn (body=29714931) at eval.c:427
#37 0x0000000000575476 in eval_sub (form=29714915) at eval.c:2085
#38 0x0000000000571ad3 in Fif (args=29714963) at eval.c:384
#39 0x0000000000575476 in eval_sub (form=29714947) at eval.c:2085
#40 0x0000000000571bd2 in Fprogn (body=29715043) at eval.c:427
---Type <return> to continue, or q <return> to quit---
#41 0x000000000057762a in funcall_lambda (fun=29715139, nargs=7,
arg_vector=0x7fffffff5f40) at eval.c:2869
#42 0x0000000000577148 in apply_lambda (fun=29715155, args=28479411, count=79)
at eval.c:2751
#43 0x0000000000575b20 in eval_sub (form=28479571) at eval.c:2198
#44 0x0000000000571bd2 in Fprogn (body=28476067) at eval.c:427
#45 0x0000000000563d13 in Fsave_current_buffer (args=28475971)
at editfns.c:1027
#46 0x0000000000575476 in eval_sub (form=28475955) at eval.c:2085
#47 0x0000000000571bd2 in Fprogn (body=28475619) at eval.c:427
#48 0x0000000000571b70 in Fcond (args=28475603) at eval.c:409
#49 0x0000000000575476 in eval_sub (form=28475587) at eval.c:2085
#50 0x0000000000571bd2 in Fprogn (body=28475523) at eval.c:427
#51 0x000000000057762a in funcall_lambda (fun=28475187, nargs=5,
arg_vector=0x7fffffff6548) at eval.c:2869
#52 0x0000000000576ecd in Ffuncall (nargs=6, args=0x7fffffff6540)
at eval.c:2711
#53 0x0000000000576003 in Fapply (nargs=5, args=0x7fffffff6600) at eval.c:2278
#54 0x0000000000575656 in eval_sub (form=26515859) at eval.c:2103
#55 0x0000000000571bd2 in Fprogn (body=26515123) at eval.c:427
#56 0x0000000000571b70 in Fcond (args=26515027) at eval.c:409
#57 0x0000000000575476 in eval_sub (form=26516723) at eval.c:2085
#58 0x0000000000571bd2 in Fprogn (body=26509027) at eval.c:427
#59 0x0000000000572952 in FletX (args=26614371) at eval.c:879
#60 0x0000000000575476 in eval_sub (form=26614259) at eval.c:2085
#61 0x0000000000571bd2 in Fprogn (body=26614099) at eval.c:427
#62 0x0000000000563d13 in Fsave_current_buffer (args=26614147)
at editfns.c:1027
#63 0x0000000000575476 in eval_sub (form=26614211) at eval.c:2085
#64 0x0000000000571bd2 in Fprogn (body=26613299) at eval.c:427
#65 0x000000000057762a in funcall_lambda (fun=26612147, nargs=5,
arg_vector=0x7fffffff6d18) at eval.c:2869
#66 0x0000000000576ecd in Ffuncall (nargs=6, args=0x7fffffff6d10)
at eval.c:2711
#67 0x0000000000576003 in Fapply (nargs=2, args=0x7fffffff6dd0) at eval.c:2278
#68 0x0000000000575656 in eval_sub (form=29409219) at eval.c:2103
#69 0x00000000005737fa in internal_lisp_condition_case (var=4245808,
bodyform=29409219, handlers=29407395) at eval.c:1278
#70 0x000000000057337c in Fcondition_case (args=29409203) at eval.c:1203
#71 0x0000000000575476 in eval_sub (form=29409187) at eval.c:2085
#72 0x0000000000571bd2 in Fprogn (body=29407411) at eval.c:427
#73 0x0000000000571af1 in Fif (args=29409107) at eval.c:385
#74 0x0000000000575476 in eval_sub (form=29409091) at eval.c:2085
#75 0x0000000000571bd2 in Fprogn (body=29408019) at eval.c:427
#76 0x0000000000572d3f in Flet (args=29408035) at eval.c:943
#77 0x0000000000575476 in eval_sub (form=29408051) at eval.c:2085
#78 0x0000000000571bd2 in Fprogn (body=29408067) at eval.c:427
#79 0x0000000000572dff in Fwhile (args=29408083) at eval.c:962
#80 0x0000000000575476 in eval_sub (form=29408099) at eval.c:2085
---Type <return> to continue, or q <return> to quit---
#81 0x0000000000571bd2 in Fprogn (body=29408115) at eval.c:427
#82 0x0000000000572d3f in Flet (args=29408131) at eval.c:943
#83 0x0000000000575476 in eval_sub (form=29408147) at eval.c:2085
#84 0x0000000000571bd2 in Fprogn (body=29406627) at eval.c:427
#85 0x000000000057762a in funcall_lambda (fun=29406723, nargs=7,
arg_vector=0x7fffffff78f8) at eval.c:2869
#86 0x0000000000576ecd in Ffuncall (nargs=8, args=0x7fffffff78f0)
at eval.c:2711
#87 0x0000000000576003 in Fapply (nargs=6, args=0x7fffffff79c0) at eval.c:2278
#88 0x0000000000575656 in eval_sub (form=29379347) at eval.c:2103
#89 0x0000000000571bd2 in Fprogn (body=29378355) at eval.c:427
#90 0x0000000000575476 in eval_sub (form=29378387) at eval.c:2085
#91 0x0000000000571ad3 in Fif (args=29378419) at eval.c:384
#92 0x0000000000575476 in eval_sub (form=29378435) at eval.c:2085
#93 0x0000000000571bd2 in Fprogn (body=29376691) at eval.c:427
#94 0x0000000000572d3f in Flet (args=29376707) at eval.c:943
#95 0x0000000000575476 in eval_sub (form=29376723) at eval.c:2085
#96 0x0000000000571bd2 in Fprogn (body=29376739) at eval.c:427
#97 0x000000000057762a in funcall_lambda (fun=29376835, nargs=5,
arg_vector=0x7fffffff7ff0) at eval.c:2869
#98 0x0000000000577148 in apply_lambda (fun=29376851, args=26672659, count=49)
at eval.c:2751
#99 0x0000000000575b20 in eval_sub (form=26672707) at eval.c:2198
#100 0x0000000000571bd2 in Fprogn (body=26671907) at eval.c:427
#101 0x0000000000571af1 in Fif (args=26676579) at eval.c:385
#102 0x0000000000575476 in eval_sub (form=26678099) at eval.c:2085
#103 0x0000000000571bd2 in Fprogn (body=26670435) at eval.c:427
#104 0x000000000057762a in funcall_lambda (fun=26736179, nargs=5,
arg_vector=0x7fffffff8478) at eval.c:2869
#105 0x0000000000576ecd in Ffuncall (nargs=6, args=0x7fffffff8470)
at eval.c:2711
#106 0x0000000000576003 in Fapply (nargs=2, args=0x7fffffff8530) at eval.c:2278
#107 0x0000000000575656 in eval_sub (form=29409219) at eval.c:2103
#108 0x00000000005737fa in internal_lisp_condition_case (var=4245808,
bodyform=29409219, handlers=29407395) at eval.c:1278
#109 0x000000000057337c in Fcondition_case (args=29409203) at eval.c:1203
#110 0x0000000000575476 in eval_sub (form=29409187) at eval.c:2085
#111 0x0000000000571bd2 in Fprogn (body=29407411) at eval.c:427
#112 0x0000000000571af1 in Fif (args=29409107) at eval.c:385
#113 0x0000000000575476 in eval_sub (form=29409091) at eval.c:2085
#114 0x0000000000571bd2 in Fprogn (body=29408019) at eval.c:427
#115 0x0000000000572d3f in Flet (args=29408035) at eval.c:943
#116 0x0000000000575476 in eval_sub (form=29408051) at eval.c:2085
#117 0x0000000000571bd2 in Fprogn (body=29408067) at eval.c:427
#118 0x0000000000572dff in Fwhile (args=29408083) at eval.c:962
#119 0x0000000000575476 in eval_sub (form=29408099) at eval.c:2085
#120 0x0000000000571bd2 in Fprogn (body=29408115) at eval.c:427
#121 0x0000000000572d3f in Flet (args=29408131) at eval.c:943
#122 0x0000000000575476 in eval_sub (form=29408147) at eval.c:2085
---Type <return> to continue, or q <return> to quit---
#123 0x0000000000571bd2 in Fprogn (body=29406627) at eval.c:427
#124 0x000000000057762a in funcall_lambda (fun=29406723, nargs=7,
arg_vector=0x7fffffff9058) at eval.c:2869
#125 0x0000000000576ecd in Ffuncall (nargs=8, args=0x7fffffff9050)
at eval.c:2711
#126 0x0000000000576003 in Fapply (nargs=6, args=0x7fffffff9120) at eval.c:2278
#127 0x0000000000575656 in eval_sub (form=29379187) at eval.c:2103
#128 0x0000000000571bd2 in Fprogn (body=29378371) at eval.c:427
#129 0x0000000000575476 in eval_sub (form=29378387) at eval.c:2085
#130 0x0000000000571ad3 in Fif (args=29378419) at eval.c:384
#131 0x0000000000575476 in eval_sub (form=29378435) at eval.c:2085
#132 0x0000000000571bd2 in Fprogn (body=29376691) at eval.c:427
#133 0x0000000000572d3f in Flet (args=29376707) at eval.c:943
#134 0x0000000000575476 in eval_sub (form=29376723) at eval.c:2085
#135 0x0000000000571bd2 in Fprogn (body=29376739) at eval.c:427
#136 0x000000000057762a in funcall_lambda (fun=29376835, nargs=5,
arg_vector=0x7fffffff9808) at eval.c:2869
#137 0x0000000000576ecd in Ffuncall (nargs=6, args=0x7fffffff9800)
at eval.c:2711
#138 0x0000000000576003 in Fapply (nargs=5, args=0x7fffffff98c0) at eval.c:2278
#139 0x0000000000575656 in eval_sub (form=29386419) at eval.c:2103
#140 0x0000000000571bd2 in Fprogn (body=29386547) at eval.c:427
#141 0x0000000000572952 in FletX (args=29385507) at eval.c:879
#142 0x0000000000575476 in eval_sub (form=29385523) at eval.c:2085
#143 0x0000000000571bd2 in Fprogn (body=29385603) at eval.c:427
#144 0x000000000057762a in funcall_lambda (fun=29383683, nargs=2,
arg_vector=0x7fffffff9c50) at eval.c:2869
#145 0x0000000000577148 in apply_lambda (fun=29383699, args=29388323, count=24)
at eval.c:2751
#146 0x0000000000575b20 in eval_sub (form=29388307) at eval.c:2198
#147 0x0000000000571bd2 in Fprogn (body=29388355) at eval.c:427
#148 0x0000000000572d3f in Flet (args=29388067) at eval.c:943
#149 0x0000000000575476 in eval_sub (form=29387907) at eval.c:2085
#150 0x0000000000571bd2 in Fprogn (body=29388483) at eval.c:427
#151 0x0000000000572dff in Fwhile (args=29387891) at eval.c:962
#152 0x0000000000575476 in eval_sub (form=29387827) at eval.c:2085
#153 0x0000000000571bd2 in Fprogn (body=29388499) at eval.c:427
#154 0x0000000000572d3f in Flet (args=29387811) at eval.c:943
#155 0x0000000000575476 in eval_sub (form=29389667) at eval.c:2085
#156 0x0000000000571bd2 in Fprogn (body=29387027) at eval.c:427
#157 0x0000000000575476 in eval_sub (form=29387043) at eval.c:2085
#158 0x0000000000571ad3 in Fif (args=29387075) at eval.c:384
#159 0x0000000000575476 in eval_sub (form=29387091) at eval.c:2085
#160 0x0000000000571bd2 in Fprogn (body=29385731) at eval.c:427
#161 0x000000000057762a in funcall_lambda (fun=29385827, nargs=2,
arg_vector=0x7fffffffa6e8) at eval.c:2869
#162 0x0000000000576ecd in Ffuncall (nargs=3, args=0x7fffffffa6e0)
at eval.c:2711
#163 0x0000000000576003 in Fapply (nargs=2, args=0x7fffffffa7a0) at eval.c:2278
---Type <return> to continue, or q <return> to quit---
#164 0x0000000000576552 in apply1 (fn=15835456, arg=42197571) at eval.c:2494
#165 0x00000000005c64d2 in read_process_output_call (fun_and_args=42197267)
at process.c:5241
#166 0x0000000000573ac2 in internal_condition_case_1 (
bfun=0x5c64a4 <read_process_output_call>, arg=42197267, handlers=16416,
hfun=0x5c64d4 <read_process_output_error_handler>) at eval.c:1333
#167 0x00000000005c6c63 in read_and_dispose_of_process_output (p=0x27781c0,
chars=0x7fffffffa8b0 ":gattsu!~gattsu <at> jdhankle.com PRIVMSG #emacs :lol\r\np\002", nbytes=50, coding=0x23e4fc0) at process.c:5449
#168 0x00000000005c68b1 in read_process_output (proc=41386437, channel=9)
at process.c:5360
#169 0x00000000005c5e87 in wait_reading_process_output (time_limit=2,
nsecs=999975529, read_kbd=-1, do_display=true, wait_for_cell=0,
wait_proc=0x0, just_wait_proc=0) at process.c:5067
#170 0x00000000004e2e56 in kbd_buffer_get_event (kbp=0x7fffffffbe48,
used_mouse_menu=0x0, end_time=0x7fffffffc420) at keyboard.c:3786
#171 0x00000000004df878 in read_event_from_main_queue (
end_time=0x7fffffffc420, local_getcjmp=0x7fffffffc1f0, used_mouse_menu=0x0)
at keyboard.c:2129
#172 0x00000000004dfab9 in read_decoded_event_from_main_queue (
end_time=0x7fffffffc420, local_getcjmp=0x7fffffffc1f0, prev_event=0,
used_mouse_menu=0x0) at keyboard.c:2192
#173 0x00000000004e0f71 in read_char (commandflag=0, map=0, prev_event=0,
used_mouse_menu=0x0, end_time=0x7fffffffc420) at keyboard.c:2787
#174 0x000000000059daf9 in read_filtered_event (no_switch_frame=false,
ascii_required=false, error_nonascii=false, input_method=true, seconds=14)
at lread.c:609
#175 0x000000000059dddd in Fread_event (prompt=0, inherit_input_method=39456,
seconds=14) at lread.c:721
#176 0x0000000000576be9 in Ffuncall (nargs=4, args=0x7fffffffc580)
at eval.c:2657
#177 0x00000000005b8037 in exec_byte_code (bytestr=8831356, vector=8831389,
maxdepth=30, args_template=3078, nargs=1, args=0x7fffffffcab0)
at bytecode.c:880
#178 0x000000000057737f in funcall_lambda (fun=8831309, nargs=1,
arg_vector=0x7fffffffcaa8) at eval.c:2810
#179 0x0000000000576dfc in Ffuncall (nargs=2, args=0x7fffffffcaa0)
at eval.c:2699
#180 0x00000000005b8037 in exec_byte_code (bytestr=27571796, vector=26240117,
maxdepth=14, args_template=2, nargs=0, args=0x7fffffffcfb8)
at bytecode.c:880
#181 0x000000000057737f in funcall_lambda (fun=26240269, nargs=0,
arg_vector=0x7fffffffcfb8) at eval.c:2810
#182 0x0000000000576dfc in Ffuncall (nargs=1, args=0x7fffffffcfb0)
at eval.c:2699
#183 0x00000000005b8037 in exec_byte_code (bytestr=27567188, vector=26240845,
maxdepth=30, args_template=2, nargs=0, args=0x7fffffffd4e0)
at bytecode.c:880
#184 0x000000000057737f in funcall_lambda (fun=26274869, nargs=0,
---Type <return> to continue, or q <return> to quit---
arg_vector=0x7fffffffd4e0) at eval.c:2810
#185 0x0000000000576dfc in Ffuncall (nargs=1, args=0x7fffffffd4d8)
at eval.c:2699
#186 0x0000000000576571 in call0 (fn=15122304) at eval.c:2501
#187 0x00000000004df233 in safe_run_hooks_1 (nargs=2, args=0x7fffffffd580)
at keyboard.c:1770
#188 0x0000000000573db6 in internal_condition_case_n (
bfun=0x4df210 <safe_run_hooks_1>, nargs=2, args=0x7fffffffd580,
handlers=39456, hfun=0x4df235 <safe_run_hooks_error>) at eval.c:1391
#189 0x00000000004df4b1 in safe_run_hook_funcall (nargs=2, args=0x7fffffffd610)
at keyboard.c:1818
#190 0x0000000000576461 in run_hook_with_args (nargs=2, args=0x7fffffffd610,
funcall=0x4df45e <safe_run_hook_funcall>) at eval.c:2466
#191 0x00000000004df51b in safe_run_hooks (hook=33264) at keyboard.c:1834
#192 0x00000000004de0f0 in command_loop_1 () at keyboard.c:1474
#193 0x0000000000573957 in internal_condition_case (
bfun=0x4dd931 <command_loop_1>, handlers=16416, hfun=0x4dd13d <cmd_error>)
at eval.c:1309
#194 0x00000000004dd649 in command_loop_2 (ignore=0) at keyboard.c:1088
#195 0x0000000000573119 in internal_catch (tag=40656,
func=0x4dd620 <command_loop_2>, arg=0) at eval.c:1073
#196 0x00000000004dd5e9 in command_loop () at keyboard.c:1067
#197 0x00000000004dcd0c in recursive_edit_1 () at keyboard.c:673
#198 0x00000000004dce9f in Frecursive_edit () at keyboard.c:744
#199 0x00000000004dada7 in main (argc=1, argv=0x7fffffffdac8) at emacs.c:1643
bug-gnu-emacs <at> gnu.org:bug#21666; Package emacs.
(Mon, 12 Oct 2015 00:31:02 GMT) Full text and rfc822 format available.Message #8 received at 21666 <at> debbugs.gnu.org (full text, mbox):
From: Paul Eggert <eggert <at> cs.ucla.edu> To: Jorgen Schaefer <Jorgen.Schaefer <at> gmail.com> Cc: 21666 <at> debbugs.gnu.org Subject: Re: 25.0.50; Random segfaults Date: Sun, 11 Oct 2015 17:30:13 -0700
What happens if you build Emacs with checking turned on? E.g.,: cd src make clean make CFLAGS='-ggdb -DENABLE_CHECKING' or, if you want to build from scratch: ./configure --enable-checking --without-x CFLAGS='-ggdb' make clean make
bug-gnu-emacs <at> gnu.org:bug#21666; Package emacs.
(Tue, 13 Oct 2015 11:51:02 GMT) Full text and rfc822 format available.Message #11 received at 21666 <at> debbugs.gnu.org (full text, mbox):
From: Jorgen Schaefer <Jorgen.Schaefer <at> gmail.com> To: 21666 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu> Subject: 25.0.50; Random segfaults Date: Tue, 13 Oct 2015 13:50:27 +0200
> What happens if you build Emacs with checking turned on?
I was about to say that that did fix things, but it just took a bit
longer to segfault. bt full output follows:
#0 0x00000000004f0a84 in XFLOAT_DATA (f=7) at lisp.h:2396
No locals.
#1 0x00000000005a675c in Fabs (arg=7) at floatfns.c:283
No locals.
#2 0x00000000005a1eca in eval_sub (form=29494067) at eval.c:2123
numargs = 6
args_left = 0
i = 1
maxargs = 1
argvals = {7, 5904481, 140737488312256, 3494512, -120026, 29492291, 0,
13281456}
fun = 12706525
val = 140737488312208
original_fun = 302192
original_args = 29494083
funcar = 16368
count = 99
#3 0x00000000005a1d4d in eval_sub (form=29494051) at eval.c:2097
vals = 0x7fffffff57a0
argnum = 1
sa_avail = 16368
sa_count = 99
sa_must_free = false
numargs = 10
args_left = 29494099
i = -43104
maxargs = 0
argvals = {7, 25237744, 140737488312544, 5907209, 5180867, 13080496,
140737488312352, 5766358}
fun = 12697797
val = 140737488312496
original_fun = 263920
original_args = 29494099
funcar = 42317360
count = 98
#4 0x000000000059c9a9 in Fand (args=29494131) at eval.c:362
val = 39456
#5 0x00000000005a1be3 in eval_sub (form=29493987) at eval.c:2085
numargs = 10
args_left = 29494035
i = 2
maxargs = 0
argvals = {0, 25237712, 13080496, 42317360, 140737488312640, 0,
140737488312656, 13266816}
fun = 12703789
val = 12703837
original_fun = 299776
original_args = 29494035
funcar = 140737488312800
count = 97
#6 0x000000000059ca60 in Fif (args=29494147) at eval.c:381
cond = 12703837
#7 0x00000000005a1be3 in eval_sub (form=29493971) at eval.c:2085
numargs = 14
args_left = 29494147
i = 3
maxargs = 0
argvals = {5181002, 42962914960, 12695877, 25783087632, 0, 41856,
13080496, 140737488312960}
fun = 12703837
val = 140737488313104
original_fun = 23328
original_args = 29494147
funcar = 140737488313040
count = 96
#8 0x000000000059cd42 in Fprogn (body=29489363) at eval.c:427
val = 0
#9 0x00000000005a420c in funcall_lambda (fun=44939827, nargs=1,
arg_vector=0x7fffffff5c88) at eval.c:2869
val = 11952
syms_left = 0
next = 3494512
lexenv = 43990947
count = 95
i = 1
optional = false
rest = false
#10 0x00000000005a38d3 in Ffuncall (nargs=2, args=0x7fffffff5c80)
at eval.c:2711
fun = 44939811
original_fun = 44939811
funcar = 11952
numargs = 1
lisp_numargs = 12705469
val = 140737488313456
internal_args = 0xc1debd <Sfuncall+5>
count = 94
#11 0x00000000005a1dc3 in eval_sub (form=29492595) at eval.c:2103
vals = 0x7fffffff5c80
argnum = 2
sa_avail = 16368
sa_count = 94
sa_must_free = false
numargs = 10
args_left = 0
i = -41848
maxargs = 0
argvals = {140737488313568, 25237584, 140737488313792, 5907209,
140737488313808, 29492547, 7, 13080496}
fun = 12705469
val = 140737488313744
original_fun = 20736
original_args = 29492611
funcar = 140737488313792
count = 93
#12 0x000000000059cd42 in Fprogn (body=29492643) at eval.c:427
val = 0
#13 0x000000000059cc81 in Fcond (args=29487411) at eval.c:409
clause = 29492579
val = 39456
#14 0x00000000005a1be3 in eval_sub (form=29487027) at eval.c:2085
numargs = 30
args_left = 29487411
i = 7
maxargs = 0
argvals = {140737488313920, 13266816, 44351859, 25783087632, 0, 41856,
13080496, 140737488313968}
fun = 12703885
val = 140737488314112
original_fun = 299824
original_args = 29487411
funcar = 140737488314048
count = 92
#15 0x000000000059cd42 in Fprogn (body=29485059) at eval.c:427
val = 0
#16 0x00000000005a420c in funcall_lambda (fun=44939763, nargs=1,
arg_vector=0x7fffffff6088) at eval.c:2869
val = 11952
syms_left = 0
next = 3671008
lexenv = 43990979
count = 91
i = 1
optional = false
rest = false
#17 0x00000000005a38d3 in Ffuncall (nargs=2, args=0x7fffffff6080)
at eval.c:2711
fun = 44939747
original_fun = 44939747
funcar = 11952
numargs = 1
lisp_numargs = 0
val = 0
internal_args = 0x169
count = 90
#18 0x00000000005a2f13 in call1 (fn=44939747, arg1=7) at eval.c:2509
No locals.
#19 0x00000000005b0025 in mapcar1 (leni=2502, vals=0x3689380, fn=44939747,
seq=40715987) at fns.c:2530
tail = 41927235
dummy = 0
i = 2458
#20 0x00000000005b040f in Fmapcar (function=44939747, sequence=40715987)
at fns.c:2595
len = 2502
leni = 2502
args = 0x3689380
ret = 140737488314688
sa_avail = 16384
sa_count = 89
sa_must_free = true
#21 0x00000000005a1ef9 in eval_sub (form=29490963) at eval.c:2126
numargs = 10
args_left = 0
i = 2
maxargs = 2
argvals = {44939747, 40715987, 140737488315024, 5907209, 0, 29485091,
13080496, 140737488314832}
fun = 12709501
val = 140737488314976
original_fun = 268560
original_args = 29490979
funcar = 140737488314912
count = 88
#22 0x000000000059cd42 in Fprogn (body=29491011) at eval.c:427
val = 0
#23 0x000000000059e472 in FletX (args=29485203) at eval.c:879
varlist = 0
var = 8221472
val = 44939747
elt = 29485107
lexenv = 44939843
count = 87
#24 0x00000000005a1be3 in eval_sub (form=29485219) at eval.c:2085
numargs = 10
args_left = 29485203
i = 2
maxargs = 0
argvals = {12698032, 140737488315224, 5181002, 25783087632, 0, 41856,
13080496, 140737488315248}
fun = 12704509
val = 140737488315392
original_fun = 26784
original_args = 29485203
funcar = 140737488315328
count = 86
#25 0x000000000059cd42 in Fprogn (body=29485283) at eval.c:427
val = 27583604
#26 0x00000000005a420c in funcall_lambda (fun=29485379, nargs=3,
arg_vector=0x7fffffff64c0) at eval.c:2869
val = 0
syms_left = 0
next = 254080
lexenv = 44939843
count = 85
i = 3
optional = false
rest = false
#27 0x00000000005a3b4e in apply_lambda (fun=29485395, args=29496867, count=84)
at eval.c:2751
args_left = 0
i = 3
numargs = 3
arg_vector = 0x7fffffff64c0
tem = 142
sa_avail = 16360
sa_count = 85
sa_must_free = false
#28 0x00000000005a22bb in eval_sub (form=29496883) at eval.c:2198
fun = 29485395
val = 12704072
original_fun = 15600400
original_args = 29496867
funcar = 11952
count = 84
#29 0x000000000059cfb4 in Fsetq (args=29496915) at eval.c:494
args_left = 29496915
val = 29496915
sym = 12704077
lex_binding = 5181157
#30 0x00000000005a1be3 in eval_sub (form=29496931) at eval.c:2085
numargs = 10
args_left = 29496915
i = 2
maxargs = 0
argvals = {140737488316144, 40715987, 140737488316384, 5904587,
140737488316288, 305648, 42317360, 13061392}
fun = 12704077
val = 140737488316336
original_fun = 299968
original_args = 29496915
funcar = 5180867
count = 83
#31 0x000000000059cd42 in Fprogn (body=29493251) at eval.c:427
val = 0
#32 0x00000000005a1be3 in eval_sub (form=29493267) at eval.c:2085
numargs = 6
args_left = 29493251
i = 1
maxargs = 0
argvals = {40715987, 5918068, 0, 82, 140737488316528, 40715987,
42317365, 305648}
fun = 12703933
val = 140737488316640
original_fun = 33936
original_args = 29493251
funcar = 140737488316688
count = 82
#33 0x000000000059cabe in Fif (args=29493299) at eval.c:384
cond = 39456
#34 0x00000000005a1be3 in eval_sub (form=29493315) at eval.c:2085
numargs = 10
args_left = 29493299
i = 2
maxargs = 0
argvals = {140737488316768, 0, 140737488316992, 25783087632, 0, 41856,
13080496, 140737488316800}
fun = 12703837
val = 0
original_fun = 23328
original_args = 29493299
funcar = 140737488316880
count = 81
#35 0x000000000059cd42 in Fprogn (body=29493507) at eval.c:427
val = 0
#36 0x000000000059e9d6 in Flet (args=29493539) at eval.c:943
temps = 0x7fffffff6a50
tem = 0
lexenv = 44351859
elt = 30240019
varlist = 0
count = 80
argnum = 2
sa_avail = 16368
sa_count = 80
sa_must_free = false
#37 0x00000000005a1be3 in eval_sub (form=29493555) at eval.c:2085
numargs = 18
args_left = 29493539
i = 4
maxargs = 0
argvals = {8021312, 13242000, 44984931, 25783087632, 0, 41856,
13080496, 140737488317280}
fun = 12704557
val = 140737488317424
original_fun = 26736
original_args = 29493539
funcar = 140737488317360
count = 79
#38 0x000000000059cd42 in Fprogn (body=29493619) at eval.c:427
val = 27598036
#39 0x00000000005a420c in funcall_lambda (fun=29493715, nargs=2,
arg_vector=0x7fffffff6cb0) at eval.c:2869
val = 0
syms_left = 0
next = 15839792
lexenv = 44351923
count = 78
i = 2
optional = true
rest = false
#40 0x00000000005a3b4e in apply_lambda (fun=29493731, args=30643603, count=77)
at eval.c:2751
args_left = 0
i = 2
numargs = 2
arg_vector = 0x7fffffff6cb0
tem = 0
sa_avail = 16368
sa_count = 78
sa_must_free = false
#41 0x00000000005a22bb in eval_sub (form=30643587) at eval.c:2198
fun = 29493731
val = 0
original_fun = 15839744
original_args = 30643603
funcar = 11952
count = 77
#42 0x000000000059cd42 in Fprogn (body=30643683) at eval.c:427
val = 0
#43 0x000000000059e472 in FletX (args=30641891) at eval.c:879
varlist = 0
var = 39888
val = 57037812
elt = 30644851
lexenv = 45366915
count = 76
#44 0x00000000005a1be3 in eval_sub (form=30641907) at eval.c:2085
numargs = 18
args_left = 30641891
i = 4
maxargs = 0
argvals = {2, 25237008, 140737488318480, 5907209, 2, 30645795, 0,
13242000}
fun = 12704509
val = 140737488318432
original_fun = 26784
original_args = 30641891
funcar = 24816
count = 75
#45 0x000000000059cd42 in Fprogn (body=30641939) at eval.c:427
val = 0
#46 0x00000000005a1be3 in eval_sub (form=30641923) at eval.c:2085
numargs = 6
args_left = 30641939
i = 1
maxargs = 0
argvals = {0, 43427043, 140737488318624, 5780801, 43427043, 13242000,
140737488318592, 0}
fun = 12703933
val = 140737488318736
original_fun = 33936
original_args = 30641939
funcar = 42317360
count = 74
#47 0x000000000059cabe in Fif (args=30641971) at eval.c:384
cond = 39456
#48 0x00000000005a1be3 in eval_sub (form=30641955) at eval.c:2085
numargs = 10
args_left = 30641971
i = 2
maxargs = 0
argvals = {0, 13242000, 13080496, 25783087632, 0, 41856, 13080496,
140737488318896}
fun = 12703837
val = 140737488319040
original_fun = 23328
original_args = 30641971
funcar = 140737488318976
count = 73
#49 0x000000000059cd42 in Fprogn (body=30642051) at eval.c:427
val = 28003380
#50 0x00000000005a420c in funcall_lambda (fun=30640131, nargs=7,
arg_vector=0x7fffffff7300) at eval.c:2869
val = 29556963
syms_left = 0
next = 8021312
lexenv = 45366915
count = 72
i = 7
optional = false
rest = true
#51 0x00000000005a3b4e in apply_lambda (fun=30640147, args=29557075, count=71)
at eval.c:2751
args_left = 0
i = 7
numargs = 7
arg_vector = 0x7fffffff7300
tem = 41234100
sa_avail = 16328
sa_count = 72
sa_must_free = false
#52 0x00000000005a22bb in eval_sub (form=29557187) at eval.c:2198
fun = 30640147
val = 0
original_fun = 15682864
original_args = 29557075
funcar = 11952
count = 71
#53 0x000000000059cd42 in Fprogn (body=29553699) at eval.c:427
val = 0
#54 0x000000000058df4c in Fsave_current_buffer (args=29553603)
at editfns.c:1027
count = 70
#55 0x00000000005a1be3 in eval_sub (form=29553587) at eval.c:2085
numargs = 14
args_left = 29553603
i = 3
maxargs = 0
argvals = {1, 39456, 140737488320080, 5904587, 9212280, 39456, 2, 70}
fun = 12700301
val = 140737488320032
original_fun = 328752
original_args = 29553603
funcar = 3
count = 69
#56 0x000000000059cd42 in Fprogn (body=29552739) at eval.c:427
val = 0
#57 0x000000000059cc81 in Fcond (args=29552691) at eval.c:409
clause = 29552755
val = 39456
#58 0x00000000005a1be3 in eval_sub (form=29552675) at eval.c:2085
numargs = 10
args_left = 29553891
i = 2
maxargs = 0
argvals = {139642271659744, 0, 46084787, 25783087632, 0, 41856,
13080496, 140737488320256}
fun = 12703885
val = 140737488320400
original_fun = 299824
original_args = 29553891
funcar = 140737488320336
count = 68
#59 0x000000000059cd42 in Fprogn (body=29552451) at eval.c:427
val = 28684644
#60 0x00000000005a420c in funcall_lambda (fun=29552355, nargs=5,
arg_vector=0x7fffffff7908) at eval.c:2869
val = 11952
syms_left = 0
next = 39888
lexenv = 46084547
count = 67
i = 5
optional = false
rest = false
#61 0x00000000005a38d3 in Ffuncall (nargs=6, args=0x7fffffff7900)
at eval.c:2711
fun = 29552339
original_fun = 14991984
funcar = 11952
numargs = 5
lisp_numargs = 41234292
val = 140737488320752
internal_args = 0x0
count = 66
#62 0x00000000005a2857 in Fapply (nargs=5, args=0x7fffffff79c0) at eval.c:2278
i = 6
numargs = 5
funcall_nargs = 6
funcall_args = 0x7fffffff7900
spread_arg = 0
fun = 29552339
retval = 5181002
sa_avail = 16336
sa_count = 66
sa_must_free = false
#63 0x00000000005a1dc3 in eval_sub (form=27450755) at eval.c:2103
vals = 0x7fffffff79c0
argnum = 5
sa_avail = 16344
sa_count = 66
sa_must_free = false
numargs = 22
args_left = 0
i = -34336
maxargs = 0
argvals = {140737488321088, 25236688, 140737488321312, 5907209,
140737488321120, 27451571, 14991984, 0}
fun = 12705133
val = 140737488321264
original_fun = 7440
original_args = 27450547
funcar = 3617888
count = 65
#64 0x000000000059cd42 in Fprogn (body=27450019) at eval.c:427
val = 0
#65 0x000000000059cc81 in Fcond (args=27449859) at eval.c:409
clause = 27450851
val = 39456
#66 0x00000000005a1be3 in eval_sub (form=27451619) at eval.c:2085
numargs = 14
args_left = 27449859
i = 3
maxargs = 0
argvals = {0, 25236656, 140737488321680, 5907209, 0, 27489955,
13080496, 140737488321488}
fun = 12703885
val = 140737488321632
original_fun = 299824
original_args = 27449859
funcar = 140737488321568
count = 64
#67 0x000000000059cd42 in Fprogn (body=27443843) at eval.c:427
val = 0
#68 0x000000000059e472 in FletX (args=27548227) at eval.c:879
varlist = 0
var = 15335232
val = 42033092
elt = 27487971
lexenv = 46085011
count = 63
#69 0x00000000005a1be3 in eval_sub (form=27548163) at eval.c:2085
numargs = 10
args_left = 27548227
i = 2
maxargs = 0
argvals = {41616405, 17179869590, 140737488326256, 5717659, 19141664,
13242000, 5181281, 0}
fun = 12704509
val = 41616405
original_fun = 26784
original_args = 27548227
funcar = 0
count = 62
#70 0x000000000059cd42 in Fprogn (body=27547955) at eval.c:427
val = 41616405
#71 0x000000000058df4c in Fsave_current_buffer (args=27548003)
at editfns.c:1027
count = 61
#72 0x00000000005a1be3 in eval_sub (form=27548115) at eval.c:2085
numargs = 10
args_left = 27548003
i = 2
maxargs = 0
argvals = {0, 0, 140737488322224, 25783087632, 0, 41856, 13080496,
140737488322256}
fun = 12700301
val = 140737488322400
original_fun = 328752
original_args = 27548003
funcar = 140737488322336
count = 60
#73 0x000000000059cd42 in Fprogn (body=27547027) at eval.c:427
val = 28452724
#74 0x00000000005a420c in funcall_lambda (fun=27546115, nargs=5,
arg_vector=0x7fffffff80d8) at eval.c:2869
val = 11952
syms_left = 0
next = 7488
lexenv = 46085011
count = 59
i = 5
optional = true
rest = true
#75 0x00000000005a38d3 in Ffuncall (nargs=6, args=0x7fffffff80d0)
at eval.c:2711
fun = 27546003
original_fun = 15440144
funcar = 11952
numargs = 5
lisp_numargs = 140737488322848
val = 140737488322752
internal_args = 0x0
count = 58
#76 0x00000000005a2857 in Fapply (nargs=2, args=0x7fffffff8190) at eval.c:2278
i = 6
numargs = 5
funcall_nargs = 6
funcall_args = 0x7fffffff80d0
spread_arg = 0
fun = 27546003
retval = 5181002
sa_avail = 16336
sa_count = 58
sa_must_free = false
#77 0x00000000005a1dc3 in eval_sub (form=30335235) at eval.c:2103
vals = 0x7fffffff8190
argnum = 2
sa_avail = 16368
sa_count = 58
sa_must_free = false
numargs = 10
args_left = 0
i = -32360
maxargs = 0
argvals = {0, 15627764, 140737488323056, 13080496, 140737488323072,
5766358, 140737488323312, 25783087632}
fun = 12705133
val = 140737488323232
original_fun = 7440
original_args = 30335251
funcar = 140737488323168
count = 57
#78 0x000000000059f9ee in internal_lisp_condition_case (var=4171408,
bodyform=30335235, handlers=30335427) at eval.c:1278
val = 0
c = 0x148a870
oldhandlerlist = 0x14a3370
clausenb = 1
#79 0x000000000059f3ee in Fcondition_case (args=30335219) at eval.c:1203
var = 4171408
bodyform = 30335235
handlers = 30335427
#80 0x00000000005a1be3 in eval_sub (form=30335203) at eval.c:2085
numargs = 14
args_left = 30335219
i = 3
maxargs = 0
argvals = {40424192, 0, 140737488323808, 5904587, 44898067, 299216,
140737488323616, 45589667}
fun = 12704845
val = 140737488323760
original_fun = 300624
original_args = 30335219
funcar = 140737488323696
count = 56
#81 0x000000000059cd42 in Fprogn (body=30335443) at eval.c:427
val = 0
#82 0x000000000059cb71 in Fif (args=30335123) at eval.c:385
cond = 0
#83 0x00000000005a1be3 in eval_sub (form=30335107) at eval.c:2085
numargs = 14
args_left = 30335123
i = 3
maxargs = 0
argvals = {140737488323904, 25236336, 140737488324160, 25783087632, 0,
41856, 13080496, 140737488323968}
fun = 12703837
val = 140737488324112
original_fun = 23328
original_args = 30335123
funcar = 140737488324048
count = 55
#84 0x000000000059cd42 in Fprogn (body=30334035) at eval.c:427
val = 0
#85 0x000000000059e9d6 in Flet (args=30334051) at eval.c:943
temps = 0x7fffffff8650
tem = 15440144
lexenv = 45589603
elt = 30335923
varlist = 0
count = 54
argnum = 1
sa_avail = 16376
sa_count = 54
sa_must_free = false
#86 0x00000000005a1be3 in eval_sub (form=30334067) at eval.c:2085
numargs = 14
args_left = 30334051
i = 3
maxargs = 0
argvals = {140737488324432, 45589667, 140737488324640, 5904481,
7277957735319046016, 3425200, 140737488324448, 5174391}
fun = 12704557
val = 140737488324592
original_fun = 26736
original_args = 30334051
funcar = 4294936720
count = 53
#87 0x000000000059cd42 in Fprogn (body=30334083) at eval.c:427
val = 0
#88 0x000000000059eaf2 in Fwhile (args=30334099) at eval.c:962
test = 3425200
body = 30334083
#89 0x00000000005a1be3 in eval_sub (form=30334115) at eval.c:2085
numargs = 10
args_left = 30334099
i = 2
maxargs = 0
argvals = {2, 25236240, 140737488325008, 25783087632, 0, 41856,
13080496, 140737488324816}
fun = 12704605
val = 140737488324960
original_fun = 300304
original_args = 30334099
funcar = 140737488324896
count = 52
#90 0x000000000059cd42 in Fprogn (body=30334131) at eval.c:427
val = 0
#91 0x000000000059e9d6 in Flet (args=30334147) at eval.c:943
temps = 0x7fffffff89a0
tem = 29412307
lexenv = 45589667
elt = 30335843
varlist = 0
count = 51
argnum = 1
sa_avail = 16376
sa_count = 51
sa_must_free = false
#92 0x00000000005a1be3 in eval_sub (form=30334163) at eval.c:2085
numargs = 10
args_left = 30334147
i = 2
maxargs = 0
argvals = {140737488325248, 13266816, 70, 25783087632, 0, 41856,
13080496, 140737488325296}
fun = 12704557
val = 140737488325440
original_fun = 26736
original_args = 30334147
funcar = 140737488325376
count = 50
#93 0x000000000059cd42 in Fprogn (body=30334659) at eval.c:427
val = 26443828
#94 0x00000000005a420c in funcall_lambda (fun=30334755, nargs=7,
arg_vector=0x7fffffff8cb8) at eval.c:2869
val = 11952
syms_left = 0
next = 7488
lexenv = 45589699
count = 49
i = 7
optional = false
rest = true
#95 0x00000000005a38d3 in Ffuncall (nargs=8, args=0x7fffffff8cb0)
at eval.c:2711
fun = 30334771
original_fun = 15173088
funcar = 11952
numargs = 7
lisp_numargs = 46157907
val = 140737488325792
internal_args = 0x0
count = 48
#96 0x00000000005a2857 in Fapply (nargs=6, args=0x7fffffff8d80) at eval.c:2278
i = 8
numargs = 7
funcall_nargs = 8
funcall_args = 0x7fffffff8cb0
spread_arg = 0
fun = 30334771
retval = 5181002
sa_avail = 16320
sa_count = 48
sa_must_free = false
#97 0x00000000005a1dc3 in eval_sub (form=30305363) at eval.c:2103
vals = 0x7fffffff8d80
argnum = 6
sa_avail = 16336
sa_count = 48
sa_must_free = false
numargs = 26
args_left = 0
i = -29272
maxargs = 0
argvals = {46157907, 24816, 2, 25236080, 13080496, 42317360,
140737488326176, 0}
fun = 12705133
val = 0
original_fun = 7440
original_args = 30305411
funcar = 5180867
count = 47
#98 0x000000000059cd42 in Fprogn (body=30304371) at eval.c:427
val = 0
#99 0x00000000005a1be3 in eval_sub (form=30304403) at eval.c:2085
numargs = 10
args_left = 30304387
i = 2
maxargs = 0
argvals = {13266816, 0, 140737488326448, 140737488326576,
140737488326560, 5915316, 2, 30318963}
fun = 12703933
val = 140737488326624
original_fun = 33936
original_args = 30304387
funcar = 0
count = 46
#100 0x000000000059cabe in Fif (args=30304435) at eval.c:384
cond = 27466557
#101 0x00000000005a1be3 in eval_sub (form=30304451) at eval.c:2085
numargs = 10
args_left = 30304435
i = 2
maxargs = 0
argvals = {2, 25236016, 140737488326976, 25783087632, 0, 41856,
13080496, 140737488326784}
fun = 12703837
val = 140737488326928
original_fun = 23328
original_args = 30304435
funcar = 140737488326864
count = 45
#102 0x000000000059cd42 in Fprogn (body=30304723) at eval.c:427
val = 0
#103 0x000000000059e9d6 in Flet (args=30304739) at eval.c:943
temps = 0x7fffffff9150
tem = 27466557
lexenv = 45590147
elt = 30307075
varlist = 0
count = 44
argnum = 1
sa_avail = 16376
sa_count = 44
sa_must_free = false
#104 0x00000000005a1be3 in eval_sub (form=30304755) at eval.c:2085
numargs = 10
args_left = 30304739
i = 2
maxargs = 0
argvals = {115, 18914517, 462, 25783087632, 0, 41856, 13080496,
140737488327264}
fun = 12704557
val = 0
original_fun = 26736
original_args = 30304739
funcar = 11952
count = 43
#105 0x000000000059cd42 in Fprogn (body=30304771) at eval.c:427
val = 0
#106 0x00000000005a420c in funcall_lambda (fun=30304867, nargs=5,
arg_vector=0x7fffffff93b0) at eval.c:2869
val = 5174391
syms_left = 0
next = 7488
lexenv = 46157907
count = 42
i = 5
optional = false
rest = true
#107 0x00000000005a3b4e in apply_lambda (fun=30304883, args=27606451, count=41)
at eval.c:2751
args_left = 0
i = 5
numargs = 5
arg_vector = 0x7fffffff93b0
tem = 41234100
sa_avail = 16344
sa_count = 42
sa_must_free = false
#108 0x00000000005a22bb in eval_sub (form=27606579) at eval.c:2198
fun = 30304883
val = 140737488328032
original_fun = 15172464
original_args = 27606451
funcar = 11952
count = 41
#109 0x000000000059cd42 in Fprogn (body=27605795) at eval.c:427
val = 0
#110 0x000000000059cb71 in Fif (args=27610355) at eval.c:385
cond = 0
#111 0x00000000005a1be3 in eval_sub (form=27611539) at eval.c:2085
numargs = 14
args_left = 27610355
i = 3
maxargs = 0
argvals = {38586432, 140737488328216, 5181002, 25783087632, 0, 41856,
13080496, 140737488328240}
fun = 12703837
val = 140737488328384
original_fun = 23328
original_args = 27610355
funcar = 140737488328320
count = 40
#112 0x000000000059cd42 in Fprogn (body=27604451) at eval.c:427
val = 0
#113 0x00000000005a420c in funcall_lambda (fun=27670195, nargs=5,
arg_vector=0x7fffffff9838) at eval.c:2869
val = 11952
syms_left = 0
next = 3425248
lexenv = 46158339
count = 39
i = 5
optional = false
rest = false
#114 0x00000000005a38d3 in Ffuncall (nargs=6, args=0x7fffffff9830)
at eval.c:2711
fun = 27669843
original_fun = 15396096
funcar = 11952
numargs = 5
lisp_numargs = 140737488328688
val = 140737488328736
internal_args = 0x0
count = 38
#115 0x00000000005a2857 in Fapply (nargs=2, args=0x7fffffff98f0) at eval.c:2278
i = 6
numargs = 5
funcall_nargs = 6
funcall_args = 0x7fffffff9830
spread_arg = 0
fun = 27669843
retval = 5181002
sa_avail = 16336
sa_count = 38
sa_must_free = false
#116 0x00000000005a1dc3 in eval_sub (form=30335235) at eval.c:2103
vals = 0x7fffffff98f0
argnum = 2
sa_avail = 16368
sa_count = 38
sa_must_free = false
numargs = 10
args_left = 0
i = -26376
maxargs = 0
argvals = {0, 0, 0, 26, 9406029, 9405996, 12577954, 9405996}
fun = 12705133
val = 140737488329216
original_fun = 7440
original_args = 30335251
funcar = 140737488329152
count = 37
#117 0x000000000059f9ee in internal_lisp_condition_case (var=4171408,
bodyform=30335235, handlers=30335427) at eval.c:1278
val = 0
c = 0x14a3370
oldhandlerlist = 0x14a2410
clausenb = 1
#118 0x000000000059f3ee in Fcondition_case (args=30335219) at eval.c:1203
var = 4171408
bodyform = 30335235
handlers = 30335427
#119 0x00000000005a1be3 in eval_sub (form=30335203) at eval.c:2085
numargs = 14
args_left = 30335219
i = 3
maxargs = 0
argvals = {7, 0, 140737488329792, 5904587, 0, 299216, 140737488329600,
46158675}
fun = 12704845
val = 140737488329744
original_fun = 300624
original_args = 30335219
funcar = 579868614149
count = 36
#120 0x000000000059cd42 in Fprogn (body=30335443) at eval.c:427
val = 0
#121 0x000000000059cb71 in Fif (args=30335123) at eval.c:385
cond = 0
#122 0x00000000005a1be3 in eval_sub (form=30335107) at eval.c:2085
numargs = 14
args_left = 30335123
i = 3
maxargs = 0
argvals = {140737488329888, 25235696, 140737488330144, 25783087632, 0,
41856, 13080496, 140737488329952}
fun = 12703837
val = 140737488330096
original_fun = 23328
original_args = 30335123
funcar = 140737488330032
count = 35
#123 0x000000000059cd42 in Fprogn (body=30334035) at eval.c:427
val = 0
#124 0x000000000059e9d6 in Flet (args=30334051) at eval.c:943
temps = 0x7fffffff9db0
tem = 15396096
lexenv = 46158643
elt = 30335923
varlist = 0
count = 34
argnum = 1
sa_avail = 16376
sa_count = 34
sa_must_free = false
#125 0x00000000005a1be3 in eval_sub (form=30334067) at eval.c:2085
numargs = 14
args_left = 30334051
i = 3
maxargs = 0
argvals = {140737488330416, 46158675, 140737488330624, 5904481,
5116089176692883456, 3425200, 1433318007, 13281456}
fun = 12704557
val = 140737488330576
original_fun = 26736
original_args = 30334051
funcar = 140737488330512
count = 33
#126 0x000000000059cd42 in Fprogn (body=30334083) at eval.c:427
val = 0
#127 0x000000000059eaf2 in Fwhile (args=30334099) at eval.c:962
test = 3425200
body = 30334083
#128 0x00000000005a1be3 in eval_sub (form=30334115) at eval.c:2085
numargs = 10
args_left = 30334099
i = 2
maxargs = 0
argvals = {13, 25235600, 140737488330992, 25783087632, 0, 41856,
13080496, 140737488330800}
fun = 12704605
val = 140737488330944
original_fun = 300304
original_args = 30334099
funcar = 140737488330880
count = 32
#129 0x000000000059cd42 in Fprogn (body=30334131) at eval.c:427
val = 0
#130 0x000000000059e9d6 in Flet (args=30334147) at eval.c:943
temps = 0x7fffffffa100
tem = 29405635
lexenv = 46158675
elt = 30335843
varlist = 0
count = 31
argnum = 1
sa_avail = 16376
sa_count = 31
sa_must_free = false
#131 0x00000000005a1be3 in eval_sub (form=30334163) at eval.c:2085
numargs = 10
args_left = 30334147
i = 2
maxargs = 0
argvals = {0, 5908622, 140737488331336, 25783087632, 0, 41856,
13080496, 140737488331280}
fun = 12704557
val = 140737488331424
original_fun = 26736
original_args = 30334147
funcar = 140737488331360
count = 30
#132 0x000000000059cd42 in Fprogn (body=30334659) at eval.c:427
val = 26443828
#133 0x00000000005a420c in funcall_lambda (fun=30334755, nargs=7,
arg_vector=0x7fffffffa418) at eval.c:2869
val = 11952
syms_left = 0
next = 7488
lexenv = 46158803
count = 29
i = 7
optional = false
rest = true
#134 0x00000000005a38d3 in Ffuncall (nargs=8, args=0x7fffffffa410)
at eval.c:2711
fun = 30334771
original_fun = 15173088
funcar = 11952
numargs = 7
lisp_numargs = 45445171
val = 140737488331776
internal_args = 0x0
count = 28
#135 0x00000000005a2857 in Fapply (nargs=6, args=0x7fffffffa4e0) at eval.c:2278
i = 8
numargs = 7
funcall_nargs = 8
funcall_args = 0x7fffffffa410
spread_arg = 0
fun = 30334771
retval = 5181002
sa_avail = 16320
sa_count = 28
sa_must_free = false
#136 0x00000000005a1dc3 in eval_sub (form=30307219) at eval.c:2103
vals = 0x7fffffffa4e0
argnum = 6
sa_avail = 16336
sa_count = 28
sa_must_free = false
numargs = 26
args_left = 0
i = -23288
maxargs = 0
argvals = {45445171, 24816, 2, 25235440, 13080496, 42317360,
140737488332160, 0}
fun = 12705133
val = 140737488332304
original_fun = 7440
original_args = 30307267
funcar = 5180867
count = 27
#137 0x000000000059cd42 in Fprogn (body=30304387) at eval.c:427
val = 0
#138 0x00000000005a1be3 in eval_sub (form=30304403) at eval.c:2085
numargs = 10
args_left = 30304387
i = 2
maxargs = 0
argvals = {13266816, 0, 140737488332432, 140737488332560,
140737488332544, 5915316, 2, 30318963}
fun = 12703933
val = 140737488332608
original_fun = 33936
original_args = 30304387
funcar = 0
count = 26
#139 0x000000000059cabe in Fif (args=30304435) at eval.c:384
cond = 27466557
#140 0x00000000005a1be3 in eval_sub (form=30304451) at eval.c:2085
numargs = 10
args_left = 30304435
i = 2
maxargs = 0
argvals = {2, 25235376, 140737488332960, 25783087632, 0, 41856,
13080496, 140737488332768}
fun = 12703837
val = 140737488332912
original_fun = 23328
original_args = 30304435
funcar = 140737488332848
count = 25
#141 0x000000000059cd42 in Fprogn (body=30304723) at eval.c:427
val = 0
#142 0x000000000059e9d6 in Flet (args=30304739) at eval.c:943
temps = 0x7fffffffa8b0
tem = 27466557
lexenv = 45435091
elt = 30307075
varlist = 0
count = 24
argnum = 1
sa_avail = 16376
sa_count = 24
sa_must_free = false
#143 0x00000000005a1be3 in eval_sub (form=30304755) at eval.c:2085
numargs = 10
args_left = 30304739
i = 2
maxargs = 0
argvals = {140737488333216, 13080496, 140737488333216, 25783087632, 0,
41856, 13080496, 140737488333248}
fun = 12704557
val = 0
original_fun = 26736
original_args = 30304739
funcar = 11952
count = 23
#144 0x000000000059cd42 in Fprogn (body=30304771) at eval.c:427
val = 0
#145 0x00000000005a420c in funcall_lambda (fun=30304867, nargs=5,
arg_vector=0x7fffffffabc8) at eval.c:2869
val = 11952
syms_left = 0
next = 7488
lexenv = 45445171
count = 22
i = 5
optional = false
rest = true
#146 0x00000000005a38d3 in Ffuncall (nargs=6, args=0x7fffffffabc0)
at eval.c:2711
fun = 30304883
original_fun = 15172464
funcar = 11952
numargs = 5
lisp_numargs = 1
val = 140737488333744
internal_args = 0x0
count = 21
#147 0x00000000005a2857 in Fapply (nargs=5, args=0x7fffffffac80) at eval.c:2278
i = 6
numargs = 5
funcall_nargs = 6
funcall_args = 0x7fffffffabc0
spread_arg = 0
fun = 30304883
retval = 5181002
sa_avail = 16336
sa_count = 21
sa_must_free = false
#148 0x00000000005a1dc3 in eval_sub (form=30314451) at eval.c:2103
vals = 0x7fffffffac80
argnum = 5
sa_avail = 16344
sa_count = 21
sa_must_free = false
numargs = 22
args_left = 0
i = -21344
maxargs = 0
argvals = {140737488334048, 25235248, 140737488334304, 5907209, 0,
30313331, 45446035, 140737488334112}
fun = 12705133
val = 140737488334256
original_fun = 7440
original_args = 30312483
funcar = 140737488334192
count = 20
#149 0x000000000059cd42 in Fprogn (body=30312563) at eval.c:427
val = 0
#150 0x000000000059e472 in FletX (args=30311523) at eval.c:879
varlist = 0
var = 7488
val = 45446003
elt = 30313395
lexenv = 46061075
count = 19
#151 0x00000000005a1be3 in eval_sub (form=30311539) at eval.c:2085
numargs = 10
args_left = 30311523
i = 2
maxargs = 0
argvals = {140737488334480, 24816, 140737488334512, 25783087632, 0,
41856, 13080496, 140737488334528}
fun = 12704509
val = 0
original_fun = 26784
original_args = 30311523
funcar = 11952
count = 18
#152 0x000000000059cd42 in Fprogn (body=30311619) at eval.c:427
val = 0
#153 0x00000000005a420c in funcall_lambda (fun=30311715, nargs=2,
arg_vector=0x7fffffffb010) at eval.c:2869
val = 5927501
syms_left = 0
next = 26976
lexenv = 46061075
count = 17
i = 2
optional = false
rest = false
#154 0x00000000005a3b4e in apply_lambda (fun=30311731, args=30316355, count=16)
at eval.c:2751
args_left = 0
i = 2
numargs = 2
arg_vector = 0x7fffffffb010
tem = 41234388
sa_avail = 16368
sa_count = 17
sa_must_free = false
#155 0x00000000005a22bb in eval_sub (form=30316339) at eval.c:2198
fun = 30311731
val = 42336787
original_fun = 15172608
original_args = 30316355
funcar = 11952
count = 16
#156 0x000000000059cd42 in Fprogn (body=30316387) at eval.c:427
val = 42336787
#157 0x000000000059e9d6 in Flet (args=30316099) at eval.c:943
temps = 0x7fffffffb1e0
tem = 41234388
lexenv = 46061523
elt = 30315955
varlist = 0
count = 15
argnum = 1
sa_avail = 16376
sa_count = 15
sa_must_free = false
#158 0x00000000005a1be3 in eval_sub (form=30315939) at eval.c:2085
numargs = 22
args_left = 30316099
i = 5
maxargs = 0
argvals = {42506340, 25235056, 140737488335792, 5907209,
140737488335760, 30315875, 24154676, 42506340}
fun = 12704557
val = 140737488335744
original_fun = 26736
original_args = 30316099
funcar = 3492448
count = 14
#159 0x000000000059cd42 in Fprogn (body=30314499) at eval.c:427
val = 0
#160 0x000000000059eaf2 in Fwhile (args=30315923) at eval.c:962
test = 30315875
body = 30314499
#161 0x00000000005a1be3 in eval_sub (form=30315859) at eval.c:2085
numargs = 10
args_left = 30315923
i = 2
maxargs = 0
argvals = {2, 25234960, 140737488336160, 25783087632, 0, 41856,
13080496, 140737488335968}
fun = 12704605
val = 140737488336112
original_fun = 300304
original_args = 30315923
funcar = 140737488336048
count = 13
#162 0x000000000059cd42 in Fprogn (body=30314515) at eval.c:427
val = 0
#163 0x000000000059e9d6 in Flet (args=30315843) at eval.c:943
temps = 0x7fffffffb530
tem = 42506340
lexenv = 43210819
elt = 30315747
varlist = 0
count = 11
argnum = 2
sa_avail = 16368
sa_count = 11
sa_must_free = false
#164 0x00000000005a1be3 in eval_sub (form=30315683) at eval.c:2085
numargs = 10
args_left = 30315843
i = 2
maxargs = 0
argvals = {140737488336400, 0, 140737488336640, 5904587,
140737488336448, 15172512, 13080496, 43211619}
fun = 12704557
val = 140737488336592
original_fun = 26736
original_args = 30315843
funcar = 13080496
count = 10
#165 0x000000000059cd42 in Fprogn (body=30315059) at eval.c:427
val = 0
#166 0x00000000005a1be3 in eval_sub (form=30315075) at eval.c:2085
numargs = 6
args_left = 30315059
i = 1
maxargs = 0
argvals = {0, 9, 42506340, 0, 3, 43211139, 0, 42336787}
fun = 12703933
val = 140737488336896
original_fun = 33936
original_args = 30315059
funcar = 42506340
count = 9
#167 0x000000000059cabe in Fif (args=30315107) at eval.c:384
cond = 39456
#168 0x00000000005a1be3 in eval_sub (form=30315123) at eval.c:2085
numargs = 10
args_left = 30315107
i = 2
maxargs = 0
argvals = {12727696, 12727264, 140737488337024, 25783087632, 0, 41856,
13080496, 140737488337056}
fun = 12703837
val = 42336787
original_fun = 23328
original_args = 30315107
funcar = 11952
count = 8
#169 0x000000000059cd42 in Fprogn (body=30313763) at eval.c:427
val = 42336787
#170 0x00000000005a420c in funcall_lambda (fun=30313859, nargs=2,
arg_vector=0x7fffffffbaa8) at eval.c:2869
val = 11952
syms_left = 0
next = 13872
lexenv = 43211619
count = 7
i = 2
optional = false
rest = false
#171 0x00000000005a38d3 in Ffuncall (nargs=3, args=0x7fffffffbaa0)
at eval.c:2711
fun = 30313875
original_fun = 15172224
funcar = 11952
numargs = 2
lisp_numargs = 4229744
val = 140737488337552
internal_args = 0x0
count = 6
#172 0x00000000005a2857 in Fapply (nargs=2, args=0x7fffffffbb60) at eval.c:2278
i = 3
numargs = 2
funcall_nargs = 3
funcall_args = 0x7fffffffbaa0
spread_arg = 0
fun = 30313875
retval = 0
sa_avail = 16360
sa_count = 6
sa_must_free = false
#173 0x00000000005a2ec1 in apply1 (fn=15172224, arg=45692627) at eval.c:2494
No locals.
#174 0x00000000005fc21c in read_process_output_call (fun_and_args=45692483)
at process.c:5241
No locals.
#175 0x000000000059fcb6 in internal_condition_case_1 (
bfun=0x5fc192 <read_process_output_call>, arg=45692483, handlers=16416,
hfun=0x5fc21e <read_process_output_error_handler>) at eval.c:1333
val = 42007693
c = 0x14a2410
#176 0x00000000005fc9ad in read_and_dispose_of_process_output (p=0x280fc88,
chars=0x7fffffffbc70 ":bremner!~bremner <at> debian/developer/bremner PRIVMSG #emacs :see, this why we need category theory. because categories are hard.\r\n0\266\205\002", nbytes=128, coding=0x25ba7d0) at process.c:5449
outstream = 15172224
text = 42506372
outer_running_asynch_code = false
waiting = -1
#177 0x00000000005fc5fb in read_process_output (proc=42007693, channel=9)
at process.c:5360
nbytes = 128
p = 0x280fc88
coding = 0x25ba7d0
carryover = 0
count = 3
odeactivate = 0
chars = ":bremner!~bremner <at> debian/developer/bremner PRIVMSG #emacs :see, this why we need category theory. because categories are hard.\r\n0\266\205\002\000\000\000\000\020\275\377\377\377\177\000\000#\017O\000\000\000\000\000\340\063\302\000\000\000\000\000\060\275\377\377\377\177\000\000\240\243\307\000\000\000\000\000@\275\377\377\377\177\000\000\220\016\312\000\000\000\000\000\240\271\301", '\000' <repeats 13 times>...
#178 0x00000000005fbb75 in wait_reading_process_output (time_limit=30,
nsecs=0, read_kbd=-1, do_display=true, wait_for_cell=0, wait_proc=0x0,
just_wait_proc=0) at process.c:5067
nread = 32767
process_skipped = false
channel = 9
nfds = 1
Available = {fds_bits = {512, 0 <repeats 15 times>}}
Writeok = {fds_bits = {0 <repeats 16 times>}}
check_write = true
check_delay = 4
no_avail = false
xerrno = 22
proc = 42007693
timeout = {tv_sec = 0, tv_nsec = 999585382}
end_time = {tv_sec = 1444736473, tv_nsec = 221694407}
timer_delay = {tv_sec = 0, tv_nsec = 999585382}
got_output_end_time = {tv_sec = 1444736473, tv_nsec = 221694407}
wait = TIMEOUT
got_some_output = -1
count = 2
now = {tv_sec = 0, tv_nsec = -1}
#179 0x000000000041717d in sit_for (timeout=122, reading=true,
display_option=1) at dispnew.c:5756
sec = 30
nsec = 0
do_display = true
#180 0x00000000004fcbe2 in read_char (commandflag=1, map=45687155,
prev_event=0, used_mouse_menu=0x7fffffffd49f, end_time=0x0)
at keyboard.c:2702
tem0 = 8589934592
timeout = 30
delay_level = 4
buffer_size = 51
c = 0
jmpcount = 2
local_getcjmp = {{__jmpbuf = {0, -1164755293277226821, 4229744,
140737488345792, 0, 0, -1164755293379987269,
1164754841692305595}, __mask_was_saved = 0, __saved_mask = {
__val = {13242000, 140737488343776, 0, 140737488343776, 5174391,
17307264, 13242000, 140737488343920, 0, 140737488343824,
5174391, 0, 45687427, 140737488343920, 5918068, 0}}}}
save_jump = {{__jmpbuf = {46719384, 23482373, 140737488332992,
17184122957, 46487760, 140737488332984, 5181002, 17201297920},
__mask_was_saved = 44227616, __saved_mask = {__val = {21474814168,
13523240, 140737488333032, 5181002, 17179869184, 13532752,
140737488333064, 5181002, 13242000, 4294967297, 0,
140737488333088, 5174391, 5181095, 41106176,
140737488333136}}}}
tem = 45687155
save = 140737488343920
previous_echo_area_message = 0
also_record = 0
reread = false
recorded = false
polling_stopped_here = false
orig_kboard = 0x14982b0
#181 0x000000000050b8d0 in read_key_sequence (keybuf=0x7fffffffd650,
bufsize=30, prompt=0, dont_downcase_last=false,
can_return_switch_frame=true, fix_current_buffer=true,
prevent_redisplay=false) at keyboard.c:9030
interrupted_kboard = 0x14982b0
interrupted_frame = 0xce5578
key = 42317365
used_mouse_menu = false
echo_local_start = 0
last_real_key_start = 0
keys_local_start = 0
new_binding = 140737488344528
count = 2
t = 0
echo_start = 0
keys_start = 0
current_binding = 45687155
first_event = 0
first_unbound = 31
mock_input = 0
fkey = {parent = 13629363, map = 13629363, start = 0, end = 0}
keytran = {parent = 13440579, map = 13440579, start = 0, end = 0}
indec = {parent = 13629379, map = 13629379, start = 0, end = 0}
shift_translated = false
delayed_switch_frame = 0
original_uppercase = 5181002
original_uppercase_position = -1
dummyflag = false
starting_buffer = 0x285b630
fake_prefixed_keys = 0
#182 0x00000000004f9359 in command_loop_1 () at keyboard.c:1348
cmd = 15599760
keybuf = {54, 366, 210, 506, 257664, 2, 3, 140737488344808, 0,
9064821, 140737488344800, 0, 140737488344832, 5910429, 0, 13242000,
41647619, 0, 140737488344832, 5174391, 9077284, 13242000,
140737488344880, 0, 140737488344880, 5174391, 140737488344880, 2,
140737488344992, 5211963}
i = 1
prev_modiff = 34428
prev_buffer = 0x285b630
already_adjusted = false
#183 0x000000000059fb4b in internal_condition_case (
bfun=0x4f8f17 <command_loop_1>, handlers=16416, hfun=0x4f85a7 <cmd_error>)
at eval.c:1309
val = 140737488345248
c = 0x14a22e0
#184 0x00000000004f8b55 in command_loop_2 (ignore=0) at keyboard.c:1088
val = 2
#185 0x000000000059ef7f in internal_catch (tag=40656,
func=0x4f8b2c <command_loop_2>, arg=0) at eval.c:1073
val = 0
c = 0x1498380
#186 0x00000000004f8af5 in command_loop () at keyboard.c:1067
No locals.
#187 0x00000000004f8086 in recursive_edit_1 () at keyboard.c:673
count = 1
val = 140737488345296
#188 0x00000000004f8291 in Frecursive_edit () at keyboard.c:744
count = 0
buffer = 0
#189 0x00000000004f60b3 in main (argc=1, argv=0x7fffffffdac8) at emacs.c:1643
dummy = 140737488345456
stack_bottom_variable = 0 '\000'
do_initial_setlocale = true
dumping = false
skip_args = 0
rlim = {rlim_cur = 10485760, rlim_max = 18446744073709551615}
no_loadup = false
junk = 0x0
dname_arg = 0x0
ch_to_dir = 0x0
original_pwd = 0x0
bug-gnu-emacs <at> gnu.org:bug#21666; Package emacs.
(Tue, 13 Oct 2015 16:10:03 GMT) Full text and rfc822 format available.Message #14 received at 21666 <at> debbugs.gnu.org (full text, mbox):
From: Paul Eggert <eggert <at> cs.ucla.edu> To: Jorgen Schaefer <Jorgen.Schaefer <at> gmail.com>, 21666 <at> debbugs.gnu.org Subject: Re: 25.0.50; Random segfaults Date: Tue, 13 Oct 2015 09:09:16 -0700
[Message part 1 (text/plain, inline)]
Those two backtraces both have a call to mapcar1 with a long list (leni=2544 in one, leni=2502 in the other). When Fmapcar uses SAFE_ALLOCA_LISP, it'll ask for (say) 2502*8 bytes, or 20016 bytes, and this is more than the 16 KiB MAX_ALLOCA limit, which means SAFE_ALLOCA_LISP will invoke xmalloc and make_save_memory rather than invoking AVAIL_ALLOCA. One possibility is that the xmalloced memory isn't being properly analyzed by the garbage collector. To test that theory, can you please try something like the attached patch? This wouldn't fix the bug, but it would mean mapcar should work for larger lists and you won't get a backtrace until the list gets about twice as large.
[t.diff (text/plain, attachment)]
bug-gnu-emacs <at> gnu.org:bug#21666; Package emacs.
(Thu, 15 Oct 2015 11:06:02 GMT) Full text and rfc822 format available.Message #17 received at 21666 <at> debbugs.gnu.org (full text, mbox):
From: Jorgen Schäfer <jorgen.schaefer <at> gmail.com> To: Paul Eggert <eggert <at> cs.ucla.edu>, 21666 <at> debbugs.gnu.org Subject: Re: 25.0.50; Random segfaults Date: Thu, 15 Oct 2015 11:05:07 +0000
[Message part 1 (text/plain, inline)]
Hello! The attached backtrace is running the same Emacs version (e6013e8c) but with your patch applied. Program received signal SIGSEGV, Segmentation fault. mark_object (arg=140737488314368) at alloc.c:6187 6187 if (ptr->gcmarkbit) Anything else I can try to narrow it down more? :-) Regards, Jorgen On Tue, Oct 13, 2015 at 6:09 PM Paul Eggert <eggert <at> cs.ucla.edu> wrote: > Those two backtraces both have a call to mapcar1 with a long list > (leni=2544 in > one, leni=2502 in the other). When Fmapcar uses SAFE_ALLOCA_LISP, it'll > ask for > (say) 2502*8 bytes, or 20016 bytes, and this is more than the 16 KiB > MAX_ALLOCA > limit, which means SAFE_ALLOCA_LISP will invoke xmalloc and > make_save_memory > rather than invoking AVAIL_ALLOCA. One possibility is that the xmalloced > memory > isn't being properly analyzed by the garbage collector. To test that > theory, > can you please try something like the attached patch? This wouldn't fix > the > bug, but it would mean mapcar should work for larger lists and you won't > get a > backtrace until the list gets about twice as large. > >
[Message part 2 (text/html, inline)]
[emacs-bug-3.txt (text/plain, attachment)]
bug-gnu-emacs <at> gnu.org:bug#21666; Package emacs.
(Fri, 16 Oct 2015 08:05:02 GMT) Full text and rfc822 format available.Message #20 received at 21666 <at> debbugs.gnu.org (full text, mbox):
From: Jorgen Schäfer <jorgen.schaefer <at> gmail.com> To: Paul Eggert <eggert <at> cs.ucla.edu>, 21666 <at> debbugs.gnu.org Subject: Re: 25.0.50; Random segfaults Date: Fri, 16 Oct 2015 08:03:46 +0000
[Message part 1 (text/plain, inline)]
And another one, this time in the same location as emacs-bug-2. mapcar's leni=2682, so not that much larger. If I read the backtrace correctly, this should be the following piece of code, if that's helpful at all: https://github.com/jorgenschaefer/circe/blob/master/lui.el#L916-L970 Regards, Jorgen On Thu, Oct 15, 2015 at 1:05 PM Jorgen Schäfer <jorgen.schaefer <at> gmail.com> wrote: > Hello! > The attached backtrace is running the same Emacs version (e6013e8c) but > with your patch applied. > > Program received signal SIGSEGV, Segmentation fault. > mark_object (arg=140737488314368) at alloc.c:6187 > 6187 if (ptr->gcmarkbit) > > Anything else I can try to narrow it down more? :-) > > Regards, > Jorgen > > > On Tue, Oct 13, 2015 at 6:09 PM Paul Eggert <eggert <at> cs.ucla.edu> wrote: > >> Those two backtraces both have a call to mapcar1 with a long list >> (leni=2544 in >> one, leni=2502 in the other). When Fmapcar uses SAFE_ALLOCA_LISP, it'll >> ask for >> (say) 2502*8 bytes, or 20016 bytes, and this is more than the 16 KiB >> MAX_ALLOCA >> limit, which means SAFE_ALLOCA_LISP will invoke xmalloc and >> make_save_memory >> rather than invoking AVAIL_ALLOCA. One possibility is that the xmalloced >> memory >> isn't being properly analyzed by the garbage collector. To test that >> theory, >> can you please try something like the attached patch? This wouldn't fix >> the >> bug, but it would mean mapcar should work for larger lists and you won't >> get a >> backtrace until the list gets about twice as large. >> >>
[Message part 2 (text/html, inline)]
[emacs-bug-4.txt (text/plain, attachment)]
bug-gnu-emacs <at> gnu.org:bug#21666; Package emacs.
(Fri, 16 Oct 2015 08:06:01 GMT) Full text and rfc822 format available.Message #23 received at 21666 <at> debbugs.gnu.org (full text, mbox):
From: Paul Eggert <eggert <at> cs.ucla.edu> To: Jorgen Schäfer <jorgen.schaefer <at> gmail.com>, 21666 <at> debbugs.gnu.org Subject: Re: 25.0.50; Random segfaults Date: Fri, 16 Oct 2015 01:05:22 -0700
Jorgen Schäfer wrote: > And another one, this time in the same location as emacs-bug-2. mapcar's > leni=2682, so not that much larger. Yes, it's looking like my guess at the problem was incorrect, unfortunately.
bug-gnu-emacs <at> gnu.org:bug#21666; Package emacs.
(Fri, 16 Oct 2015 09:04:01 GMT) Full text and rfc822 format available.Message #26 received at 21666 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Paul Eggert <eggert <at> cs.ucla.edu> Cc: jorgen.schaefer <at> gmail.com, 21666 <at> debbugs.gnu.org Subject: Re: bug#21666: 25.0.50; Random segfaults Date: Fri, 16 Oct 2015 12:03:12 +0300
> From: Paul Eggert <eggert <at> cs.ucla.edu> > Date: Fri, 16 Oct 2015 01:05:22 -0700 > > Jorgen Schäfer wrote: > > And another one, this time in the same location as emacs-bug-2. mapcar's > > leni=2682, so not that much larger. > > Yes, it's looking like my guess at the problem was incorrect, unfortunately. Do I read the backtrace correctly to indicate that Fabs was called with an argument that is a symbol, not a number? If so, how could it possibly evade the CHECK_NUMBER_OR_FLOAT test just before XFLOAT? That sounds similar to a problem Cygwin users had, whereby some system code invoked by a signal handler or another thread (and which thus interrupted Emacs between the test and the use of the value) didn't preserve registers correctly. Is there any other explanation?
bug-gnu-emacs <at> gnu.org:bug#21666; Package emacs.
(Fri, 16 Oct 2015 22:29:01 GMT) Full text and rfc822 format available.Message #29 received at 21666 <at> debbugs.gnu.org (full text, mbox):
From: Paul Eggert <eggert <at> cs.ucla.edu> To: Eli Zaretskii <eliz <at> gnu.org> Cc: jorgen.schaefer <at> gmail.com, 21666 <at> debbugs.gnu.org Subject: Re: bug#21666: 25.0.50; Random segfaults Date: Fri, 16 Oct 2015 15:28:44 -0700
On 10/16/2015 02:03 AM, Eli Zaretskii wrote: > Do I read the backtrace correctly to indicate that Fabs was called > with an argument that is a symbol, not a number? No, Fabs's argument is 95, which means its tag is 7, which is Lisp_Float. Applying XFLOAT to 95 yields (struct Lisp_Float *) 0x58, which is not a valid pointer. The new backtrace contains a call to Fmapcar, so it could well be that the problem is mapcar-related. However, my hypothesis does not look right, because this code has been patched so that sa_must_free is false, which means mapcar's temporary array of Lisp_Object values is allocated on the C stack and not via malloc. I'm afraid this means I am at a loss.
bug-gnu-emacs <at> gnu.org:bug#21666; Package emacs.
(Sat, 17 Oct 2015 08:07:01 GMT) Full text and rfc822 format available.Message #32 received at 21666 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Paul Eggert <eggert <at> cs.ucla.edu> Cc: jorgen.schaefer <at> gmail.com, 21666 <at> debbugs.gnu.org Subject: Re: bug#21666: 25.0.50; Random segfaults Date: Sat, 17 Oct 2015 11:06:34 +0300
> Cc: jorgen.schaefer <at> gmail.com, 21666 <at> debbugs.gnu.org > From: Paul Eggert <eggert <at> cs.ucla.edu> > Date: Fri, 16 Oct 2015 15:28:44 -0700 > > On 10/16/2015 02:03 AM, Eli Zaretskii wrote: > > Do I read the backtrace correctly to indicate that Fabs was called > > with an argument that is a symbol, not a number? > > No, Fabs's argument is 95, which means its tag is 7, which is > Lisp_Float. Applying XFLOAT to 95 yields (struct Lisp_Float *) 0x58, > which is not a valid pointer. > > The new backtrace contains a call to Fmapcar, so it could well be that > the problem is mapcar-related. However, my hypothesis does not look > right, because this code has been patched so that sa_must_free is false, > which means mapcar's temporary array of Lisp_Object values is allocated > on the C stack and not via malloc. I'm afraid this means I am at a loss. Stack corruption might be caused by overrunning the bounds of an automatic array, or by calling a function that overwrites the bounds of its array argument. Maybe using some debugging libraries or GCC options for these problems could catch the bad code? Another idea is to look at values in addresses adjacent to the one where this Lisp_Float was stored. 0x58 is a code of an ASCII character (and so is 95 = 0x5F), so perhaps we have some ASCII text around there. If so, and if we can recognize that text, that could give us some hints as to where to look for the villain.
bug-gnu-emacs <at> gnu.org:bug#21666; Package emacs.
(Fri, 23 Oct 2015 09:42:03 GMT) Full text and rfc822 format available.Message #35 received at 21666 <at> debbugs.gnu.org (full text, mbox):
From: Jorgen Schäfer <jorgen.schaefer <at> gmail.com> To: 21666 <at> debbugs.gnu.org Subject: Re: 25.0.50; Random segfaults Date: Fri, 23 Oct 2015 09:41:35 +0000
[Message part 1 (text/plain, inline)]
Hello again! A few more backtraces in various locations, this time around with the gdb settings in the Emacs git tree. I also upgraded to 2add4a, the problem did not go away. Any suggestions on how I can help debug this further? :-) Regards, Jorgen
[Message part 2 (text/html, inline)]
[emacs-bug.txt (text/plain, attachment)]
[emacs-bug-2.txt (text/plain, attachment)]
bug-gnu-emacs <at> gnu.org:bug#21666; Package emacs.
(Fri, 23 Oct 2015 10:05:01 GMT) Full text and rfc822 format available.Message #38 received at 21666 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Jorgen Schäfer <jorgen.schaefer <at> gmail.com> Cc: 21666 <at> debbugs.gnu.org Subject: Re: bug#21666: 25.0.50; Random segfaults Date: Fri, 23 Oct 2015 13:04:26 +0300
> From: Jorgen Schäfer <jorgen.schaefer <at> gmail.com> > Date: Fri, 23 Oct 2015 09:41:35 +0000 > > A few more backtraces in various locations, this time around with the gdb > settings in the Emacs git tree. > > I also upgraded to 2add4a, the problem did not go away. > > Any suggestions on how I can help debug this further? :-) There's something _very_ weird going on on your system. For example: > Lisp Backtrace: > "car" (0xffff47f0) > "numberp" (0xffff4938) > "cond" (0xffff4a78) This says that 'numberp' calls 'car', which is false, according to my reading of the code. What system-wide or Emacs-related changes, excluding "git pull" from the repository, did you make immediately before this started happening? Any system upgrades, new installations, anything else?
bug-gnu-emacs <at> gnu.org:bug#21666; Package emacs.
(Fri, 23 Oct 2015 10:28:02 GMT) Full text and rfc822 format available.Message #41 received at 21666 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: jorgen.schaefer <at> gmail.com Cc: 21666 <at> debbugs.gnu.org Subject: Re: bug#21666: 25.0.50; Random segfaults Date: Fri, 23 Oct 2015 13:26:47 +0300
> From: Eli Zaretskii <eliz <at> gnu.org> > Cc: 21666 <at> debbugs.gnu.org > > > Lisp Backtrace: > > "car" (0xffff47f0) > > "numberp" (0xffff4938) > > "cond" (0xffff4a78) > > This says that 'numberp' calls 'car', which is false, according to my > reading of the code. Or maybe I'm reading this incorrectly. In any case: > #0 CAR (c=4210977137704721523) at lisp.h:1195 How can CAR segfault? > What system-wide or Emacs-related changes, excluding "git pull" from > the repository, did you make immediately before this started > happening? Any system upgrades, new installations, anything else? This question still stands.
bug-gnu-emacs <at> gnu.org:bug#21666; Package emacs.
(Sun, 29 Nov 2015 19:15:02 GMT) Full text and rfc822 format available.Message #44 received at 21666 <at> debbugs.gnu.org (full text, mbox):
From: Jorgen Schäfer <jorgen.schaefer <at> gmail.com> To: 21666 <at> debbugs.gnu.org Subject: Re: bug#21666: Acknowledgement (25.0.50; Random segfaults) Date: Sun, 29 Nov 2015 19:13:51 +0000
[Message part 1 (text/plain, inline)]
Just as a small update, I downgraded to 19efb9db and have not seen any crashes in the last fortnight, so I would rule out environment or VM issues. I can upgrade back to the latest master version if you have any suggestions on how to debug this further. Regards, Jorgen
[Message part 2 (text/html, inline)]
bug-gnu-emacs <at> gnu.org:bug#21666; Package emacs.
(Wed, 09 Mar 2016 10:15:01 GMT) Full text and rfc822 format available.Message #47 received at 21666 <at> debbugs.gnu.org (full text, mbox):
From: Jorgen Schäfer <jorgen.schaefer <at> gmail.com> To: "21666 <at> debbugs.gnu.org" <21666 <at> debbugs.gnu.org> Subject: Bug is indeed undo-list and GC related Date: Wed, 09 Mar 2016 10:14:35 +0000
[Message part 1 (text/plain, inline)]
Hello! After applying the same fix as in #22120, that is, binding gc-cons-threshold to most-positive-fixnum, the crashes have not reoccurred. That is, the two bugs refer to the same problem. I do not know how GC works in Emacs Lisp, but it seems to me that an Emacs Lisp program should not be able to segfault Emacs in this manner. It is interesting that this problem was introduced sometime after 19efb9 – an Emacs built from that commit did not exhibit the problem. Hope this helps, Jorgen
[Message part 2 (text/html, inline)]
bug-gnu-emacs <at> gnu.org:bug#21666; Package emacs.
(Wed, 09 Mar 2016 15:16:02 GMT) Full text and rfc822 format available.Message #50 received at 21666 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Jorgen Schäfer <jorgen.schaefer <at> gmail.com> Cc: 21666 <at> debbugs.gnu.org Subject: Re: bug#21666: Bug is indeed undo-list and GC related Date: Wed, 09 Mar 2016 17:15:28 +0200
> From: Jorgen Schäfer <jorgen.schaefer <at> gmail.com> > Date: Wed, 09 Mar 2016 10:14:35 +0000 > > I do not know how GC works in Emacs Lisp, but it seems to me that an Emacs Lisp program should not be > able to segfault Emacs in this manner. It is interesting that this problem was introduced sometime after > 19efb9 – an Emacs built from that commit did not exhibit the problem. Can you bisect it more narrowly? "After 19efb9" leaves a lot of alternatives... Thanks.
bug-gnu-emacs <at> gnu.org:bug#21666; Package emacs.
(Wed, 09 Mar 2016 15:23:01 GMT) Full text and rfc822 format available.Message #53 received at 21666 <at> debbugs.gnu.org (full text, mbox):
From: Jorgen Schäfer <jorgen.schaefer <at> gmail.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: 21666 <at> debbugs.gnu.org Subject: Re: bug#21666: Bug is indeed undo-list and GC related Date: Wed, 09 Mar 2016 15:21:45 +0000
[Message part 1 (text/plain, inline)]
No, I can not. As mentioned, the problem occurs after a day or two of usage. If you understand the problem better now that you know what prevents it, I am of course happy to run test cases. Eli Zaretskii <eliz <at> gnu.org> schrieb am Mi., 9. März 2016 16:15: > > From: Jorgen Schäfer <jorgen.schaefer <at> gmail.com> > > Date: Wed, 09 Mar 2016 10:14:35 +0000 > > > > I do not know how GC works in Emacs Lisp, but it seems to me that an > Emacs Lisp program should not be > > able to segfault Emacs in this manner. It is interesting that this > problem was introduced sometime after > > 19efb9 – an Emacs built from that commit did not exhibit the problem. > > Can you bisect it more narrowly? "After 19efb9" leaves a lot of > alternatives... > > Thanks. >
[Message part 2 (text/html, inline)]
bug-gnu-emacs <at> gnu.org:bug#21666; Package emacs.
(Wed, 09 Mar 2016 15:45:02 GMT) Full text and rfc822 format available.Message #56 received at 21666 <at> debbugs.gnu.org (full text, mbox):
From: phillip.lord <at> russet.org.uk (Phillip Lord) To: Jorgen Schäfer <jorgen.schaefer <at> gmail.com> Cc: Eli Zaretskii <eliz <at> gnu.org>, 21666 <at> debbugs.gnu.org Subject: Re: bug#21666: Bug is indeed undo-list and GC related Date: Wed, 09 Mar 2016 15:43:56 +0000
You might try looking at commits where the undo-list handling has been changed since 19efb9. To a first approximation, git log --author="Phillip Lord" should show most of these. But these might be good ones to try. ae18cc20f899335cede183f18221b6aae539fd51 957b05c615ee749b569d9fa2b214b2a2d8fa9bda 20aa42e8204f8f0139ba3880cb32ddf88acc9bf4 Phil Jorgen Schäfer <jorgen.schaefer <at> gmail.com> writes: > No, I can not. As mentioned, the problem occurs after a day or two of > usage. If you understand the problem better now that you know what prevents > it, I am of course happy to run test cases. > > Eli Zaretskii <eliz <at> gnu.org> schrieb am Mi., 9. März 2016 16:15: > >> > From: Jorgen Schäfer <jorgen.schaefer <at> gmail.com> >> > Date: Wed, 09 Mar 2016 10:14:35 +0000 >> > >> > I do not know how GC works in Emacs Lisp, but it seems to me that an >> Emacs Lisp program should not be >> > able to segfault Emacs in this manner. It is interesting that this >> problem was introduced sometime after >> > 19efb9 – an Emacs built from that commit did not exhibit the problem. >> >> Can you bisect it more narrowly? "After 19efb9" leaves a lot of >> alternatives... >> >> Thanks. >>
bug-gnu-emacs <at> gnu.org:bug#21666; Package emacs.
(Wed, 09 Mar 2016 16:38:02 GMT) Full text and rfc822 format available.Message #59 received at 21666 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Jorgen Schäfer <jorgen.schaefer <at> gmail.com> Cc: 21666 <at> debbugs.gnu.org Subject: Re: bug#21666: Bug is indeed undo-list and GC related Date: Wed, 09 Mar 2016 18:37:19 +0200
> From: Jorgen Schäfer <jorgen.schaefer <at> gmail.com> > Date: Wed, 09 Mar 2016 15:21:45 +0000 > Cc: 21666 <at> debbugs.gnu.org > > No, I can not. As mentioned, the problem occurs after a day or two of usage. If you understand the problem > better now that you know what prevents it, I am of course happy to run test cases. I cannot say I understand the problem better, sorry. Are you running master or the emacs-25 branch? If the former, can you try the branch, please? It is more urgent to have the branch bug-free than the master, as we are in pretest for 25.1. Also, what was date or the commit of the first build which exhibited the problem? Was that the one you reported in your original message to the bug tracker? Or did you experience these problems before that? Thanks.
bug-gnu-emacs <at> gnu.org:bug#21666; Package emacs.
(Wed, 09 Mar 2016 16:48:01 GMT) Full text and rfc822 format available.Message #62 received at 21666 <at> debbugs.gnu.org (full text, mbox):
From: Jorgen Schäfer <jorgen.schaefer <at> gmail.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: 21666 <at> debbugs.gnu.org Subject: Re: bug#21666: Bug is indeed undo-list and GC related Date: Wed, 09 Mar 2016 16:46:20 +0000
[Message part 1 (text/plain, inline)]
> Are you running master or the emacs-25 branch? I am currently running Emacs from git master. > If the former, can you > try the branch, please? It is more urgent to have the branch bug-free > than the master, as we are in pretest for 25.1. Will do. I wish there was a better way of reproducing this than for me to lose time every few days to realize "oh, it's still there!" > Also, what was date or the commit of the first build which exhibited > the problem? Was that the one you reported in your original message > to the bug tracker? Or did you experience these problems before that? The ref in the original report was not the first I experienced this in, I did rebuild Emacs a few times in between assuming it was a temporary problem that would get fixed. I did not record the ref where this happened originally I'm afraid. Jorgen On Wed, Mar 9, 2016 at 5:37 PM Eli Zaretskii <eliz <at> gnu.org> wrote: > > From: Jorgen Schäfer <jorgen.schaefer <at> gmail.com> > > Date: Wed, 09 Mar 2016 15:21:45 +0000 > > Cc: 21666 <at> debbugs.gnu.org > > > > No, I can not. As mentioned, the problem occurs after a day or two of > usage. If you understand the problem > > better now that you know what prevents it, I am of course happy to run > test cases. > > I cannot say I understand the problem better, sorry. > > Are you running master or the emacs-25 branch? If the former, can you > try the branch, please? It is more urgent to have the branch bug-free > than the master, as we are in pretest for 25.1. > > Also, what was date or the commit of the first build which exhibited > the problem? Was that the one you reported in your original message > to the bug tracker? Or did you experience these problems before that? > > Thanks. >
[Message part 2 (text/html, inline)]
bug-gnu-emacs <at> gnu.org:bug#21666; Package emacs.
(Sat, 12 Mar 2016 14:44:01 GMT) Full text and rfc822 format available.Message #65 received at 21666 <at> debbugs.gnu.org (full text, mbox):
From: Jorgen Schäfer <jorgen.schaefer <at> gmail.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: 21666 <at> debbugs.gnu.org Subject: Re: bug#21666: Bug is indeed undo-list and GC related Date: Sat, 12 Mar 2016 14:43:36 +0000
[Message part 1 (text/plain, inline)]
Hello! I have been running 1b9d616 (emacs-25 branch) for the last three days and did not see any crashes, so this problem seems to be specific to the master branch. Jorgen On Wed, Mar 9, 2016 at 5:46 PM Jorgen Schäfer <jorgen.schaefer <at> gmail.com> wrote: > > Are you running master or the emacs-25 branch? > > I am currently running Emacs from git master. > > > If the former, can you > > try the branch, please? It is more urgent to have the branch bug-free > > than the master, as we are in pretest for 25.1. > > Will do. > > I wish there was a better way of reproducing this than for me to lose time > every few days to realize "oh, it's still there!" > > > Also, what was date or the commit of the first build which exhibited > > the problem? Was that the one you reported in your original message > > to the bug tracker? Or did you experience these problems before that? > > The ref in the original report was not the first I experienced this in, I > did rebuild Emacs a few times in between assuming it was a temporary > problem that would get fixed. I did not record the ref where this happened > originally I'm afraid. > > Jorgen > > On Wed, Mar 9, 2016 at 5:37 PM Eli Zaretskii <eliz <at> gnu.org> wrote: > >> > From: Jorgen Schäfer <jorgen.schaefer <at> gmail.com> >> > Date: Wed, 09 Mar 2016 15:21:45 +0000 >> > Cc: 21666 <at> debbugs.gnu.org >> > >> > No, I can not. As mentioned, the problem occurs after a day or two of >> usage. If you understand the problem >> > better now that you know what prevents it, I am of course happy to run >> test cases. >> >> I cannot say I understand the problem better, sorry. >> >> Are you running master or the emacs-25 branch? If the former, can you >> try the branch, please? It is more urgent to have the branch bug-free >> than the master, as we are in pretest for 25.1. >> >> Also, what was date or the commit of the first build which exhibited >> the problem? Was that the one you reported in your original message >> to the bug tracker? Or did you experience these problems before that? >> >> Thanks. >> >
[Message part 2 (text/html, inline)]
bug-gnu-emacs <at> gnu.org:bug#21666; Package emacs.
(Sat, 12 Mar 2016 16:24:02 GMT) Full text and rfc822 format available.Message #68 received at 21666 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Jorgen Schäfer <jorgen.schaefer <at> gmail.com>, phillip.lord <at> russet.org.uk (Phillip Lord) Cc: 21666 <at> debbugs.gnu.org Subject: Re: bug#21666: Bug is indeed undo-list and GC related Date: Sat, 12 Mar 2016 18:22:42 +0200
> From: Jorgen Schäfer <jorgen.schaefer <at> gmail.com> > Date: Sat, 12 Mar 2016 14:43:36 +0000 > Cc: 21666 <at> debbugs.gnu.org > > I have been running 1b9d616 (emacs-25 branch) for the last three days and did not see any crashes, so this > problem seems to be specific to the master branch. Thanks, this is good to know. Phillip, I think this means the undo-related changes are actually exonerated, as they are present on emacs-25 as well, right?
bug-gnu-emacs <at> gnu.org:bug#21666; Package emacs.
(Sat, 12 Mar 2016 23:45:02 GMT) Full text and rfc822 format available.Message #71 received at 21666 <at> debbugs.gnu.org (full text, mbox):
From: phillip.lord <at> russet.org.uk (Phillip Lord) To: Eli Zaretskii <eliz <at> gnu.org> Cc: Jorgen Schäfer <jorgen.schaefer <at> gmail.com>, 21666 <at> debbugs.gnu.org Subject: Re: bug#21666: Bug is indeed undo-list and GC related Date: Sat, 12 Mar 2016 23:44:32 +0000
Eli Zaretskii <eliz <at> gnu.org> writes: >> From: Jorgen Schäfer <jorgen.schaefer <at> gmail.com> >> Date: Sat, 12 Mar 2016 14:43:36 +0000 >> Cc: 21666 <at> debbugs.gnu.org >> >> I have been running 1b9d616 (emacs-25 branch) for the last three days and did not see any crashes, so this >> problem seems to be specific to the master branch. > > Thanks, this is good to know. > > Phillip, I think this means the undo-related changes are actually > exonerated, as they are present on emacs-25 as well, right? Yes. My changes went in (just) before the branch. And, the fixes from the GC problems you found went onto Emacs-25, then got merged to master. Phil
bug-gnu-emacs <at> gnu.org:bug#21666; Package emacs.
(Sun, 13 Mar 2016 09:28:02 GMT) Full text and rfc822 format available.Message #74 received at 21666 <at> debbugs.gnu.org (full text, mbox):
From: martin rudalics <rudalics <at> gmx.at> To: Phillip Lord <phillip.lord <at> russet.org.uk>, Eli Zaretskii <eliz <at> gnu.org> Cc: Jorgen Schäfer <jorgen.schaefer <at> gmail.com>, 21666 <at> debbugs.gnu.org Subject: Re: bug#21666: Bug is indeed undo-list and GC related Date: Sun, 13 Mar 2016 10:26:20 +0100
> Yes. My changes went in (just) before the branch. And, the fixes from > the GC problems you found went onto Emacs-25, then got merged to master. I'm afraid that quite a number of fixes did not get merged back to master. Could you please look into this particular issue? Thanks in advance, martin
bug-gnu-emacs <at> gnu.org:bug#21666; Package emacs.
(Sun, 13 Mar 2016 19:59:01 GMT) Full text and rfc822 format available.Message #77 received at 21666 <at> debbugs.gnu.org (full text, mbox):
From: phillip.lord <at> russet.org.uk (Phillip Lord) To: martin rudalics <rudalics <at> gmx.at> Cc: Jorgen Schäfer <jorgen.schaefer <at> gmail.com>, Eli Zaretskii <eliz <at> gnu.org>, 21666 <at> debbugs.gnu.org Subject: Re: bug#21666: Bug is indeed undo-list and GC related Date: Sun, 13 Mar 2016 19:58:49 +0000
martin rudalics <rudalics <at> gmx.at> writes: >> Yes. My changes went in (just) before the branch. And, the fixes from >> the GC problems you found went onto Emacs-25, then got merged to master. > > I'm afraid that quite a number of fixes did not get merged back to > master. Could you please look into this particular issue? I did check and, unless I am missing something subtle, the fixes did get merged. Phil
bug-gnu-emacs <at> gnu.org:bug#21666; Package emacs.
(Sun, 13 Mar 2016 20:14:01 GMT) Full text and rfc822 format available.Message #80 received at 21666 <at> debbugs.gnu.org (full text, mbox):
From: martin rudalics <rudalics <at> gmx.at> To: Phillip Lord <phillip.lord <at> russet.org.uk> Cc: Jorgen Schäfer <jorgen.schaefer <at> gmail.com>, Eli Zaretskii <eliz <at> gnu.org>, 21666 <at> debbugs.gnu.org Subject: Re: bug#21666: Bug is indeed undo-list and GC related Date: Sun, 13 Mar 2016 21:12:59 +0100
> I did check and, unless I am missing something subtle, the fixes did get > merged. Thanks for checking. martin
bug-gnu-emacs <at> gnu.org:bug#21666; Package emacs.
(Mon, 14 Mar 2016 19:57:02 GMT) Full text and rfc822 format available.Message #83 received at 21666 <at> debbugs.gnu.org (full text, mbox):
From: Jorgen Schäfer <jorgen.schaefer <at> gmail.com> To: "21666 <at> debbugs.gnu.org" <21666 <at> debbugs.gnu.org> Subject: Correction, emacs-25 *is* broken Date: Mon, 14 Mar 2016 19:56:06 +0000
[Message part 1 (text/plain, inline)]
Hi. Sorry to kill the good news – it took a while longer, but my Emacs just crashed with a segfault, so I'm afraid emacs-25 is still affected by this problem. Jorgen
[Message part 2 (text/html, inline)]
bug-gnu-emacs <at> gnu.org:bug#21666; Package emacs.
(Mon, 14 Mar 2016 20:11:02 GMT) Full text and rfc822 format available.Message #86 received at 21666 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Jorgen Schäfer <jorgen.schaefer <at> gmail.com> Cc: 21666 <at> debbugs.gnu.org Subject: Re: bug#21666: Correction, emacs-25 *is* broken Date: Mon, 14 Mar 2016 22:09:48 +0200
> From: Jorgen Schäfer <jorgen.schaefer <at> gmail.com> > Date: Mon, 14 Mar 2016 19:56:06 +0000 > > Sorry to kill the good news – it took a while longer, but my Emacs just crashed with a segfault, so I'm afraid > emacs-25 is still affected by this problem. I'm not surprised. Please always provide the backtrace and the data about the immediate reason for the crash each time you experience this. The more data we collect, the higher our chances to zero in on the perpetrator. It is best to start Emacs from the debugger, since the crashes happen relatively regularly. Thanks.
bug-gnu-emacs <at> gnu.org:bug#21666; Package emacs.
(Mon, 14 Mar 2016 20:22:01 GMT) Full text and rfc822 format available.Message #89 received at 21666 <at> debbugs.gnu.org (full text, mbox):
From: Jorgen Schäfer <jorgen.schaefer <at> gmail.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: 21666 <at> debbugs.gnu.org Subject: Re: bug#21666: Correction, emacs-25 *is* broken Date: Mon, 14 Mar 2016 20:21:01 +0000
[Message part 1 (text/plain, inline)]
Will do. Would you prefer me to run emacs-25 or master? On Mon, Mar 14, 2016 at 9:10 PM Eli Zaretskii <eliz <at> gnu.org> wrote: > > From: Jorgen Schäfer <jorgen.schaefer <at> gmail.com> > > Date: Mon, 14 Mar 2016 19:56:06 +0000 > > > > Sorry to kill the good news – it took a while longer, but my Emacs just > crashed with a segfault, so I'm afraid > > emacs-25 is still affected by this problem. > > I'm not surprised. > > Please always provide the backtrace and the data about the immediate > reason for the crash each time you experience this. The more data we > collect, the higher our chances to zero in on the perpetrator. > > It is best to start Emacs from the debugger, since the crashes happen > relatively regularly. > > Thanks. >
[Message part 2 (text/html, inline)]
bug-gnu-emacs <at> gnu.org:bug#21666; Package emacs.
(Mon, 14 Mar 2016 20:29:01 GMT) Full text and rfc822 format available.Message #92 received at 21666 <at> debbugs.gnu.org (full text, mbox):
From: phillip.lord <at> russet.org.uk (Phillip Lord) To: Jorgen Schäfer <jorgen.schaefer <at> gmail.com> Cc: "21666 <at> debbugs.gnu.org" <21666 <at> debbugs.gnu.org> Subject: Re: bug#21666: Correction, emacs-25 *is* broken Date: Mon, 14 Mar 2016 20:28:19 +0000
Jorgen Schäfer <jorgen.schaefer <at> gmail.com> writes: > Sorry to kill the good news – it took a while longer, but my Emacs just > crashed with a segfault, so I'm afraid emacs-25 is still affected by this > problem. Unsurprising. There is not a huge amount of work happening in master. You said earlier that setting gc-cons-threshold to a big value stopped the problem. What happens if you set it small, say to 1/10th or 1/100 the default value? If we can provoke the seqfault much faster then it should be possible to bisect it. Phil
bug-gnu-emacs <at> gnu.org:bug#21666; Package emacs.
(Mon, 14 Mar 2016 20:42:02 GMT) Full text and rfc822 format available.Message #95 received at 21666 <at> debbugs.gnu.org (full text, mbox):
From: Jorgen Schäfer <jorgen.schaefer <at> gmail.com> To: Phillip Lord <phillip.lord <at> russet.org.uk> Cc: "21666 <at> debbugs.gnu.org" <21666 <at> debbugs.gnu.org> Subject: Re: bug#21666: Correction, emacs-25 *is* broken Date: Mon, 14 Mar 2016 20:41:23 +0000
[Message part 1 (text/plain, inline)]
> You said earlier that setting gc-cons-threshold to a big value stopped the problem. What happens if you set it small, say to 1/10th or 1/100 the default value? I tried that, but that did not really seem to have any effect. :-( I also tried to come up with some reproduction case creating a huge undo list, small gc-cons-threshold, and then just running gc/modify undo list a lot, but that did not cause any crash, either. Jorgen On Mon, Mar 14, 2016 at 9:28 PM Phillip Lord <phillip.lord <at> russet.org.uk> wrote: > Jorgen Schäfer <jorgen.schaefer <at> gmail.com> writes: > > Sorry to kill the good news – it took a while longer, but my Emacs just > > crashed with a segfault, so I'm afraid emacs-25 is still affected by this > > problem. > > Unsurprising. There is not a huge amount of work happening in master. > > You said earlier that setting gc-cons-threshold to a big value stopped > the problem. What happens if you set it small, say to 1/10th or 1/100 > the default value? > > If we can provoke the seqfault much faster then it should be possible to > bisect it. > > Phil > > >
[Message part 2 (text/html, inline)]
bug-gnu-emacs <at> gnu.org:bug#21666; Package emacs.
(Mon, 14 Mar 2016 20:55:02 GMT) Full text and rfc822 format available.Message #98 received at 21666 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Jorgen Schäfer <jorgen.schaefer <at> gmail.com> Cc: 21666 <at> debbugs.gnu.org Subject: Re: bug#21666: Correction, emacs-25 *is* broken Date: Mon, 14 Mar 2016 22:53:32 +0200
> From: Jorgen Schäfer <jorgen.schaefer <at> gmail.com> > Date: Mon, 14 Mar 2016 20:21:01 +0000 > Cc: 21666 <at> debbugs.gnu.org > > Will do. Would you prefer me to run emacs-25 or master? Emacs-25, please.
bug-gnu-emacs <at> gnu.org:bug#21666; Package emacs.
(Mon, 14 Mar 2016 21:21:02 GMT) Full text and rfc822 format available.Message #101 received at 21666 <at> debbugs.gnu.org (full text, mbox):
From: Jorgen Schäfer <jorgen.schaefer <at> gmail.com> To: "21666 <at> debbugs.gnu.org" <21666 <at> debbugs.gnu.org> Subject: Backtrace Date: Mon, 14 Mar 2016 21:20:28 +0000
[Message part 1 (text/plain, inline)]
Did a new experiment with ./configure --enable-checking Not sure if it helped, but it crashed a lot faster …
[Message part 2 (text/html, inline)]
[gdb.log (text/x-log, attachment)]
bug-gnu-emacs <at> gnu.org:bug#21666; Package emacs.
(Mon, 14 Mar 2016 22:20:01 GMT) Full text and rfc822 format available.Message #104 received at 21666 <at> debbugs.gnu.org (full text, mbox):
From: Jorgen Schäfer <jorgen.schaefer <at> gmail.com> To: "21666 <at> debbugs.gnu.org" <21666 <at> debbugs.gnu.org> Subject: Re: Backtrace Date: Mon, 14 Mar 2016 22:19:32 +0000
[Message part 1 (text/plain, inline)]
Ignore this, I'm just not awake enough. Forgot handle SIGINT nostop noprint pass, so that's just C-g. Meh. :-( On Mon, Mar 14, 2016 at 10:20 PM Jorgen Schäfer <jorgen.schaefer <at> gmail.com> wrote: > Did a new experiment with ./configure --enable-checking > > Not sure if it helped, but it crashed a lot faster … >
[Message part 2 (text/html, inline)]
bug-gnu-emacs <at> gnu.org:bug#21666; Package emacs.
(Tue, 15 Mar 2016 03:38:01 GMT) Full text and rfc822 format available.Message #107 received at 21666 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Jorgen Schäfer <jorgen.schaefer <at> gmail.com> Cc: 21666 <at> debbugs.gnu.org Subject: Re: bug#21666: Backtrace Date: Tue, 15 Mar 2016 05:36:28 +0200
> From: Jorgen Schäfer <jorgen.schaefer <at> gmail.com> > Date: Mon, 14 Mar 2016 22:19:32 +0000 > > Ignore this, I'm just not awake enough. Forgot handle SIGINT nostop noprint pass, so that's just C-g. Meh. :-( If you start GDB from the Emacs src directory, the .gdbinit file there will do this for you, I think.
bug-gnu-emacs <at> gnu.org:bug#21666; Package emacs.
(Tue, 12 Jun 2018 23:02:03 GMT) Full text and rfc822 format available.Message #110 received at 21666 <at> debbugs.gnu.org (full text, mbox):
From: Noam Postavsky <npostavs <at> gmail.com> To: Jorgen Schäfer <jorgen.schaefer <at> gmail.com> Cc: "21666 <at> debbugs.gnu.org" <21666 <at> debbugs.gnu.org> Subject: Re: bug#21666: 25.0.50; Random segfaults Date: Tue, 12 Jun 2018 19:01:27 -0400
Jorgen Schäfer <jorgen.schaefer <at> gmail.com> writes: > Sorry to kill the good news – it took a while longer, but my Emacs just > crashed with a segfault, so I'm afraid emacs-25 is still affected by this > problem. There were some serious segfaulting problems fixed after 25.1; I'm wondering if you still see this in 25.3 or 26.1?
bug-gnu-emacs <at> gnu.org:bug#21666; Package emacs.
(Wed, 13 Jun 2018 07:54:02 GMT) Full text and rfc822 format available.Message #113 received at 21666 <at> debbugs.gnu.org (full text, mbox):
From: Jorgen Schäfer <jorgen.schaefer <at> gmail.com> To: Noam Postavsky <npostavs <at> gmail.com> Cc: "21666 <at> debbugs.gnu.org" <21666 <at> debbugs.gnu.org> Subject: Re: bug#21666: 25.0.50; Random segfaults Date: Wed, 13 Jun 2018 09:52:47 +0200
[Message part 1 (text/plain, inline)]
Hello and thanks for the update! I have not experienced any segfaults in a long time, so this can be closed as far as I am concerned. Thank you! Jorgen On Wed, Jun 13, 2018 at 1:01 AM Noam Postavsky <npostavs <at> gmail.com> wrote: > Jorgen Schäfer <jorgen.schaefer <at> gmail.com> writes: > > > Sorry to kill the good news – it took a while longer, but my Emacs just > > crashed with a segfault, so I'm afraid emacs-25 is still affected by this > > problem. > > There were some serious segfaulting problems fixed after 25.1; I'm > wondering if you still see this in 25.3 or 26.1? > >
[Message part 2 (text/html, inline)]
bug-gnu-emacs <at> gnu.org:bug#21666; Package emacs.
(Wed, 13 Jun 2018 10:32:01 GMT) Full text and rfc822 format available.Message #116 received at 21666 <at> debbugs.gnu.org (full text, mbox):
From: Noam Postavsky <npostavs <at> gmail.com> To: Jorgen Schäfer <jorgen.schaefer <at> gmail.com> Cc: "21666 <at> debbugs.gnu.org" <21666 <at> debbugs.gnu.org> Subject: Re: bug#21666: 25.0.50; Random segfaults Date: Wed, 13 Jun 2018 06:31:24 -0400
tags 21666 fixed close 21666 quit Jorgen Schäfer <jorgen.schaefer <at> gmail.com> writes: > I have not experienced any segfaults in a long time, Cool, that's good news. > so this can be closed as far as I am concerned. Done.
Noam Postavsky <npostavs <at> gmail.com>
to control <at> debbugs.gnu.org.
(Wed, 13 Jun 2018 10:32:02 GMT) Full text and rfc822 format available.Noam Postavsky <npostavs <at> gmail.com>
to control <at> debbugs.gnu.org.
(Wed, 13 Jun 2018 10:32:02 GMT) Full text and rfc822 format available.Debbugs Internal Request <help-debbugs <at> gnu.org>
to internal_control <at> debbugs.gnu.org.
(Wed, 11 Jul 2018 11:24:05 GMT) Full text and rfc822 format available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.