From unknown Sun Jun 15 08:17:39 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#12544 <12544@debbugs.gnu.org> To: bug#12544 <12544@debbugs.gnu.org> Subject: Status: -r110296..110297 causes random crashes in optimized build on Windows Reply-To: bug#12544 <12544@debbugs.gnu.org> Date: Sun, 15 Jun 2025 15:17:39 +0000 retitle 12544 -r110296..110297 causes random crashes in optimized build on = Windows reassign 12544 emacs submitter 12544 Juanma Barranquero severity 12544 important thanks From debbugs-submit-bounces@debbugs.gnu.org Sun Sep 30 21:38:00 2012 Received: (at submit) by debbugs.gnu.org; 1 Oct 2012 01:38:00 +0000 Received: from localhost ([127.0.0.1]:35195 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TIUxK-0005ay-Rz for submit@debbugs.gnu.org; Sun, 30 Sep 2012 21:38:00 -0400 Received: from eggs.gnu.org ([208.118.235.92]:37929) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TIUxG-0005an-1H for submit@debbugs.gnu.org; Sun, 30 Sep 2012 21:37:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TIUwp-0003ZB-Kf for submit@debbugs.gnu.org; Sun, 30 Sep 2012 21:37:30 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM, RCVD_IN_DNSWL_HI,T_DKIM_INVALID autolearn=unavailable version=3.3.2 Received: from lists.gnu.org ([208.118.235.17]:60031) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TIUwp-0003Z7-H7 for submit@debbugs.gnu.org; Sun, 30 Sep 2012 21:37:27 -0400 Received: from eggs.gnu.org ([208.118.235.92]:56909) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TIUwm-0000sG-U2 for bug-gnu-emacs@gnu.org; Sun, 30 Sep 2012 21:37:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TIUwk-0003Yv-6D for bug-gnu-emacs@gnu.org; Sun, 30 Sep 2012 21:37:24 -0400 Received: from mail-we0-f169.google.com ([74.125.82.169]:65156) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TIUwj-0003Yp-QI for bug-gnu-emacs@gnu.org; Sun, 30 Sep 2012 21:37:22 -0400 Received: by weyu3 with SMTP id u3so2843726wey.0 for ; Sun, 30 Sep 2012 18:37:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=VV4LsTSvuZsvv+SZ5+LQQG+I20LOST883exUUdEZBxY=; b=CUu6/Hev7ZcWSkpMpbnTRuFCjFMnsUdkRAXCFQQsfiV9F0lDZlv3yct7jDfohb1mO+ NdVKUL5QkfXEFyoee9tyMMnQ17Q80gxLR2d7nz+AMVcrevjv8ODKihN0hfjnOF6Los+/ zkRiXUVpp4kQ30zztzragaKO6braeFRtZTnT2P5b1vsLpm237RY+pKjs/Vdwh4uu3zHW jTbPdZpRL71d3qVnCVigZrHnY6UdTjZqwrbzJ3tPkwGW25uJ/XpQyof7XQyNXRn5yU76 9rQqOb/pI/TWday5rH+ylEj+58OTIrdvB8Uu2nQrLeDU797depAlgmcX8tzDU2AZ57TB zxSw== Received: by 10.180.91.71 with SMTP id cc7mr11121228wib.2.1349055440203; Sun, 30 Sep 2012 18:37:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.155.132 with HTTP; Sun, 30 Sep 2012 18:36:39 -0700 (PDT) From: Juanma Barranquero Date: Mon, 1 Oct 2012 03:36:39 +0200 Message-ID: Subject: -r110296..110297 causes random crashes in optimized build on Windows To: Bug-Gnu-Emacs Content-Type: text/plain; charset=UTF-8 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 208.118.235.17 X-Spam-Score: -4.3 (----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -4.3 (----) 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 ". The crashes disappear if I remove revnos 110296 and 110297. In one case, I got "Wrong type argument: listp, #", 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=, timers=) 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=, 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=) 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 , handlers=57589170, hfun=0x105e490 ) 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 , 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=, 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 , 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 , 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 , nargs=2, args=0x88e6b0, handlers=57538610, hfun=0x111ba40 ) 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=, 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=, 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=) 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 , handlers=57589170, hfun=0x105e490 ) 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 , 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=, 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=, timers=) 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=, 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=) 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 , handlers=57589170, hfun=0x105e490 ) 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 , 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=, 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 , 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 , 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=, 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 , handlers=57589170, hfun=0x105e490 ) 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 , 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=, 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=, 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 , nargs=2, args=0x88e6b0, handlers=57538610, hfun=0x111ba40 ) 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=, 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=, 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=) 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 , handlers=57589170, hfun=0x105e490 ) 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 , 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=, 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) From debbugs-submit-bounces@debbugs.gnu.org Mon Oct 01 03:32:04 2012 Received: (at 12544) by debbugs.gnu.org; 1 Oct 2012 07:32:04 +0000 Received: from localhost ([127.0.0.1]:35495 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TIaTz-00073F-7D for submit@debbugs.gnu.org; Mon, 01 Oct 2012 03:32:04 -0400 Received: from mail-wi0-f174.google.com ([209.85.212.174]:45853) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TIaTw-00072q-Cf for 12544@debbugs.gnu.org; Mon, 01 Oct 2012 03:32:01 -0400 Received: by mail-wi0-f174.google.com with SMTP id hq7so1769367wib.15 for <12544@debbugs.gnu.org>; Mon, 01 Oct 2012 00:31:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=ZMFSe7e+X0YuQuMRa+2ZAzdWCSow5yR+5sljXHqr57k=; b=UDkG36p5fPGffUVzntwh2BHRXnP8O8g1lihXcQSm0CWPaPBbyaRWT/iQNFkyejG19P UL3q7vF57E99QnZiDs4/fdEyPxkRrFdijrUTiG5b0GU+NWJbc/xyej4W2HS3E+g6XB+5 4EDKCSgOlO8DqsvGRrUJeUacoDnZ6T9WMKoLtABfs7HGe3kDolLmIt0vQeHlN+w8bQy/ Iu8tXTTOU6hCWi6kHPGmnJxXEfMDh7uTLCTO6o2Z6boc9wG08zEfQqjeOLvUkvX7NFdO BXzdt2Pn0PkrqCclH7oQlsRBRRXbICNX59CDpxMNFvWCXXe+Yw2uP07AgZIimWJ8iPb8 jFwg== Received: by 10.180.104.200 with SMTP id gg8mr12590551wib.14.1349076694184; Mon, 01 Oct 2012 00:31:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.26.162 with HTTP; Mon, 1 Oct 2012 00:31:14 -0700 (PDT) In-Reply-To: References: From: Fabrice Popineau Date: Mon, 1 Oct 2012 09:31:14 +0200 X-Google-Sender-Auth: DoACOLpL4HY0BAKZSwAqLGb8gGE Message-ID: Subject: Re: bug#12544: -r110296..110297 causes random crashes in optimized build on Windows To: Juanma Barranquero Content-Type: multipart/alternative; boundary=f46d0443040421b3bd04cafa65a1 X-Spam-Score: 1.6 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: 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) [...] Content analysis details: (1.6 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (fabrice.popineau[at]gmail.com) -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [209.85.212.174 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record 0.0 HTML_MESSAGE BODY: HTML included in message 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid 2.3 MANY_SPAN_IN_TEXT Many tags embedded within text X-Debbugs-Envelope-To: 12544 Cc: 12544@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -0.7 (/) --f46d0443040421b3bd04cafa65a1 Content-Type: text/plain; charset=ISO-8859-1 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 --f46d0443040421b3bd04cafa65a1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 b= acktrace is :
And the crash occurs after a

