* bug#12544: -r110296..110297 causes random crashes in optimized build on Windows
@ 2012-10-01 1:36 Juanma Barranquero
2012-10-01 7:31 ` Fabrice Popineau
` (2 more replies)
0 siblings, 3 replies; 14+ messages in thread
From: Juanma Barranquero @ 2012-10-01 1:36 UTC (permalink / raw)
To: 12544; +Cc: fabrice.popineau
Version: 24.2.50
Package: emacs
Severity: important
X-Debbugs-CC: eliz@gnu.org
X-Debbugs-CC: fabrice.popineau@supelec.fr
Compiling current trunk on Windows with optimization gives me an unusable exe.
Compiler: MinGW GCC 4.6.2
Compilation options: -march=core2 -fno-omit-frame-pointer -O2
It either crashes immediately upon starting, or displays an error,
usually "Wrong type argument, lisp <some number>".
The crashes disappear if I remove revnos 110296 and 110297.
In one case, I got "Wrong type argument: listp, #<EMACS BUG: INVALID
DATATYPE (PVEC 0x5f000100) Save your buffers immediately and please
report this bug>", followed by this crash:
Program received signal SIGSEGV, Segmentation fault.
0x0100eeb8 in mark_vectorlike (ptr=0x3003030) at alloc.c:5492
5492 VECTOR_MARK (ptr); /* Else mark it. */
(gdb) bt
#0 0x0100eeb8 in mark_vectorlike (ptr=0x3003030) at alloc.c:5492
#1 0x0100fbca in mark_maybe_object (obj=61397630) at alloc.c:4216
#2 mark_memory (end=0x88f1f8, start=0x88fef0) at alloc.c:4380
#3 mark_stack () at alloc.c:4617
#4 Fgarbage_collect () at alloc.c:5201
#5 0x01014649 in maybe_gc () at lisp.h:3672
#6 Ffuncall (nargs=3, args=0x88f2a4) at eval.c:2723
#7 0x010998eb in exec_byte_code (bytestr=-553647872, vector=8975012,
maxdepth=50343989, args_template=57538586, nargs=0, args=0x388bd80)
at bytecode.c:899
#8 0x0101425d in funcall_lambda (fun=20055197, nargs=4,
arg_vector=0x88f42c) at eval.c:3004
#9 0x010145fb in Ffuncall (nargs=5, args=0x88f428) at eval.c:2833
#10 0x010998eb in exec_byte_code (bytestr=-553647872, vector=8975400,
maxdepth=50343989, args_template=57538586, nargs=0, args=0x0)
at bytecode.c:899
#11 0x0101425d in funcall_lambda (fun=20055685, nargs=3,
arg_vector=0x88f5a8) at eval.c:3004
#12 0x010145fb in Ffuncall (nargs=4, args=0x88f5a4) at eval.c:2833
#13 0x010998eb in exec_byte_code (bytestr=-553647872, vector=8975780,
maxdepth=50343989, args_template=57538586, nargs=0, args=0x88f5ac)
at bytecode.c:899
#14 0x0101425d in funcall_lambda (fun=20058285, nargs=1,
arg_vector=0x88f72c) at eval.c:3004
#15 0x010145fb in Ffuncall (nargs=2, args=0x88f728) at eval.c:2833
#16 0x01014ca5 in call1 (fn=57580834, arg1=61212581) at eval.c:2566
#17 0x0105ef48 in timer_check_2 (idle_timers=<optimized out>,
timers=<optimized out>) at keyboard.c:4427
#18 timer_check () at keyboard.c:4494
#19 0x0105f2f5 in readable_events (flags=1) at keyboard.c:3388
#20 0x01061237 in get_input_pending (flags=1, addr=0x1550940) at keyboard.c:6718
#21 0x010657e7 in detect_input_pending_run_timers (do_display=1) at
keyboard.c:10310
#22 0x0101d849 in wait_reading_process_output (time_limit=<optimized
out>, nsecs=0, read_kbd=-1, do_display=1, wait_for_cell=57538586,
wait_proc=0x0, just_wait_proc=0) at process.c:4760
#23 0x01066550 in kbd_buffer_get_event (end_time=0x0,
used_mouse_menu=0x88fbd8, kbp=<synthetic pointer>) at keyboard.c:3843
#24 read_char (commandflag=1, nmaps=2, maps=0x88fae0,
prev_event=57538586, used_mouse_menu=0x88fbd8, end_time=0x0) at
keyboard.c:2791
#25 0x0106977b in read_key_sequence (keybuf=0x88fc48, prompt=57538586,
dont_downcase_last=0, can_return_switch_frame=1, fix_current_buffer=1,
bufsize=30) at keyboard.c:9265
#26 0x0106bfe2 in command_loop_1 () at keyboard.c:1474
#27 0x0101288b in internal_condition_case (bfun=0x106bdd0
<command_loop_1>, handlers=57589170, hfun=0x105e490 <cmd_error>) at
eval.c:1288
#28 0x0105c84d in command_loop_2 (ignore=57538586) at keyboard.c:1179
#29 0x010127c8 in internal_catch (tag=57579026, func=0x105c820
<command_loop_2>, arg=57538586) at eval.c:1059
#30 0x0105de7a in command_loop () at keyboard.c:1158
#31 recursive_edit_1 () at keyboard.c:779
#32 0x0105e1da in Frecursive_edit () at keyboard.c:843
#33 0x012432f9 in main (argc=<optimized out>, argv=0xd92ec8) at emacs.c:1525
Lisp Backtrace:
"Automatic GC" (0x154fb7c)
"time-add" (0x88f2a8)
"timer-relative-time" (0x88f42c)
"timer-inc-time" (0x88f5a8)
"timer-event-handler" (0x88f72c)
(gdb)
In a debug build, with NO optimizations and no special compilation
options (no -march) except the ones related to debugging, I get also
problems but much less frequently. Bootstrapping crashed twice while
bytecompiling some files, and also while dumping. Restarting the build
process finished dumping correctly and the resulting exe apparently
does not crash.
A few more backtraces (from the optimized build):
Program received signal SIGSEGV, Segmentation fault.
0x012129ff in traverse_intervals (tree=0x5f474944, position=0,
function=0x1094150 <print_check_string_charset_prop>, arg=50344505)
at intervals.c:264
264 traverse_intervals (tree->left, position, function, arg);
(gdb) bt
#0 0x012129ff in traverse_intervals (tree=0x5f474944, position=0,
function=0x1094150 <print_check_string_charset_prop>, arg=50344505)
at intervals.c:264
#1 0x0109515a in print_prune_string_charset (string=50344505) at print.c:1295
#2 print_object (obj=50344505, printcharfun=57538586, escapeflag=1)
at print.c:1404
#3 0x01095826 in print_object (obj=61404422, printcharfun=57538586,
escapeflag=1) at print.c:1669
#4 0x0109813a in Fprin1_to_string (object=61404406,
noescape=57538586) at print.c:603
#5 0x0104969b in Fformat (nargs=3, args=0x88e5a4) at editfns.c:3815
#6 0x0111b8f2 in add_to_log (format=0x147169c "Error during
redisplay: %S signaled %S", arg1=61404390, arg2=61404406) at
xdisp.c:9302
#7 0x0111ba6f in safe_eval_handler (arg=61404406, nargs=2,
args=0x88e6b0) at xdisp.c:2424
#8 0x01012b5a in internal_condition_case_n (bfun=0x1014440
<Ffuncall>, nargs=2, args=0x88e6b0, handlers=57538610,
hfun=0x111ba40 <safe_eval_handler>) at eval.c:1402
#9 0x01119369 in safe_call (nargs=2, func=57641754) at xdisp.c:2459
#10 0x011193b0 in safe_call1 (fn=57641754, arg=59220198) at xdisp.c:2475
#11 0x0111964a in safe_eval (sexpr=59220198) at xdisp.c:2483
#12 0x011258f1 in display_mode_element (it=0x88ea84, depth=6,
field_width=0, precision=-8, elt=59220206, props=59219854, risky=0) at
xdisp.c:20762
#13 0x011259bd in display_mode_element (it=0x88ea84, depth=5,
field_width=0, precision=-8, elt=59219894, props=59219854, risky=0) at
xdisp.c:20843
#14 0x011258bb in display_mode_element (it=0x88ea84, depth=4,
field_width=0, precision=-8, elt=59219838, props=57538586, risky=0) at
xdisp.c:20777
#15 0x011259bd in display_mode_element (it=0x88ea84, depth=3,
field_width=0, precision=-8, elt=59219822, props=57538586, risky=0) at
xdisp.c:20843
#16 0x011259bd in display_mode_element (it=0x88ea84, depth=1,
field_width=0, precision=0, elt=59320366, props=57538586, risky=0) at
xdisp.c:20843
#17 0x0112b9c3 in display_mode_line (w=<optimized out>,
face_id=MODE_LINE_FACE_ID, format=59320390) at xdisp.c:20360
#18 0x0112bcd9 in display_mode_lines (w=0x37e62c0) at xdisp.c:20306
#19 0x0112c038 in redisplay_mode_lines (window=<optimized out>,
force=0) at xdisp.c:20265
#20 0x011334ee in echo_area_display (update_frame_p=1) at xdisp.c:10802
#21 0x0113375a in message3_nolog (m=59765329, nbytes=65, multibyte=0)
at xdisp.c:9701
#22 0x01133a5a in message3 (m=59765329, nbytes=65, multibyte=0) at xdisp.c:9638
#23 0x0104a602 in Fmessage (nargs=2, args=0x88f5b8) at editfns.c:3465
#24 0x0101497d in Ffuncall (nargs=3, args=0x88f5b4) at eval.c:2753
#25 0x010998eb in exec_byte_code (bytestr=17383760, vector=8975796,
maxdepth=1, args_template=0, nargs=0, args=0x0) at bytecode.c:899
#26 0x010142b9 in funcall_lambda (fun=19572773, nargs=0,
arg_vector=0x88f73c) at eval.c:2938
#27 0x010145fb in Ffuncall (nargs=1, args=0x88f738) at eval.c:2833
#28 0x010998eb in exec_byte_code (bytestr=17383760, vector=8976184,
maxdepth=1, args_template=1028, nargs=1, args=0x36df81a) at
bytecode.c:899
#29 0x010142b9 in funcall_lambda (fun=19573749, nargs=1,
arg_vector=0x88f8f8) at eval.c:2938
#30 0x010145fb in Ffuncall (nargs=2, args=0x88f8f4) at eval.c:2833
#31 0x010998eb in exec_byte_code (bytestr=17383760, vector=8976628,
maxdepth=1, args_template=0, nargs=0, args=0x36ec430) at
bytecode.c:899
#32 0x010142b9 in funcall_lambda (fun=19552197, nargs=0,
arg_vector=0x88faac) at eval.c:2938
#33 0x010145fb in Ffuncall (nargs=1, args=0x88faa8) at eval.c:2833
#34 0x010998eb in exec_byte_code (bytestr=17383760, vector=8977064,
maxdepth=1, args_template=0, nargs=0, args=0x88faa8) at bytecode.c:899
#35 0x010142b9 in funcall_lambda (fun=19550069, nargs=0,
arg_vector=0x88fbc0) at eval.c:2938
#36 0x01013236 in apply_lambda (fun=19550069, args=<optimized out>) at
eval.c:2881
#37 0x010134dd in eval_sub (form=59221734) at eval.c:2212
#38 0x010163c2 in Feval (form=59221734, lexical=57538586) at eval.c:2002
#39 0x0105c6ac in top_level_2 () at keyboard.c:1188
#40 0x0101288b in internal_condition_case (bfun=0x105c690
<top_level_2>, handlers=57589170, hfun=0x105e490 <cmd_error>) at
eval.c:1288
#41 0x0105cad0 in top_level_1 (ignore=57538586) at keyboard.c:1196
#42 0x010127c8 in internal_catch (tag=57579026, func=0x105ca70
<top_level_1>, arg=57538586) at eval.c:1059
#43 0x0105de5c in command_loop () at keyboard.c:1151
#44 recursive_edit_1 () at keyboard.c:779
#45 0x0105e1da in Frecursive_edit () at keyboard.c:843
#46 0x012432f9 in main (argc=<optimized out>, argv=0x972ec8) at emacs.c:1525
Lisp Backtrace:
"message" (0x88f5b8)
"display-startup-echo-area-message" (0x88f73c)
"command-line-1" (0x88f8f8)
"command-line" (0x88faac)
"normal-top-level" (0x88fbc0)
(gdb)
Program received signal SIGSEGV, Segmentation fault.
0x0100e290 in mark_object (arg=61397630) at alloc.c:5924
5924 FLOAT_MARK (XFLOAT (obj));
(gdb) bt
#0 0x0100e290 in mark_object (arg=61397630) at alloc.c:5924
#1 0x0100fbca in mark_maybe_object (obj=61397630) at alloc.c:4216
#2 mark_memory (end=0x88f378, start=0x88fef0) at alloc.c:4380
#3 mark_stack () at alloc.c:4617
#4 Fgarbage_collect () at alloc.c:5201
#5 0x01014649 in maybe_gc () at lisp.h:3672
#6 Ffuncall (nargs=2, args=0x88f424) at eval.c:2723
#7 0x010998eb in exec_byte_code (bytestr=64, vector=8975396,
maxdepth=6, args_template=57538586, nargs=0, args=0x0) at
bytecode.c:899
#8 0x0101425d in funcall_lambda (fun=20055685, nargs=3,
arg_vector=0x88f5a8) at eval.c:3004
#9 0x010145fb in Ffuncall (nargs=4, args=0x88f5a4) at eval.c:2833
#10 0x010998eb in exec_byte_code (bytestr=64, vector=8975780,
maxdepth=6, args_template=57538586, nargs=0, args=0x88f5ac) at
bytecode.c:899
#11 0x0101425d in funcall_lambda (fun=20058285, nargs=1,
arg_vector=0x88f72c) at eval.c:3004
#12 0x010145fb in Ffuncall (nargs=2, args=0x88f728) at eval.c:2833
#13 0x01014ca5 in call1 (fn=57580834, arg1=61192101) at eval.c:2566
#14 0x0105ef48 in timer_check_2 (idle_timers=<optimized out>,
timers=<optimized out>) at keyboard.c:4427
#15 timer_check () at keyboard.c:4494
#16 0x0105f2f5 in readable_events (flags=1) at keyboard.c:3388
#17 0x01061237 in get_input_pending (flags=1, addr=0x1550940) at keyboard.c:6718
#18 0x010657e7 in detect_input_pending_run_timers (do_display=1) at
keyboard.c:10310
#19 0x0101d849 in wait_reading_process_output (time_limit=<optimized
out>, nsecs=0, read_kbd=-1, do_display=1, wait_for_cell=57538586,
wait_proc=0x0, just_wait_proc=0) at process.c:4760
#20 0x01066550 in kbd_buffer_get_event (end_time=0x0,
used_mouse_menu=0x88fbd8, kbp=<synthetic pointer>) at keyboard.c:3843
#21 read_char (commandflag=1, nmaps=2, maps=0x88fae0,
prev_event=57538586, used_mouse_menu=0x88fbd8, end_time=0x0) at
keyboard.c:2791
#22 0x0106977b in read_key_sequence (keybuf=0x88fc48, prompt=57538586,
dont_downcase_last=0, can_return_switch_frame=1, fix_current_buffer=1,
bufsize=30) at keyboard.c:9265
#23 0x0106bfe2 in command_loop_1 () at keyboard.c:1474
#24 0x0101288b in internal_condition_case (bfun=0x106bdd0
<command_loop_1>, handlers=57589170, hfun=0x105e490 <cmd_error>) at
eval.c:1288
#25 0x0105c84d in command_loop_2 (ignore=57538586) at keyboard.c:1179
#26 0x010127c8 in internal_catch (tag=57579026, func=0x105c820
<command_loop_2>, arg=57538586) at eval.c:1059
#27 0x0105de7a in command_loop () at keyboard.c:1158
#28 recursive_edit_1 () at keyboard.c:779
#29 0x0105e1da in Frecursive_edit () at keyboard.c:843
#30 0x012432f9 in main (argc=<optimized out>, argv=0xd82ec8) at emacs.c:1525
Lisp Backtrace:
"Automatic GC" (0x154fb7c)
"timerp" (0x88f428)
"timer-inc-time" (0x88f5a8)
"timer-event-handler" (0x88f72c)
(gdb)
Program received signal SIGSEGV, Segmentation fault.
0x012129ff in traverse_intervals (tree=0x5f474944, position=0,
function=0x1094150 <print_check_string_charset_prop>, arg=50344505)
at intervals.c:264
264 traverse_intervals (tree->left, position, function, arg);
(gdb) bt
#0 0x012129ff in traverse_intervals (tree=0x5f474944, position=0,
function=0x1094150 <print_check_string_charset_prop>, arg=50344505)
at intervals.c:264
#1 0x0109515a in print_prune_string_charset (string=50344505) at print.c:1295
#2 print_object (obj=50344505, printcharfun=57538610, escapeflag=1)
at print.c:1404
#3 0x010987ac in Fprin1 (object=50344505, printcharfun=57538610) at print.c:560
#4 0x01098d3f in print_error_message (data=<optimized out>,
stream=57538610, context=0x88fca7 "", caller=59742426) at print.c:915
#5 0x0105e419 in cmd_error_internal (data=61397630, context=0x88fca7
"") at keyboard.c:1124
#6 0x0105e55e in cmd_error (data=61397630) at keyboard.c:1055
#7 0x010128ac in internal_condition_case (bfun=0x105c690
<top_level_2>, handlers=57589170, hfun=0x105e490 <cmd_error>) at
eval.c:1278
#8 0x0105cad0 in top_level_1 (ignore=57538586) at keyboard.c:1196
#9 0x010127c8 in internal_catch (tag=57579026, func=0x105ca70
<top_level_1>, arg=57538586) at eval.c:1059
#10 0x0105de5c in command_loop () at keyboard.c:1151
#11 recursive_edit_1 () at keyboard.c:779
#12 0x0105e1da in Frecursive_edit () at keyboard.c:843
#13 0x012432f9 in main (argc=<optimized out>, argv=0x982ec8) at emacs.c:1525
(gdb)
print.c:1511: Emacs fatal error: assertion failed: STRINGP (((((((enum
Lisp_Type) (((obj)) & TYPEMASK)) == Lisp_Symbol)) || suppress_checking
? (void)
0 : die ("assertion failed: " "SYMBOLP (obj)", "print.c", 1511)),
(struct Lisp_Symbol *) ((intptr_t) ((obj) - (Lisp_Symbol))))->name)
Breakpoint 1, terminate_due_to_signal (sig=22,
backtrace_limit=2147483647) at emacs.c:292
292 {
(gdb) bt
#0 terminate_due_to_signal (sig=22, backtrace_limit=2147483647) at emacs.c:292
#1 0x0100a527 in die (
msg=0x145e14c "assertion failed: STRINGP (((((((enum Lisp_Type)
(((obj)) & TYPEMASK)) == Lisp_Symbol)) || suppress_checking ? (void) 0
: die (\"as
sertion failed: \" \"SYMBOLP (obj)\", \"print.c\", 1511)), (struct
Lisp_Sym"..., file=0x145d864 "print.c", line=1511) at alloc.c:6445
#2 0x01097105 in print_object (obj=<optimized out>,
printcharfun=57538586, escapeflag=1) at print.c:1511
#3 0x01095826 in print_object (obj=61404422, printcharfun=57538586,
escapeflag=1) at print.c:1669
#4 0x0109813a in Fprin1_to_string (object=61404406,
noescape=57538586) at print.c:603
#5 0x0104969b in Fformat (nargs=3, args=0x88e5a4) at editfns.c:3815
#6 0x0111b8f2 in add_to_log (format=0x147169c "Error during
redisplay: %S signaled %S", arg1=61404390, arg2=61404406) at
xdisp.c:9302
#7 0x0111ba6f in safe_eval_handler (arg=61404406, nargs=2,
args=0x88e6b0) at xdisp.c:2424
#8 0x01012b5a in internal_condition_case_n (bfun=0x1014440
<Ffuncall>, nargs=2, args=0x88e6b0, handlers=57538610,
hfun=0x111ba40 <safe_eval_handler>) at eval.c:1402
#9 0x01119369 in safe_call (nargs=2, func=57641754) at xdisp.c:2459
#10 0x011193b0 in safe_call1 (fn=57641754, arg=59220198) at xdisp.c:2475
#11 0x0111964a in safe_eval (sexpr=59220198) at xdisp.c:2483
#12 0x011258f1 in display_mode_element (it=0x88ea84, depth=6,
field_width=0, precision=-8, elt=59220206, props=59219854, risky=0) at
xdisp.c:20762
#13 0x011259bd in display_mode_element (it=0x88ea84, depth=5,
field_width=0, precision=-8, elt=59219894, props=59219854, risky=0) at
xdisp.c:20843
#14 0x011258bb in display_mode_element (it=0x88ea84, depth=4,
field_width=0, precision=-8, elt=59219838, props=57538586, risky=0) at
xdisp.c:20777
#15 0x011259bd in display_mode_element (it=0x88ea84, depth=3,
field_width=0, precision=-8, elt=59219822, props=57538586, risky=0) at
xdisp.c:20843
#16 0x011259bd in display_mode_element (it=0x88ea84, depth=1,
field_width=0, precision=0, elt=59320366, props=57538586, risky=0) at
xdisp.c:20843
#17 0x0112b9c3 in display_mode_line (w=<optimized out>,
face_id=MODE_LINE_FACE_ID, format=59320390) at xdisp.c:20360
#18 0x0112bcd9 in display_mode_lines (w=0x37e62c0) at xdisp.c:20306
#19 0x0112c038 in redisplay_mode_lines (window=<optimized out>,
force=0) at xdisp.c:20265
#20 0x011334ee in echo_area_display (update_frame_p=1) at xdisp.c:10802
#21 0x0113375a in message3_nolog (m=59765329, nbytes=65, multibyte=0)
at xdisp.c:9701
#22 0x01133a5a in message3 (m=59765329, nbytes=65, multibyte=0) at xdisp.c:9638
#23 0x0104a602 in Fmessage (nargs=2, args=0x88f5b8) at editfns.c:3465
#24 0x0101497d in Ffuncall (nargs=3, args=0x88f5b4) at eval.c:2753
#25 0x010998eb in exec_byte_code (bytestr=288, vector=8975796,
maxdepth=1979596570, args_template=0, nargs=0, args=0x0) at
bytecode.c:899
#26 0x010142b9 in funcall_lambda (fun=19572773, nargs=0,
arg_vector=0x88f73c) at eval.c:2938
#27 0x010145fb in Ffuncall (nargs=1, args=0x88f738) at eval.c:2833
#28 0x010998eb in exec_byte_code (bytestr=288, vector=8976184,
maxdepth=1979596570, args_template=1028, nargs=1, args=0x36df81a) at
bytecode.c:899
#29 0x010142b9 in funcall_lambda (fun=19573749, nargs=1,
arg_vector=0x88f8f8) at eval.c:2938
#30 0x010145fb in Ffuncall (nargs=2, args=0x88f8f4) at eval.c:2833
#31 0x010998eb in exec_byte_code (bytestr=288, vector=8976628,
maxdepth=1979596570, args_template=0, nargs=0, args=0x36ec430) at
bytecode.c:899
#32 0x010142b9 in funcall_lambda (fun=19552197, nargs=0,
arg_vector=0x88faac) at eval.c:2938
#33 0x010145fb in Ffuncall (nargs=1, args=0x88faa8) at eval.c:2833
#34 0x010998eb in exec_byte_code (bytestr=288, vector=8977064,
maxdepth=1979596570, args_template=0, nargs=0, args=0x88faa8) at
bytecode.c:899
#35 0x010142b9 in funcall_lambda (fun=19550069, nargs=0,
arg_vector=0x88fbc0) at eval.c:2938
#36 0x01013236 in apply_lambda (fun=19550069, args=<optimized out>) at
eval.c:2881
#37 0x010134dd in eval_sub (form=59221734) at eval.c:2212
#38 0x010163c2 in Feval (form=59221734, lexical=57538586) at eval.c:2002
#39 0x0105c6ac in top_level_2 () at keyboard.c:1188
#40 0x0101288b in internal_condition_case (bfun=0x105c690
<top_level_2>, handlers=57589170, hfun=0x105e490 <cmd_error>) at
eval.c:1288
#41 0x0105cad0 in top_level_1 (ignore=57538586) at keyboard.c:1196
#42 0x010127c8 in internal_catch (tag=57579026, func=0x105ca70
<top_level_1>, arg=57538586) at eval.c:1059
#43 0x0105de5c in command_loop () at keyboard.c:1151
#44 recursive_edit_1 () at keyboard.c:779
#45 0x0105e1da in Frecursive_edit () at keyboard.c:843
#46 0x012432f9 in main (argc=<optimized out>, argv=0xc62ec8) at emacs.c:1525
Lisp Backtrace:
"message" (0x88f5b8)
"display-startup-echo-area-message" (0x88f73c)
"command-line-1" (0x88f8f8)
"command-line" (0x88faac)
"normal-top-level" (0x88fbc0)
(gdb)
^ permalink raw reply [flat|nested] 14+ messages in thread* bug#12544: -r110296..110297 causes random crashes in optimized build on Windows
2012-10-01 1:36 bug#12544: -r110296..110297 causes random crashes in optimized build on Windows Juanma Barranquero
@ 2012-10-01 7:31 ` Fabrice Popineau
2012-10-01 8:12 ` Eli Zaretskii
2012-10-01 8:37 ` Eli Zaretskii
2012-10-01 11:41 ` Eli Zaretskii
2 siblings, 1 reply; 14+ messages in thread
From: Fabrice Popineau @ 2012-10-01 7:31 UTC (permalink / raw)
To: Juanma Barranquero; +Cc: 12544
[-- Attachment #1: Type: text/plain, Size: 4851 bytes --]
I don't know if it is related or not, but I get a few crashes too when
doing a bootstrap and
while compiling some .el files. An example of a backtrace is :
And the crash occurs after a
EnterCriticalSection(crit)
instruction.
I have the same behaviour with both 32bits and 64bits exe.
Fabrice
ntdll.dll!RtlDeNormalizeProcessParams() + 0x5a4 bytes
[Frames below may be incorrect and/or missing, no symbols loaded for
ntdll.dll]
ntdll.dll!RtlDeNormalizeProcessParams() + 0x4cb bytes
> emacs.exe!setitimer(int which, itimerval * value, itimerval * ovalue)
Line 642 C
emacs.exe!set_alarm() Line 326 C
emacs.exe!do_pending_atimers() Line 397 C
emacs.exe!totally_unblock_input() Line 7168 C
emacs.exe!terminate_due_to_signal(int sig, int backtrace_limit) Line 297
C
emacs.exe!deliver_fatal_thread_signal(int sig) Line 1570 + 0x12 bytes C
msvcr100.dll!_XcptFilter() + 0x1ad bytes
emacs.exe!__tmainCRTStartup$filt$0() Line 572 + 0x16 bytes C
msvcr100.dll!__C_specific_handler() + 0x97 bytes
ntdll.dll!RtlDecodePointer() + 0xbd bytes
ntdll.dll!RtlUnwindEx() + 0xbbf bytes
ntdll.dll!KiUserExceptionDispatcher() + 0x2e bytes
ntdll.dll!RtlDeNormalizeProcessParams() + 0x5a4 bytes
ntdll.dll!RtlDeNormalizeProcessParams() + 0x4cb bytes
emacs.exe!setitimer(int which, itimerval * value, itimerval * ovalue)
Line 642 C
emacs.exe!set_alarm() Line 326 C
emacs.exe!do_pending_atimers() Line 397 C
emacs.exe!unblock_input() Line 7159 C
emacs.exe!check_glyph_memory() Line 2335 C
emacs.exe!Fkill_emacs(__int64 arg) Line 1832 + 0x8a bytes C
emacs.exe!Ffuncall(__int64 nargs, __int64 * args) Line 2773 C
emacs.exe!exec_byte_code(__int64 bytestr, __int64 vector, __int64
maxdepth, __int64 args_template, __int64 nargs, __int64 * args) Line 899 +
0xf bytes C
emacs.exe!funcall_lambda(__int64 fun, __int64 nargs, __int64 *
arg_vector) Line 3011 C
emacs.exe!Ffuncall(__int64 nargs, __int64 * args) Line 2844 C
emacs.exe!exec_byte_code(__int64 bytestr, __int64 vector, __int64
maxdepth, __int64 args_template, __int64 nargs, __int64 * args) Line 899 +
0xf bytes C
emacs.exe!funcall_lambda(__int64 fun, __int64 nargs, __int64 *
arg_vector) Line 3011 C
emacs.exe!Ffuncall(__int64 nargs, __int64 * args) Line 2844 C
emacs.exe!eval_sub(__int64 form) Line 2111 C
emacs.exe!Fif(__int64 args) Line 310 + 0x2d bytes C
emacs.exe!eval_sub(__int64 form) Line 2085 + 0x6 bytes C
emacs.exe!Fcond(__int64 args) Line 337 + 0x15 bytes C
emacs.exe!eval_sub(__int64 form) Line 2085 + 0x6 bytes C
emacs.exe!FletX(__int64 args) Line 843 + 0x25 bytes C
emacs.exe!eval_sub(__int64 form) Line 2085 + 0x6 bytes C
emacs.exe!Fwhile(__int64 args) Line 935 + 0x15 bytes C
emacs.exe!eval_sub(__int64 form) Line 2085 + 0x6 bytes C
emacs.exe!Flet(__int64 args) Line 913 + 0x2d bytes C
emacs.exe!eval_sub(__int64 form) Line 2085 + 0x6 bytes C
emacs.exe!Fprogn(__int64 args) Line 360 C
emacs.exe!eval_sub(__int64 form) Line 2085 + 0x6 bytes C
emacs.exe!eval_sub(__int64 form) Line 2085 + 0x6 bytes C
emacs.exe!Flet(__int64 args) Line 913 + 0x2d bytes C
emacs.exe!eval_sub(__int64 form) Line 2085 + 0x6 bytes C
emacs.exe!Fprogn(__int64 args) Line 360 C
emacs.exe!funcall_lambda(__int64 fun, __int64 nargs, __int64 *
arg_vector) Line 2998 C
emacs.exe!apply_lambda(__int64 fun, __int64 args) Line 2884 C
emacs.exe!eval_sub(__int64 form) Line 2212 + 0xc bytes C
emacs.exe!Fprogn(__int64 args) Line 360 C
emacs.exe!funcall_lambda(__int64 fun, __int64 nargs, __int64 *
arg_vector) Line 2998 C
emacs.exe!apply_lambda(__int64 fun, __int64 args) Line 2884 C
emacs.exe!eval_sub(__int64 form) Line 2212 + 0xc bytes C
emacs.exe!Funwind_protect(__int64 args) Line 1148 C
emacs.exe!eval_sub(__int64 form) Line 2085 + 0x6 bytes C
emacs.exe!Flet(__int64 args) Line 913 + 0x2d bytes C
emacs.exe!eval_sub(__int64 form) Line 2085 + 0x6 bytes C
emacs.exe!Fif(__int64 args) Line 310 + 0x2d bytes C
emacs.exe!eval_sub(__int64 form) Line 2085 + 0x6 bytes C
emacs.exe!Fprogn(__int64 args) Line 360 C
emacs.exe!funcall_lambda(__int64 fun, __int64 nargs, __int64 *
arg_vector) Line 2998 C
emacs.exe!apply_lambda(__int64 fun, __int64 args) Line 2884 C
emacs.exe!eval_sub(__int64 form) Line 2212 + 0xc bytes C
emacs.exe!Feval(__int64 form, __int64 lexical) Line 2002 + 0x8 bytes C
emacs.exe!internal_condition_case(__int64 (void)* bfun, __int64 handlers,
__int64 (__int64)* hfun) Line 1289 C
emacs.exe!top_level_1(__int64 ignore) Line 1201 C
emacs.exe!internal_catch(__int64 tag, __int64 (__int64)* func, __int64
arg) Line 1059 + 0x9 bytes C
emacs.exe!command_loop() Line 1158 C
emacs.exe!recursive_edit_1() Line 780 C
emacs.exe!Frecursive_edit() Line 844 C
emacs.exe!main(int argc, char * * argv) Line 1525 + 0x5 bytes C
[-- Attachment #2: Type: text/html, Size: 12186 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#12544: -r110296..110297 causes random crashes in optimized build on Windows
2012-10-01 7:31 ` Fabrice Popineau
@ 2012-10-01 8:12 ` Eli Zaretskii
2012-10-01 9:34 ` Eli Zaretskii
0 siblings, 1 reply; 14+ messages in thread
From: Eli Zaretskii @ 2012-10-01 8:12 UTC (permalink / raw)
To: Fabrice Popineau; +Cc: lekktu, 12544
> From: Fabrice Popineau <fabrice.popineau@supelec.fr>
> Date: Mon, 1 Oct 2012 09:31:14 +0200
> Cc: 12544@debbugs.gnu.org
>
> I don't know if it is related or not, but I get a few crashes too when
> doing a bootstrap and
> while compiling some .el files. An example of a backtrace is :
> And the crash occurs after a
>
> EnterCriticalSection(crit)
>
> instruction.
> I have the same behaviour with both 32bits and 64bits exe.
The backtrace looks completely different from what Juanma shows in his
crashes, FWIW.
> ntdll.dll!RtlDeNormalizeProcessParams() + 0x5a4 bytes
> [Frames below may be incorrect and/or missing, no symbols loaded for
> ntdll.dll]
> ntdll.dll!RtlDeNormalizeProcessParams() + 0x4cb bytes
> > emacs.exe!setitimer(int which, itimerval * value, itimerval * ovalue)
> Line 642 C
> emacs.exe!set_alarm() Line 326 C
> emacs.exe!do_pending_atimers() Line 397 C
> emacs.exe!totally_unblock_input() Line 7168 C
> emacs.exe!terminate_due_to_signal(int sig, int backtrace_limit) Line 297
> C
> emacs.exe!deliver_fatal_thread_signal(int sig) Line 1570 + 0x12 bytes C
> msvcr100.dll!_XcptFilter() + 0x1ad bytes
> emacs.exe!__tmainCRTStartup$filt$0() Line 572 + 0x16 bytes C
> msvcr100.dll!__C_specific_handler() + 0x97 bytes
> ntdll.dll!RtlDecodePointer() + 0xbd bytes
> ntdll.dll!RtlUnwindEx() + 0xbbf bytes
> ntdll.dll!KiUserExceptionDispatcher() + 0x2e bytes
> ntdll.dll!RtlDeNormalizeProcessParams() + 0x5a4 bytes
> ntdll.dll!RtlDeNormalizeProcessParams() + 0x4cb bytes
> emacs.exe!setitimer(int which, itimerval * value, itimerval * ovalue)
> Line 642 C
> emacs.exe!set_alarm() Line 326 C
IIUC, setitimer is being called recursively here, is that right? It
looks like some exception happened on line 642 of w32proc.c, that
exception got caught by the (SIGSEGV, I presume) signal handler, and
terminate_due_to_signal was called, which again called setitimer
through totally_unblock_input. setitimer is certainly not ready to be
called recursively, and that recursion happens inside a critical
section, which is even worse.
Fabrice, can you see what is wrong with the first call to setitimer?
What kind of exception is that, and why does it happen?
Anyway, this all happens when Emacs exits:
> emacs.exe!do_pending_atimers() Line 397 C
> emacs.exe!unblock_input() Line 7159 C
> emacs.exe!check_glyph_memory() Line 2335 C
> emacs.exe!Fkill_emacs(__int64 arg) Line 1832 + 0x8a bytes C
> emacs.exe!Ffuncall(__int64 nargs, __int64 * args) Line 2773 C
So it's probably some problem with shutting down Emacs, I guess some
cleanup code I added needs some work. Fabrice, can you see if the
problem goes away if you comment out the 3 lines in term_timers that
delete the critical sections?
Also, what does the timer thread do when this crash happens? is it at
all alive?
FWIW, I see none of this on my system.
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#12544: -r110296..110297 causes random crashes in optimized build on Windows
2012-10-01 8:12 ` Eli Zaretskii
@ 2012-10-01 9:34 ` Eli Zaretskii
2012-10-01 11:32 ` Fabrice Popineau
0 siblings, 1 reply; 14+ messages in thread
From: Eli Zaretskii @ 2012-10-01 9:34 UTC (permalink / raw)
To: fabrice.popineau; +Cc: lekktu, 12544
> Date: Mon, 01 Oct 2012 10:12:45 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: lekktu@gmail.com, 12544@debbugs.gnu.org
>
> > From: Fabrice Popineau <fabrice.popineau@supelec.fr>
> > Date: Mon, 1 Oct 2012 09:31:14 +0200
> > Cc: 12544@debbugs.gnu.org
> >
> > I don't know if it is related or not, but I get a few crashes too when
> > doing a bootstrap and
> > while compiling some .el files. An example of a backtrace is :
> > And the crash occurs after a
> >
> > EnterCriticalSection(crit)
> >
> > instruction.
> > I have the same behaviour with both 32bits and 64bits exe.
>
> The backtrace looks completely different from what Juanma shows in his
> crashes, FWIW.
>
> > ntdll.dll!RtlDeNormalizeProcessParams() + 0x5a4 bytes
> > [Frames below may be incorrect and/or missing, no symbols loaded for
> > ntdll.dll]
> > ntdll.dll!RtlDeNormalizeProcessParams() + 0x4cb bytes
> > > emacs.exe!setitimer(int which, itimerval * value, itimerval * ovalue)
> > Line 642 C
> > emacs.exe!set_alarm() Line 326 C
> > emacs.exe!do_pending_atimers() Line 397 C
> > emacs.exe!totally_unblock_input() Line 7168 C
> > emacs.exe!terminate_due_to_signal(int sig, int backtrace_limit) Line 297
> > C
> > emacs.exe!deliver_fatal_thread_signal(int sig) Line 1570 + 0x12 bytes C
> > msvcr100.dll!_XcptFilter() + 0x1ad bytes
> > emacs.exe!__tmainCRTStartup$filt$0() Line 572 + 0x16 bytes C
> > msvcr100.dll!__C_specific_handler() + 0x97 bytes
> > ntdll.dll!RtlDecodePointer() + 0xbd bytes
> > ntdll.dll!RtlUnwindEx() + 0xbbf bytes
> > ntdll.dll!KiUserExceptionDispatcher() + 0x2e bytes
> > ntdll.dll!RtlDeNormalizeProcessParams() + 0x5a4 bytes
> > ntdll.dll!RtlDeNormalizeProcessParams() + 0x4cb bytes
> > emacs.exe!setitimer(int which, itimerval * value, itimerval * ovalue)
> > Line 642 C
> > emacs.exe!set_alarm() Line 326 C
>
> IIUC, setitimer is being called recursively here, is that right? It
> looks like some exception happened on line 642 of w32proc.c, that
> exception got caught by the (SIGSEGV, I presume) signal handler, and
> terminate_due_to_signal was called, which again called setitimer
> through totally_unblock_input. setitimer is certainly not ready to be
> called recursively, and that recursion happens inside a critical
> section, which is even worse.
>
> Fabrice, can you see what is wrong with the first call to setitimer?
> What kind of exception is that, and why does it happen?
>
> Anyway, this all happens when Emacs exits:
>
> > emacs.exe!do_pending_atimers() Line 397 C
> > emacs.exe!unblock_input() Line 7159 C
> > emacs.exe!check_glyph_memory() Line 2335 C
> > emacs.exe!Fkill_emacs(__int64 arg) Line 1832 + 0x8a bytes C
> > emacs.exe!Ffuncall(__int64 nargs, __int64 * args) Line 2773 C
>
> So it's probably some problem with shutting down Emacs, I guess some
> cleanup code I added needs some work. Fabrice, can you see if the
> problem goes away if you comment out the 3 lines in term_timers that
> delete the critical sections?
I think I fixed this in trunk revision 110318. The problem was that
the call to term_ntproc, as part of shutting down Emacs, deleted the
critical sections used by the timer threads and by setitimer, so any
call to setitimer after that would use an invalid critical section
object. I now make sure any calls to setitimer after deleting the
critical sections will return immediately without doing anything.
Juanma, please see if your crashes still persist. I don't expect them
to disappear, but who knows...
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#12544: -r110296..110297 causes random crashes in optimized build on Windows
2012-10-01 9:34 ` Eli Zaretskii
@ 2012-10-01 11:32 ` Fabrice Popineau
2012-10-01 11:41 ` Eli Zaretskii
0 siblings, 1 reply; 14+ messages in thread
From: Fabrice Popineau @ 2012-10-01 11:32 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: lekktu, 12544
[-- Attachment #1: Type: text/plain, Size: 561 bytes --]
> I think I fixed this in trunk revision 110318. The problem was that
> the call to term_ntproc, as part of shutting down Emacs, deleted the
> critical sections used by the timer threads and by setitimer, so any
> call to setitimer after that would use an invalid critical section
> object. I now make sure any calls to setitimer after deleting the
> critical sections will return immediately without doing anything.
>
>
The explanation seems fine. The experimentation too : I did a bootstrap
(64bits full optimization). It ran smoothly.
Great job.
Fabrice
[-- Attachment #2: Type: text/html, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#12544: -r110296..110297 causes random crashes in optimized build on Windows
2012-10-01 11:32 ` Fabrice Popineau
@ 2012-10-01 11:41 ` Eli Zaretskii
0 siblings, 0 replies; 14+ messages in thread
From: Eli Zaretskii @ 2012-10-01 11:41 UTC (permalink / raw)
To: Fabrice Popineau; +Cc: lekktu, 12544
> From: Fabrice Popineau <fabrice.popineau@supelec.fr>
> Date: Mon, 1 Oct 2012 13:32:13 +0200
> Cc: lekktu@gmail.com, 12544@debbugs.gnu.org
>
> > I think I fixed this in trunk revision 110318. The problem was that
> > the call to term_ntproc, as part of shutting down Emacs, deleted the
> > critical sections used by the timer threads and by setitimer, so any
> > call to setitimer after that would use an invalid critical section
> > object. I now make sure any calls to setitimer after deleting the
> > critical sections will return immediately without doing anything.
> >
> >
> The explanation seems fine. The experimentation too : I did a bootstrap
> (64bits full optimization). It ran smoothly.
Great, thanks for testing.
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#12544: -r110296..110297 causes random crashes in optimized build on Windows
2012-10-01 1:36 bug#12544: -r110296..110297 causes random crashes in optimized build on Windows Juanma Barranquero
2012-10-01 7:31 ` Fabrice Popineau
@ 2012-10-01 8:37 ` Eli Zaretskii
2012-10-01 9:47 ` Eli Zaretskii
2012-10-01 11:45 ` Juanma Barranquero
2012-10-01 11:41 ` Eli Zaretskii
2 siblings, 2 replies; 14+ messages in thread
From: Eli Zaretskii @ 2012-10-01 8:37 UTC (permalink / raw)
To: Juanma Barranquero; +Cc: 12544, fabrice.popineau
> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Mon, 1 Oct 2012 03:36:39 +0200
> Cc: fabrice.popineau@supelec.fr
>
> Compiling current trunk on Windows with optimization gives me an unusable exe.
Sorry about that. The looming feature freeze deadline and the flood
of commits it triggered surely didn't facilitate careful testing of
each changeset before committing.
> Compiler: MinGW GCC 4.6.2
> Compilation options: -march=core2 -fno-omit-frame-pointer -O2
>
> It either crashes immediately upon starting, or displays an error,
> usually "Wrong type argument, lisp <some number>".
I've just bootstrapped today's trunk with an optimized build and saw
no problems at all. Not one. Of course, I use an ancient version of
GCC. Also, this is a 32-bit Windows XP, while both you and Fabrice
probably run a 64-bit Windows 7. But still, this means the bugs are
probably very subtle, or even OS version-dependent.
First, do you still see problems if you build with the default
optimization flags, those set by running 'configure' without any
"--cflags" options except those required to pick up your include
directories and image libraries? In my case, a typical compilation
command line looks like this:
gcc -I. -c -gdwarf-2 -g3 -mtune=pentium4 -O2 -Id:/usr/include/libxml2 -Demacs=1 -I../lib -I../nt/inc -DHAVE_NTGUI=1 -DUSE_CRT_DLL=1 -o oo-spd/i386/gmalloc.o gmalloc.c
IOW, the only GCC switches pertinent to optimizations are
-gdwarf-2 -g3 -mtune=pentium4 -O2
What happens if you build Emacs like this?
> The crashes disappear if I remove revnos 110296 and 110297.
To be absolutely sure the crashes have nothing to do with the timers
introduced in revision 110287, can you please try this:
. comment out the line that defines HAVE_SETITIMER in nt/config.nt
. ifdef away the entire body of 'alarm' (in w32proc.c), except its
last line, which returns to the caller the value of its argument
. build Emacs and see if the crashes go away
> In one case, I got "Wrong type argument: listp, #<EMACS BUG: INVALID
> DATATYPE (PVEC 0x5f000100) Save your buffers immediately and please
> report this bug>", followed by this crash:
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x0100eeb8 in mark_vectorlike (ptr=0x3003030) at alloc.c:5492
> 5492 VECTOR_MARK (ptr); /* Else mark it. */
> (gdb) bt
> #0 0x0100eeb8 in mark_vectorlike (ptr=0x3003030) at alloc.c:5492
> #1 0x0100fbca in mark_maybe_object (obj=61397630) at alloc.c:4216
Can you show backtrace from the other threads, whenever you see a
crash? I'm specifically interested in the timer thread, it should be
running the timer_loop function. Is that thread perhaps in the same
place when the crash happens?
> In a debug build, with NO optimizations and no special compilation
> options (no -march) except the ones related to debugging, I get also
> problems but much less frequently. Bootstrapping crashed twice while
> bytecompiling some files, and also while dumping. Restarting the build
> process finished dumping correctly and the resulting exe apparently
> does not crash.
Can you try obtaining backtraces from those crashes of an unoptimized
build?
> A few more backtraces (from the optimized build):
>
> #5 0x0104969b in Fformat (nargs=3, args=0x88e5a4) at editfns.c:3815
> #6 0x0111b8f2 in add_to_log (format=0x147169c "Error during
> redisplay: %S signaled %S", arg1=61404390, arg2=61404406) at
> xdisp.c:9302
> #7 0x0111ba6f in safe_eval_handler (arg=61404406, nargs=2,
> args=0x88e6b0) at xdisp.c:2424
> #8 0x01012b5a in internal_condition_case_n (bfun=0x1014440
> <Ffuncall>, nargs=2, args=0x88e6b0, handlers=57538610,
> hfun=0x111ba40 <safe_eval_handler>) at eval.c:1402
> #9 0x01119369 in safe_call (nargs=2, func=57641754) at xdisp.c:2459
> #10 0x011193b0 in safe_call1 (fn=57641754, arg=59220198) at xdisp.c:2475
> #11 0x0111964a in safe_eval (sexpr=59220198) at xdisp.c:2483
> #12 0x011258f1 in display_mode_element (it=0x88ea84, depth=6,
> field_width=0, precision=-8, elt=59220206, props=59219854, risky=0) at
> xdisp.c:20762
This is the display engine trying to report some error that happened
during display of the mode line. Can you show the values of arg1 and
arg2 in frame #6, which is a call to add_to_log?
> Program received signal SIGSEGV, Segmentation fault.
> 0x012129ff in traverse_intervals (tree=0x5f474944, position=0,
> function=0x1094150 <print_check_string_charset_prop>, arg=50344505)
> at intervals.c:264
> 264 traverse_intervals (tree->left, position, function, arg);
> (gdb) bt
> #0 0x012129ff in traverse_intervals (tree=0x5f474944, position=0,
> function=0x1094150 <print_check_string_charset_prop>, arg=50344505)
> at intervals.c:264
> #1 0x0109515a in print_prune_string_charset (string=50344505) at print.c:1295
> #2 print_object (obj=50344505, printcharfun=57538610, escapeflag=1)
> at print.c:1404
> #3 0x010987ac in Fprin1 (object=50344505, printcharfun=57538610) at print.c:560
> #4 0x01098d3f in print_error_message (data=<optimized out>,
> stream=57538610, context=0x88fca7 "", caller=59742426) at print.c:915
> #5 0x0105e419 in cmd_error_internal (data=61397630, context=0x88fca7
> "") at keyboard.c:1124
> #6 0x0105e55e in cmd_error (data=61397630) at keyboard.c:1055
> #7 0x010128ac in internal_condition_case (bfun=0x105c690
> <top_level_2>, handlers=57589170, hfun=0x105e490 <cmd_error>) at
> eval.c:1278
> #8 0x0105cad0 in top_level_1 (ignore=57538586) at keyboard.c:1196
> #9 0x010127c8 in internal_catch (tag=57579026, func=0x105ca70
> <top_level_1>, arg=57538586) at eval.c:1059
> #10 0x0105de5c in command_loop () at keyboard.c:1151
> #11 recursive_edit_1 () at keyboard.c:779
> #12 0x0105e1da in Frecursive_edit () at keyboard.c:843
> #13 0x012432f9 in main (argc=<optimized out>, argv=0x982ec8) at emacs.c:1525
Here, too, some error happened, and cmd_error is called to report it.
Can you show the value of 'data' in frame #6?
Please note that it is not safe to use 'pp' to display Lisp data
structures in a session badly crashed such as these. You will have to
fall back on 'xtype' and 'xFOO' commands instead, let me know if you
need guidance in using them.
> #1 0x0100a527 in die (
> msg=0x145e14c "assertion failed: STRINGP (((((((enum Lisp_Type)
> (((obj)) & TYPEMASK)) == Lisp_Symbol)) || suppress_checking ? (void) 0
> : die (\"as
> sertion failed: \" \"SYMBOLP (obj)\", \"print.c\", 1511)), (struct
> Lisp_Sym"..., file=0x145d864 "print.c", line=1511) at alloc.c:6445
> #2 0x01097105 in print_object (obj=<optimized out>,
> printcharfun=57538586, escapeflag=1) at print.c:1511
> #3 0x01095826 in print_object (obj=61404422, printcharfun=57538586,
> escapeflag=1) at print.c:1669
> #4 0x0109813a in Fprin1_to_string (object=61404406,
> noescape=57538586) at print.c:603
> #5 0x0104969b in Fformat (nargs=3, args=0x88e5a4) at editfns.c:3815
> #6 0x0111b8f2 in add_to_log (format=0x147169c "Error during
> redisplay: %S signaled %S", arg1=61404390, arg2=61404406) at
> xdisp.c:9302
> #7 0x0111ba6f in safe_eval_handler (arg=61404406, nargs=2,
> args=0x88e6b0) at xdisp.c:2424
> #8 0x01012b5a in internal_condition_case_n (bfun=0x1014440
> <Ffuncall>, nargs=2, args=0x88e6b0, handlers=57538610,
> hfun=0x111ba40 <safe_eval_handler>) at eval.c:1402
> #9 0x01119369 in safe_call (nargs=2, func=57641754) at xdisp.c:2459
> #10 0x011193b0 in safe_call1 (fn=57641754, arg=59220198) at xdisp.c:2475
> #11 0x0111964a in safe_eval (sexpr=59220198) at xdisp.c:2483
> #12 0x011258f1 in display_mode_element (it=0x88ea84, depth=6,
> field_width=0, precision=-8, elt=59220206, props=59219854, risky=0) at
> xdisp.c:20762
Again, a crash during display of mode line, triggered by some error in
redisplay. Can you show arg1 and arg2 in frame #6?
^ permalink raw reply [flat|nested] 14+ messages in thread* bug#12544: -r110296..110297 causes random crashes in optimized build on Windows
2012-10-01 8:37 ` Eli Zaretskii
@ 2012-10-01 9:47 ` Eli Zaretskii
2012-10-01 11:45 ` Juanma Barranquero
1 sibling, 0 replies; 14+ messages in thread
From: Eli Zaretskii @ 2012-10-01 9:47 UTC (permalink / raw)
To: lekktu; +Cc: 12544, fabrice.popineau
> Date: Mon, 01 Oct 2012 10:37:08 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 12544@debbugs.gnu.org, fabrice.popineau@supelec.fr
>
> To be absolutely sure the crashes have nothing to do with the timers
> introduced in revision 110287, can you please try this:
>
> . comment out the line that defines HAVE_SETITIMER in nt/config.nt
> . ifdef away the entire body of 'alarm' (in w32proc.c), except its
> last line, which returns to the caller the value of its argument
> . build Emacs and see if the crashes go away
Actually, with the trunk post-r110319, the second bullet is
unnecessary.
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#12544: -r110296..110297 causes random crashes in optimized build on Windows
2012-10-01 8:37 ` Eli Zaretskii
2012-10-01 9:47 ` Eli Zaretskii
@ 2012-10-01 11:45 ` Juanma Barranquero
2012-10-01 12:30 ` Eli Zaretskii
1 sibling, 1 reply; 14+ messages in thread
From: Juanma Barranquero @ 2012-10-01 11:45 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 12544, fabrice.popineau
On Mon, Oct 1, 2012 at 10:37 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> Sorry about that. The looming feature freeze deadline and the flood
> of commits it triggered surely didn't facilitate careful testing of
> each changeset before committing.
No need to apologize. That's what testing is for.
> Also, this is a 32-bit Windows XP, while both you and Fabrice
> probably run a 64-bit Windows 7.
Yes.
> To be absolutely sure the crashes have nothing to do with the timers
> introduced in revision 110287, can you please try this:
Before reporting I tried reverting the timers change, but it still crashed.
> I made a few cleanup changes of the r110296 commit. I don't expect
> them to fix the problems reported by Juanma, but please do try
> repeating your crash recipes after updating.
Well, I do not get any crash after revno:110320, at least after
recompilation. I'm going to bootstrap now and I'll report back.
Juanma
^ permalink raw reply [flat|nested] 14+ messages in thread* bug#12544: -r110296..110297 causes random crashes in optimized build on Windows
2012-10-01 11:45 ` Juanma Barranquero
@ 2012-10-01 12:30 ` Eli Zaretskii
2012-10-01 14:28 ` Juanma Barranquero
0 siblings, 1 reply; 14+ messages in thread
From: Eli Zaretskii @ 2012-10-01 12:30 UTC (permalink / raw)
To: Juanma Barranquero; +Cc: 12544, fabrice.popineau
> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Mon, 1 Oct 2012 13:45:17 +0200
> Cc: 12544@debbugs.gnu.org, fabrice.popineau@supelec.fr
>
> > I made a few cleanup changes of the r110296 commit. I don't expect
> > them to fix the problems reported by Juanma, but please do try
> > repeating your crash recipes after updating.
>
> Well, I do not get any crash after revno:110320, at least after
> recompilation. I'm going to bootstrap now and I'll report back.
Amazing. Holding fingers...
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#12544: -r110296..110297 causes random crashes in optimized build on Windows
2012-10-01 12:30 ` Eli Zaretskii
@ 2012-10-01 14:28 ` Juanma Barranquero
2012-10-01 14:52 ` Eli Zaretskii
0 siblings, 1 reply; 14+ messages in thread
From: Juanma Barranquero @ 2012-10-01 14:28 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 12544, fabrice.popineau
On Mon, Oct 1, 2012 at 2:30 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> Amazing. Holding fingers...
Both the optimized and the debug build bootstrapped and run just fine.
No crash in sight.
I think we can close this one.
Juanma
^ permalink raw reply [flat|nested] 14+ messages in thread* bug#12544: -r110296..110297 causes random crashes in optimized build on Windows
2012-10-01 14:28 ` Juanma Barranquero
@ 2012-10-01 14:52 ` Eli Zaretskii
2012-10-01 14:58 ` Fabrice Popineau
0 siblings, 1 reply; 14+ messages in thread
From: Eli Zaretskii @ 2012-10-01 14:52 UTC (permalink / raw)
To: Juanma Barranquero; +Cc: 12544-done, fabrice.popineau
> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Mon, 1 Oct 2012 16:28:16 +0200
> Cc: 12544@debbugs.gnu.org, fabrice.popineau@supelec.fr
>
> On Mon, Oct 1, 2012 at 2:30 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>
> > Amazing. Holding fingers...
>
> Both the optimized and the debug build bootstrapped and run just fine.
> No crash in sight.
>
> I think we can close this one.
Fhew! A large stone just dropped off my heart. Thanks for testing.
This then appears totally my fault, as all the changes I made in
revision 110320 were to correct where I deviated from Fabrice's
original submission. I guess my mind is not too clear after 11PM, not
in my age.
Closing.
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#12544: -r110296..110297 causes random crashes in optimized build on Windows
2012-10-01 14:52 ` Eli Zaretskii
@ 2012-10-01 14:58 ` Fabrice Popineau
0 siblings, 0 replies; 14+ messages in thread
From: Fabrice Popineau @ 2012-10-01 14:58 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Juanma Barranquero, 12544-done
[-- Attachment #1: Type: text/plain, Size: 1191 bytes --]
Hey ... you did a great job by commiting all this stuff in such a short
time.
Especially the patches I sent you where not that clear at all.
So a big thank you.
Fabrice
2012/10/1 Eli Zaretskii <eliz@gnu.org>
> > From: Juanma Barranquero <lekktu@gmail.com>
> > Date: Mon, 1 Oct 2012 16:28:16 +0200
> > Cc: 12544@debbugs.gnu.org, fabrice.popineau@supelec.fr
> >
> > On Mon, Oct 1, 2012 at 2:30 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> >
> > > Amazing. Holding fingers...
> >
> > Both the optimized and the debug build bootstrapped and run just fine.
> > No crash in sight.
> >
> > I think we can close this one.
>
> Fhew! A large stone just dropped off my heart. Thanks for testing.
>
> This then appears totally my fault, as all the changes I made in
> revision 110320 were to correct where I deviated from Fabrice's
> original submission. I guess my mind is not too clear after 11PM, not
> in my age.
>
> Closing.
>
--
Fabrice Popineau
-----------------------------
SUPELEC
Département Informatique
3, rue Joliot Curie
91192 Gif/Yvette Cedex
Tel direct : +33 (0) 169851950
Standard : +33 (0) 169851212
------------------------------
[-- Attachment #2: Type: text/html, Size: 1907 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#12544: -r110296..110297 causes random crashes in optimized build on Windows
2012-10-01 1:36 bug#12544: -r110296..110297 causes random crashes in optimized build on Windows Juanma Barranquero
2012-10-01 7:31 ` Fabrice Popineau
2012-10-01 8:37 ` Eli Zaretskii
@ 2012-10-01 11:41 ` Eli Zaretskii
2 siblings, 0 replies; 14+ messages in thread
From: Eli Zaretskii @ 2012-10-01 11:41 UTC (permalink / raw)
To: Juanma Barranquero; +Cc: 12544, fabrice.popineau
I made a few cleanup changes of the r110296 commit. I don't expect
them to fix the problems reported by Juanma, but please do try
repeating your crash recipes after updating.
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2012-10-01 14:58 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-10-01 1:36 bug#12544: -r110296..110297 causes random crashes in optimized build on Windows Juanma Barranquero
2012-10-01 7:31 ` Fabrice Popineau
2012-10-01 8:12 ` Eli Zaretskii
2012-10-01 9:34 ` Eli Zaretskii
2012-10-01 11:32 ` Fabrice Popineau
2012-10-01 11:41 ` Eli Zaretskii
2012-10-01 8:37 ` Eli Zaretskii
2012-10-01 9:47 ` Eli Zaretskii
2012-10-01 11:45 ` Juanma Barranquero
2012-10-01 12:30 ` Eli Zaretskii
2012-10-01 14:28 ` Juanma Barranquero
2012-10-01 14:52 ` Eli Zaretskii
2012-10-01 14:58 ` Fabrice Popineau
2012-10-01 11:41 ` Eli Zaretskii
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.