EnterCriticalSection(crit)

instruction.
=
I have the same behaviour with both 32bits and 64bits exe.
<= br>
Fabrice

=A0 ntdll.dll!RtlDeNormalizeProcessParams() =A0+ 0x5a4= bytes
=A0 [Frames below may be i= ncorrect and/or missing, no symbols loaded for ntdll.dll]
=A0 ntdll.dll!RtlDeNormalizeProcessParams() =A0+ 0x4cb bytes
> emacs.exe!setitimer(i= nt which, itimerval * value, itimerval * ovalue) =A0Line 642 C
=A0 emacs.exe!set_alarm() =A0Li= ne 326 C
=A0 emacs.exe!do_pending_atimers() =A0Line = 397 C
=A0 emacs.exe!totally_unbl= ock_input() =A0Line 7168 C
=A0 emacs.exe!terminate_d= ue_to_signal(int sig, int backtrace_limit) =A0Line 297 C
=A0 emacs.exe!deliver_fata= l_thread_signal(int sig) =A0Line 1570 + 0x12 bytes C
=A0 msvcr100.dll!_XcptFilter() =A0+ 0x1ad bytes
=A0 emacs.exe!__tmainCRTSt= artup$filt$0() =A0Line 572 + 0x16 bytes C
=A0 msvcr1= 00.dll!__C_specific_handler() =A0+ 0x97 bytes
=A0 ntdll.dll!RtlDecodePoi= nter() =A0+ 0xbd bytes
=A0 ntdll.dll!RtlUnwindEx() = =A0+ 0xbbf bytes
=A0 ntdll.dll!KiUserExcept= ionDispatcher() =A0+ 0x2e bytes
=A0 ntdll.dll!RtlDe= NormalizeProcessParams() =A0+ 0x5a4 bytes
=A0 ntdll.dll!RtlDeNormali= zeProcessParams() =A0+ 0x4cb bytes
=A0 emacs.exe!se= titimer(int which, itimerval * value, itimerval * ovalue) =A0Line 642 C
=A0 emacs.exe!set_alarm() = =A0Line 326 C
=A0 emacs.exe!do_pending_atimers() =A0= Line 397 C
=A0 emacs.exe!unblock_inpu= t() =A0Line 7159 C
= =A0 emacs.exe!check_glyph_memor= y() =A0Line 2335 C
=A0 emacs.exe!Fkill_emacs(= __int64 arg) =A0Line 1832 + 0x8a bytes= C
=A0 emacs.e= xe!Ffuncall(__int64 nargs, __int64 * args) =A0Line 2773 C
=A0 emacs.exe!exec_byte_co= de(__int64 bytestr, __int64 vector, __int64 maxdepth, __int64 args_template= , __int64 nargs, __int64 * args) =A0Line 899 + 0xf bytes C
=A0 emacs.exe!funcall_lamb= da(__int64 fun, __int64 nargs, __int64 * arg_vector) =A0Line 3011 C
=A0 emacs.exe!Ffuncall(__int64 = nargs, __int64 * args) =A0Line 2844 C
=A0 emacs.exe!= exec_byte_code(__int64 bytestr, __int64 vector, __int64 maxdepth, __int64 a= rgs_template, __int64 nargs, __int64 * args) =A0Line 899 + 0xf bytes C
=A0 emacs.exe!funcall_lamb= da(__int64 fun, __int64 nargs, __int64 * arg_vector) =A0Line 3011 C
=A0 emacs.exe!Ffuncall(__int64 = nargs, __int64 * args) =A0Line 2844 C
=A0 emacs.exe!= eval_sub(__int64 form) =A0Line 2111 C
=A0 emacs.exe!Fif(__int64 = args) =A0Line 310 + 0x2d bytes = C
=A0 emacs.exe!eval_= sub(__int64 form) =A0Line 2085 + 0x6 bytes C
=A0 emacs.exe!Fcond(__int6= 4 args) =A0Line 337 + 0x15 bytes C
=A0 emacs.exe!eva= l_sub(__int64 form) =A0Line 2085 + 0x6 bytes C
=A0 emacs.exe!FletX(__int6= 4 args) =A0Line 843 + 0x25 bytes C
=A0 emacs.exe!eva= l_sub(__int64 form) =A0Line 2085 + 0x6 bytes C
=A0 emacs.exe!Fwhile(__int= 64 args) =A0Line 935 + 0x15 bytes C
=A0 emacs.exe!ev= al_sub(__int64 form) =A0Line 2085 + 0x6 bytes C
=A0 emacs.exe!Flet(__int64= args) =A0Line 913 + 0x2d bytes C
=A0 emacs.exe!eval= _sub(__int64 form) =A0Line 2085 + 0x6 bytes C
=A0 emacs.exe!Fprogn(__int= 64 args) =A0Line 360 C
=A0 emacs.exe!eval_sub(__int6= 4 form) =A0Line 2085 + 0x6 bytes C
=A0 emacs.exe!eval_sub(__i= nt64 form) =A0Line 2085 + 0x6 bytes C
=A0 emacs.exe!= Flet(__int64 args) =A0Line 913 + 0x2d bytes C
=A0 emacs.exe!eval_sub(__i= nt64 form) =A0Line 2085 + 0x6 bytes C
=A0 emacs.exe!= Fprogn(__int64 args) =A0Line 360 C
=A0 emacs.exe!funcall_lamb= da(__int64 fun, __int64 nargs, __int64 * arg_vector) =A0Line 2998 C
=A0 emacs.exe!apply_lambda(__in= t64 fun, __int64 args) =A0Line 2884 C
=A0 emacs.exe!= eval_sub(__int64 form) =A0Line 2212 + 0xc bytes C
=A0 emacs.exe!Fprogn(__int= 64 args) =A0Line 360 C
=A0 emacs.exe!funcall_lambda(= __int64 fun, __int64 nargs, __int64 * arg_vector) =A0Line 2998 C
=A0 emacs.exe!apply_lambda= (__int64 fun, __int64 args) =A0Line 2884 C
=A0 emacs= .exe!eval_sub(__int64 form) =A0Line 2212 + 0xc bytes C
=A0 emacs.exe!Funwind_prot= ect(__int64 args) =A0Line 1148 = C
=A0 emacs.exe!eval_= sub(__int64 form) =A0Line 2085 + 0x6 bytes C
=A0 emacs.exe!Flet(__int64= args) =A0Line 913 + 0x2d bytes C
=A0 emacs.exe!eval= _sub(__int64 form) =A0Line 2085 + 0x6 bytes C
=A0 emacs.exe!Fif(__int64 = args) =A0Line 310 + 0x2d bytes = C
=A0 emacs.exe!eval_= sub(__int64 form) =A0Line 2085 + 0x6 bytes C
=A0 emacs.exe!Fprogn(__int= 64 args) =A0Line 360 C
=A0 emacs.exe!funcall_lambda(= __int64 fun, __int64 nargs, __int64 * arg_vector) =A0Line 2998 C
=A0 emacs.exe!apply_lambda= (__int64 fun, __int64 args) =A0Line 2884 C
=A0 emacs= .exe!eval_sub(__int64 form) =A0Line 2212 + 0xc bytes C
=A0 emacs.exe!Feval(__int6= 4 form, __int64 lexical) =A0Line 2002 + 0x8 bytes C
=A0 emacs.exe!internal_condition_case(__int64 (void)* bfun, __int64 handler= s, __int64 (__int64)* hfun) =A0Line 1289 C
=A0 emacs.exe!top_level_1(= __int64 ignore) =A0Line 1201 C<= /div>
=A0 emacs.exe!interna= l_catch(__int64 tag, __int64 (__int64)* func, __int64 arg) =A0Line 1059 + 0= x9 bytes C
=A0 emacs.exe!command_loop= () =A0Line 1158 C
=A0= emacs.exe!recursive_edit_1() = =A0Line 780 C
=A0 emacs.exe!Frecursive_e= dit() =A0Line 844 C
= =A0 emacs.exe!main(int argc, ch= ar * * argv) =A0Line 1525 + 0x5 bytes = C




--f46d0443040421b3bd04cafa65a1-- From debbugs-submit-bounces@debbugs.gnu.org Mon Oct 01 04:13:46 2012 Received: (at 12544) by debbugs.gnu.org; 1 Oct 2012 08:13:46 +0000 Received: from localhost ([127.0.0.1]:35526 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TIb8M-00081w-DR for submit@debbugs.gnu.org; Mon, 01 Oct 2012 04:13:46 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]:61470) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TIb8K-00081o-I4 for 12544@debbugs.gnu.org; Mon, 01 Oct 2012 04:13:45 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MB700D00G2Y8A00@a-mtaout22.012.net.il> for 12544@debbugs.gnu.org; Mon, 01 Oct 2012 10:12:40 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MB700CF8G53OFC0@a-mtaout22.012.net.il>; Mon, 01 Oct 2012 10:12:40 +0200 (IST) Date: Mon, 01 Oct 2012 10:12:45 +0200 From: Eli Zaretskii Subject: Re: bug#12544: -r110296..110297 causes random crashes in optimized build on Windows In-reply-to: X-012-Sender: halo1@inter.net.il To: Fabrice Popineau Message-id: <83ipaud30i.fsf@gnu.org> References: X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 12544 Cc: lekktu@gmail.com, 12544@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 1.0 (+) > From: Fabrice Popineau > 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. From debbugs-submit-bounces@debbugs.gnu.org Mon Oct 01 04:38:30 2012 Received: (at 12544) by debbugs.gnu.org; 1 Oct 2012 08:38:30 +0000 Received: from localhost ([127.0.0.1]:35548 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TIbWH-0000BJ-OS for submit@debbugs.gnu.org; Mon, 01 Oct 2012 04:38:30 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]:34939) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TIbWD-0000BA-U9 for 12544@debbugs.gnu.org; Mon, 01 Oct 2012 04:38:27 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MB700D00H2QFZ00@a-mtaout22.012.net.il> for 12544@debbugs.gnu.org; Mon, 01 Oct 2012 10:37:03 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MB700DHMH9Q8J40@a-mtaout22.012.net.il>; Mon, 01 Oct 2012 10:37:03 +0200 (IST) Date: Mon, 01 Oct 2012 10:37:08 +0200 From: Eli Zaretskii Subject: Re: bug#12544: -r110296..110297 causes random crashes in optimized build on Windows In-reply-to: X-012-Sender: halo1@inter.net.il To: Juanma Barranquero Message-id: <83haqed1vv.fsf@gnu.org> References: X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 12544 Cc: 12544@debbugs.gnu.org, fabrice.popineau@supelec.fr X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 1.0 (+) > From: Juanma Barranquero > 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 ". 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, # 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 > , nargs=2, args=0x88e6b0, handlers=57538610, > hfun=0x111ba40 ) 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 , 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 , 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=, > 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 > , handlers=57589170, hfun=0x105e490 ) 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 > , 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=, 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=, > 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 > , nargs=2, args=0x88e6b0, handlers=57538610, > hfun=0x111ba40 ) 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? From debbugs-submit-bounces@debbugs.gnu.org Mon Oct 01 05:35:44 2012 Received: (at 12544) by debbugs.gnu.org; 1 Oct 2012 09:35:45 +0000 Received: from localhost ([127.0.0.1]:35685 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TIcPg-0001Uu-Ct for submit@debbugs.gnu.org; Mon, 01 Oct 2012 05:35:44 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]:48899) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TIcPe-0001Um-OV for 12544@debbugs.gnu.org; Mon, 01 Oct 2012 05:35:43 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MB700D00JL1YK00@a-mtaout22.012.net.il> for 12544@debbugs.gnu.org; Mon, 01 Oct 2012 11:34:32 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MB700DUIJXG9JA0@a-mtaout22.012.net.il>; Mon, 01 Oct 2012 11:34:29 +0200 (IST) Date: Mon, 01 Oct 2012 11:34:35 +0200 From: Eli Zaretskii Subject: Re: bug#12544: -r110296..110297 causes random crashes in optimized build on Windows In-reply-to: <83ipaud30i.fsf@gnu.org> X-012-Sender: halo1@inter.net.il To: fabrice.popineau@supelec.fr Message-id: <83fw5ycz84.fsf@gnu.org> References: <83ipaud30i.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 12544 Cc: lekktu@gmail.com, 12544@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 1.0 (+) > Date: Mon, 01 Oct 2012 10:12:45 +0200 > From: Eli Zaretskii > Cc: lekktu@gmail.com, 12544@debbugs.gnu.org > > > From: Fabrice Popineau > > 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... From debbugs-submit-bounces@debbugs.gnu.org Mon Oct 01 05:48:48 2012 Received: (at 12544) by debbugs.gnu.org; 1 Oct 2012 09:48:48 +0000 Received: from localhost ([127.0.0.1]:35700 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TIccK-0001my-D8 for submit@debbugs.gnu.org; Mon, 01 Oct 2012 05:48:48 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]:45230) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TIccI-0001mr-TH for 12544@debbugs.gnu.org; Mon, 01 Oct 2012 05:48:47 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MB700200KGKYQ00@a-mtaout20.012.net.il> for 12544@debbugs.gnu.org; Mon, 01 Oct 2012 11:47:53 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MB7002K8KJTLU70@a-mtaout20.012.net.il>; Mon, 01 Oct 2012 11:47:53 +0200 (IST) Date: Mon, 01 Oct 2012 11:47:59 +0200 From: Eli Zaretskii Subject: Re: bug#12544: -r110296..110297 causes random crashes in optimized build on Windows In-reply-to: <83haqed1vv.fsf@gnu.org> X-012-Sender: halo1@inter.net.il To: lekktu@gmail.com Message-id: <83ehlicyls.fsf@gnu.org> References: <83haqed1vv.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 12544 Cc: 12544@debbugs.gnu.org, fabrice.popineau@supelec.fr X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 1.0 (+) > Date: Mon, 01 Oct 2012 10:37:08 +0200 > From: Eli Zaretskii > 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. From debbugs-submit-bounces@debbugs.gnu.org Mon Oct 01 07:33:04 2012 Received: (at 12544) by debbugs.gnu.org; 1 Oct 2012 11:33:04 +0000 Received: from localhost ([127.0.0.1]:35791 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TIeFD-00051A-3b for submit@debbugs.gnu.org; Mon, 01 Oct 2012 07:33:03 -0400 Received: from mail-wg0-f46.google.com ([74.125.82.46]:48858) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TIeFA-00050l-U0 for 12544@debbugs.gnu.org; Mon, 01 Oct 2012 07:33:01 -0400 Received: by wgbdt12 with SMTP id dt12so3287641wgb.15 for <12544@debbugs.gnu.org>; Mon, 01 Oct 2012 04:32:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=xRAsXbhZ/rg9HUAiMTd+y2hwLD9ienJn7pM/5gRRxDQ=; b=LD/kHF8yQYQIFxdzHQ8ep6KN1M8fPCyFxPfzsVJqxfar/pyepfeI/YYI6uomLLV6mq 1zmckgXs4oUidf4rP4SuC3ZUGZpPQ9OkOGIYfpPK7l7OUe/73Ai5C+taLTy/8qFY3XVJ 1YnWGc53GOeRMXDPWppA3HCBykxv6AAYm4sEcWwn14UegbrRnOc9Xw6Qez5Jhmfago9p z2GBomiVTeo35uSvLRT8FA6bQj9JxHfDMuDAFBO/7geZ/QoJ4KcVccpfrTHZ9XQNT29f 4Yc7yZnTVJdczBFVOXBAH1OTWX2fLSrWPyyDYhdBvdAXM4MJyjLgq3mqDOZn41SpXHse 9eUA== Received: by 10.180.107.163 with SMTP id hd3mr13993570wib.19.1349091153797; Mon, 01 Oct 2012 04:32:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.26.162 with HTTP; Mon, 1 Oct 2012 04:32:13 -0700 (PDT) In-Reply-To: <83fw5ycz84.fsf@gnu.org> References: <83ipaud30i.fsf@gnu.org> <83fw5ycz84.fsf@gnu.org> From: Fabrice Popineau Date: Mon, 1 Oct 2012 13:32:13 +0200 X-Google-Sender-Auth: 1zPWDB6IWfRyz_iHUX72RuTBuus Message-ID: Subject: Re: bug#12544: -r110296..110297 causes random crashes in optimized build on Windows To: Eli Zaretskii Content-Type: multipart/alternative; boundary=e89a8f6474fdfde17004cafdc288 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 12544 Cc: lekktu@gmail.com, 12544@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -0.7 (/) --e89a8f6474fdfde17004cafdc288 Content-Type: text/plain; charset=ISO-8859-1 > 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 --e89a8f6474fdfde17004cafdc288 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I think I fix= ed this in trunk revision 110318. =A0The 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. =A0I now make sure any calls to setitimer after deleting the
critical sections will return immediately without doing anything.


The explanation seems fine. The experi= mentation too : I did a bootstrap
(64bits full optimization). It = ran smoothly.

Great job.

Fabrice

--e89a8f6474fdfde17004cafdc288-- From debbugs-submit-bounces@debbugs.gnu.org Mon Oct 01 07:42:05 2012 Received: (at 12544) by debbugs.gnu.org; 1 Oct 2012 11:42:05 +0000 Received: from localhost ([127.0.0.1]:35795 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TIeNx-0005Dc-N4 for submit@debbugs.gnu.org; Mon, 01 Oct 2012 07:42:05 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]:46728) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TIeNv-0005DT-Lx for 12544@debbugs.gnu.org; Mon, 01 Oct 2012 07:42:05 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MB700F00PP73K00@a-mtaout22.012.net.il> for 12544@debbugs.gnu.org; Mon, 01 Oct 2012 13:41:13 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MB700EV4PSOUD40@a-mtaout22.012.net.il>; Mon, 01 Oct 2012 13:41:13 +0200 (IST) Date: Mon, 01 Oct 2012 13:41:19 +0200 From: Eli Zaretskii Subject: Re: bug#12544: -r110296..110297 causes random crashes in optimized build on Windows In-reply-to: X-012-Sender: halo1@inter.net.il To: Juanma Barranquero Message-id: <837gractcw.fsf@gnu.org> References: X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 12544 Cc: 12544@debbugs.gnu.org, fabrice.popineau@supelec.fr X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 1.0 (+) 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. From debbugs-submit-bounces@debbugs.gnu.org Mon Oct 01 07:42:24 2012 Received: (at 12544) by debbugs.gnu.org; 1 Oct 2012 11:42:24 +0000 Received: from localhost ([127.0.0.1]:35798 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TIeOF-0005E7-SK for submit@debbugs.gnu.org; Mon, 01 Oct 2012 07:42:24 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]:46802) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TIeOD-0005E0-Vh for 12544@debbugs.gnu.org; Mon, 01 Oct 2012 07:42:22 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MB700F00PP73K00@a-mtaout22.012.net.il> for 12544@debbugs.gnu.org; Mon, 01 Oct 2012 13:41:39 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MB700F1FPTE3710@a-mtaout22.012.net.il>; Mon, 01 Oct 2012 13:41:38 +0200 (IST) Date: Mon, 01 Oct 2012 13:41:44 +0200 From: Eli Zaretskii Subject: Re: bug#12544: -r110296..110297 causes random crashes in optimized build on Windows In-reply-to: X-012-Sender: halo1@inter.net.il To: Fabrice Popineau Message-id: <83626uctc7.fsf@gnu.org> References: <83ipaud30i.fsf@gnu.org> <83fw5ycz84.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 12544 Cc: lekktu@gmail.com, 12544@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 1.0 (+) > From: Fabrice Popineau > 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. From debbugs-submit-bounces@debbugs.gnu.org Mon Oct 01 07:46:26 2012 Received: (at 12544) by debbugs.gnu.org; 1 Oct 2012 11:46:27 +0000 Received: from localhost ([127.0.0.1]:35803 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TIeSA-0005K4-CA for submit@debbugs.gnu.org; Mon, 01 Oct 2012 07:46:26 -0400 Received: from mail-bk0-f44.google.com ([209.85.214.44]:36859) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TIeS8-0005Jx-Ct for 12544@debbugs.gnu.org; Mon, 01 Oct 2012 07:46:25 -0400 Received: by bkcjc3 with SMTP id jc3so4748874bkc.3 for <12544@debbugs.gnu.org>; Mon, 01 Oct 2012 04:45:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Ba4t2WiKpuY3UNc/8DZs7gCdyz5anjsbWxIQuN8mYrc=; b=MFVzhoAESPVlEPedSMoaBVgyerc0BI9etVWbC6NDOWVwqDyxyl0ZcDEZN2616mjklC 94RxwUMP5PEpYHbZLzkFuRLxYj2SN3e2WYy5sNQ+QmMl3vtJQRFqTGOdc8r3JQ+r7ony nVMVrFdEr/sB3FWJ8l1+04TPDC9MPn4jcFHiHAleg7hKMvNxevMKYPh58Y+Q6XYo/W5P mvR7lkECptuWIuF26i9IF2HokHZk2t2++BAhA6enW7Fuulz4RiJR1Rr+JYrstu1/D9Zt Iq6teqjpayxULyJkICi3YrX9MwQBVOYCSYG9jaoRWJ+MKD6RqyOfexwQ5DJp27kLVTjU ykcw== Received: by 10.204.12.215 with SMTP id y23mr5753529bky.13.1349091957308; Mon, 01 Oct 2012 04:45:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.230.72 with HTTP; Mon, 1 Oct 2012 04:45:17 -0700 (PDT) In-Reply-To: <83haqed1vv.fsf@gnu.org> References: <83haqed1vv.fsf@gnu.org> From: Juanma Barranquero Date: Mon, 1 Oct 2012 13:45:17 +0200 Message-ID: Subject: Re: bug#12544: -r110296..110297 causes random crashes in optimized build on Windows To: Eli Zaretskii Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 12544 Cc: 12544@debbugs.gnu.org, fabrice.popineau@supelec.fr X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -0.7 (/) On Mon, Oct 1, 2012 at 10:37 AM, Eli Zaretskii 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 From debbugs-submit-bounces@debbugs.gnu.org Mon Oct 01 08:30:50 2012 Received: (at 12544) by debbugs.gnu.org; 1 Oct 2012 12:30:50 +0000 Received: from localhost ([127.0.0.1]:35854 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TIf97-0006IX-Nl for submit@debbugs.gnu.org; Mon, 01 Oct 2012 08:30:50 -0400 Received: from mtaout21.012.net.il ([80.179.55.169]:42289) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TIf94-0006IL-98 for 12544@debbugs.gnu.org; Mon, 01 Oct 2012 08:30:47 -0400 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0MB700400S13WL00@a-mtaout21.012.net.il> for 12544@debbugs.gnu.org; Mon, 01 Oct 2012 14:30:18 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MB7004GVS2HOO90@a-mtaout21.012.net.il>; Mon, 01 Oct 2012 14:30:18 +0200 (IST) Date: Mon, 01 Oct 2012 14:30:24 +0200 From: Eli Zaretskii Subject: Re: bug#12544: -r110296..110297 causes random crashes in optimized build on Windows In-reply-to: X-012-Sender: halo1@inter.net.il To: Juanma Barranquero Message-id: <834nmecr33.fsf@gnu.org> References: <83haqed1vv.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 12544 Cc: 12544@debbugs.gnu.org, fabrice.popineau@supelec.fr X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 1.0 (+) > From: Juanma Barranquero > 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... From debbugs-submit-bounces@debbugs.gnu.org Mon Oct 01 10:29:28 2012 Received: (at 12544) by debbugs.gnu.org; 1 Oct 2012 14:29:28 +0000 Received: from localhost ([127.0.0.1]:36462 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TIgzv-0000cC-EW for submit@debbugs.gnu.org; Mon, 01 Oct 2012 10:29:28 -0400 Received: from mail-bk0-f44.google.com ([209.85.214.44]:62981) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TIgzt-0000c4-Gx for 12544@debbugs.gnu.org; Mon, 01 Oct 2012 10:29:26 -0400 Received: by bkcjc3 with SMTP id jc3so4864907bkc.3 for <12544@debbugs.gnu.org>; Mon, 01 Oct 2012 07:28:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=WCS9GYFbgoDgAK/3IVkqYkH7sD446hqtzp9rLcUUdWg=; b=bIUyrH870fYJYgD7xYawbGBwNo4bQ+wi65rbRAt/qiOzu73igXlPRACAS1JXP3Z5Wb OjtB0XaPdu9ixtkiMPyXkXC3rYhT76+jKptiGDV6gzOemFM8nitr6615yLoXj8+PDR+7 XQ6DU/+dmNKHJjVqp/MyVLVJzJxFWjMl6kPE/x6e/EN/8YIEyUx+V/BDOxIaNGugIZBu I4hWeeq0O8PFaiHqaY/fOO+XekEuhViqsnSDs/fff64q6LKWMwHoeS3r7J6f+X8yL/Im UDtkbXmB9V2u30yUYm7TH/RIGHc92aRyEZioPZm1w0mk1rilcXkBOaz2t+vHRoYZQ12i LUeQ== Received: by 10.205.127.146 with SMTP id ha18mr965913bkc.130.1349101736624; Mon, 01 Oct 2012 07:28:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.230.72 with HTTP; Mon, 1 Oct 2012 07:28:16 -0700 (PDT) In-Reply-To: <834nmecr33.fsf@gnu.org> References: <83haqed1vv.fsf@gnu.org> <834nmecr33.fsf@gnu.org> From: Juanma Barranquero Date: Mon, 1 Oct 2012 16:28:16 +0200 Message-ID: Subject: Re: bug#12544: -r110296..110297 causes random crashes in optimized build on Windows To: Eli Zaretskii Content-Type: text/plain; charset=UTF-8 X-Spam-Score: 0.1 (/) X-Debbugs-Envelope-To: 12544 Cc: 12544@debbugs.gnu.org, fabrice.popineau@supelec.fr X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.1 (/) On Mon, Oct 1, 2012 at 2:30 PM, Eli Zaretskii 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 From debbugs-submit-bounces@debbugs.gnu.org Mon Oct 01 10:52:53 2012 Received: (at 12544-done) by debbugs.gnu.org; 1 Oct 2012 14:52:53 +0000 Received: from localhost ([127.0.0.1]:36479 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TIhMb-0001A3-Dy for submit@debbugs.gnu.org; Mon, 01 Oct 2012 10:52:53 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]:55288) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TIhMZ-00019u-0D for 12544-done@debbugs.gnu.org; Mon, 01 Oct 2012 10:52:52 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MB700G00YIXSW00@a-mtaout22.012.net.il> for 12544-done@debbugs.gnu.org; Mon, 01 Oct 2012 16:52:22 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MB700G7PYNAM440@a-mtaout22.012.net.il>; Mon, 01 Oct 2012 16:52:22 +0200 (IST) Date: Mon, 01 Oct 2012 16:52:29 +0200 From: Eli Zaretskii Subject: Re: bug#12544: -r110296..110297 causes random crashes in optimized build on Windows In-reply-to: X-012-Sender: halo1@inter.net.il To: Juanma Barranquero Message-id: <83sj9yb5xu.fsf@gnu.org> References: <83haqed1vv.fsf@gnu.org> <834nmecr33.fsf@gnu.org> X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > From: Juanma Barranquero > 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 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. [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.172 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.5000] X-Debbugs-Envelope-To: 12544-done Cc: 12544-done@debbugs.gnu.org, fabrice.popineau@supelec.fr X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > From: Juanma Barranquero > 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 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. [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.172 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.5000] > From: Juanma Barranquero > 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 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. From debbugs-submit-bounces@debbugs.gnu.org Mon Oct 01 10:58:56 2012 Received: (at 12544-done) by debbugs.gnu.org; 1 Oct 2012 14:58:56 +0000 Received: from localhost ([127.0.0.1]:36500 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TIhSS-0001JN-0j for submit@debbugs.gnu.org; Mon, 01 Oct 2012 10:58:56 -0400 Received: from mail-wg0-f46.google.com ([74.125.82.46]:53058) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TIhSP-0001JG-KC for 12544-done@debbugs.gnu.org; Mon, 01 Oct 2012 10:58:54 -0400 Received: by wgbdt12 with SMTP id dt12so3436732wgb.15 for <12544-done@debbugs.gnu.org>; Mon, 01 Oct 2012 07:58:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=UnaQ21PtQYxnDAkF//kszk7ft2q2gO5DIok0w4ebGbk=; b=TTmVbV29HgQfaI/BMeCjdQfo9clxmc3CCE1iMjNCEtC9SPEb33ZhRLmsqZ0UUtaFWg hDm+A05Tf/X9F+RoxtQf7UEYnbtI/KcmZ93Kp7ffZz7eYZe+9bNiwGPQgzFRLYJNv1cB GB3x0TzaL1baYvLOZ6xnNq13Xu18aJioujDK0dOG9Y8DdcbQbb7mPcDf57mnDswdnlLr Vccv0HIqjLogMKPbhNhWWHzwvneFF1tmcT4JFiXFBsu1F/QeExPEOWNwlLscipCm2H2Z WDSUUJbLWRyCs3X4Zo0WJxSqio73IoDre2tMrasOuKHf8enDGrJWOPPGAFGPZtHQ1Pd4 ndMQ== Received: by 10.216.195.25 with SMTP id o25mr7470366wen.6.1349103505734; Mon, 01 Oct 2012 07:58:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.26.162 with HTTP; Mon, 1 Oct 2012 07:58:05 -0700 (PDT) In-Reply-To: <83sj9yb5xu.fsf@gnu.org> References: <83haqed1vv.fsf@gnu.org> <834nmecr33.fsf@gnu.org> <83sj9yb5xu.fsf@gnu.org> From: Fabrice Popineau Date: Mon, 1 Oct 2012 16:58:05 +0200 X-Google-Sender-Auth: blm8nCARmEGoBN2AEPQdu3nTBT4 Message-ID: Subject: Re: bug#12544: -r110296..110297 causes random crashes in optimized build on Windows To: Eli Zaretskii Content-Type: multipart/alternative; boundary=0016e6db7c6f397dad04cb00a38f X-Spam-Score: 0.1 (/) X-Debbugs-Envelope-To: 12544-done Cc: Juanma Barranquero , 12544-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.1 (/) --0016e6db7c6f397dad04cb00a38f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 > > From: Juanma Barranquero > > 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 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. > --=20 Fabrice Popineau ----------------------------- SUPELEC D=E9partement Informatique 3, rue Joliot Curie 91192 Gif/Yvette Cedex Tel direct : +33 (0) 169851950 Standard : +33 (0) 169851212 ------------------------------ --0016e6db7c6f397dad04cb00a38f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hey ... you did a great job by commiting all this stuff in such a short tim= e.=A0
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 <lekkt= u@gmail.com>
> Date: Mon, 1 Oct 2012 16:28:16 +0200
> Cc: 12544@debbugs.gnu.org= , fabrice.popineau@supelec.f= r
>
> On Mon, Oct 1, 2012 at 2:30 PM, Eli Zaretskii &= lt;eliz@gnu.org> wrote:
>
> > Amazing. =A0Holding 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! =A0A large stone just dropped off my heart. =A0Thanks 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. =A0I guess my mind is not too clear after 11PM, not in my age.

Closing.



--
Fabrice Popi= neau
-----------------------------
SUPELEC
D=E9part= ement Informatique
3, rue Joliot Curie
91192 Gif/Yvette= Cedex
Tel direct : +33 (0) 169851950
Standard : +33 (0) 169851212<= /div>
------------------------------


--0016e6db7c6f397dad04cb00a38f-- From unknown Sun Jun 15 08:17:39 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Tue, 30 Oct 2012 11:24:04 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator