* bug#35204: 27.0.50; Crash on Cygwin @ 2019-04-09 8:07 Katsumi Yamaoka 2019-04-09 9:47 ` Eli Zaretskii 0 siblings, 1 reply; 16+ messages in thread From: Katsumi Yamaoka @ 2019-04-09 8:07 UTC (permalink / raw) To: 35204 Hi, Recently Emacs on Cygwin suddenly crashes while it is (probably) in idle, only it lives for several minuits, but reverting the following three changes seems to help. 1. commit 0b8117ed1abfc17bb0bc1690a8997736f1e8f98c ; * src/frame.h (MonitorInfo): Remove const modifier 2. commit 7b78857c0ba69eafd780484641b858ae8a167044 ; * src/xfns.c (x-display-monitor-attributes-list) Fix typo. 3. commit a35e06bbe27c5907f56c5aeb48182d7be00d1dec Plug memory leak in GTK x-display-monitor-attributes-list * src/frame.c (free_monitors) [USE_GTK]: Define in the GTK case as well. * src/xfns.c (x-display-monitor-attributes-list) [USE_GTK]: Plug memory leak. * src/frame.h (MonitorInfo): Declare name as pointing to const char. I'm not sure what to do but please tell me anything I should do. In GNU Emacs 27.0.50 (build 3, x86_64-pc-cygwin, GTK+ Version 3.22.28) of 2019-04-09 built on localhost Windowing system distributor 'The Cygwin/X Project', version 11.0.12004000 Configured using: 'configure CFLAGS=-O0 --verbose --with-x-toolkit=gtk3' uname -a CYGWIN_NT-10.0 localhost 3.0.6(0.338/5/3) 2019-04-06 16:18 x86_64 Cygwin Here is a gdb backtrace I got after reverting only 1.: (gdb) bt #0 0x000000010054a66a in terminate_due_to_signal () #1 0x000000010057110d in handle_fatal_signal () #2 0x00000001005710e0 in deliver_thread_signal () #3 0x0000000100571149 in deliver_fatal_thread_signal () #4 0x0000000100571361 in handle_sigsegv () #5 0x000000018005f65a in altstack_wrapper (sig=<optimized out>, siginfo=<optimized out>, sigctx=0xffffde50, handler=0x1005712a5 <handle_sigsegv>) at /usr/src/debug/cygwin-3.0.6-1/winsup/cygwin/exceptions.cc:1595 #6 0x0000000180062dfa in _cygtls::call_signal_handler (this=0xffffce00) at /usr/src/debug/cygwin-3.0.6-1/winsup/cygwin/exceptions.cc:1777 #7 0x0000000000000000 in ?? () I couldn't fetch a backtrace for Emacs before reverting because of an error: (gdb) bt #0 0x000000010054a72f in terminate_due_to_signal () #1 0x000303e90000faf0 in ?? () Backtrace stopped: previous frame inner to this frame (corrupt stack?) Couldn't fetch xbacktrace either: (gdb) source .gdbinit SIGINT is used by the debugger. Are you sure you want to change it? (y or n) [answered Y; input not from terminal] DISPLAY = :0.0 TERM = xterm Breakpoint 1 at 0x10054a66a .gdbinit:1228: Error in sourced command file: No symbol "defined_HAVE_X_WINDOWS" in current context. Thanks. Regards, ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#35204: 27.0.50; Crash on Cygwin 2019-04-09 8:07 bug#35204: 27.0.50; Crash on Cygwin Katsumi Yamaoka @ 2019-04-09 9:47 ` Eli Zaretskii 2019-04-10 4:54 ` Katsumi Yamaoka 0 siblings, 1 reply; 16+ messages in thread From: Eli Zaretskii @ 2019-04-09 9:47 UTC (permalink / raw) To: Katsumi Yamaoka; +Cc: 35204 > Date: Tue, 09 Apr 2019 17:07:58 +0900 > From: Katsumi Yamaoka <yamaoka@jpl.org> > > Here is a gdb backtrace I got after reverting only 1.: > > (gdb) bt > #0 0x000000010054a66a in terminate_due_to_signal () > #1 0x000000010057110d in handle_fatal_signal () > #2 0x00000001005710e0 in deliver_thread_signal () > #3 0x0000000100571149 in deliver_fatal_thread_signal () > #4 0x0000000100571361 in handle_sigsegv () > #5 0x000000018005f65a in altstack_wrapper (sig=<optimized out>, > siginfo=<optimized out>, sigctx=0xffffde50, > handler=0x1005712a5 <handle_sigsegv>) > at /usr/src/debug/cygwin-3.0.6-1/winsup/cygwin/exceptions.cc:1595 > #6 0x0000000180062dfa in _cygtls::call_signal_handler (this=0xffffce00) > at /usr/src/debug/cygwin-3.0.6-1/winsup/cygwin/exceptions.cc:1777 > #7 0x0000000000000000 in ?? () Is this when you run Emacs from GDB to begin with? If not, please run Emacs from GDB, then the backtrace should be more informative. > I couldn't fetch a backtrace for Emacs before reverting because > of an error: > > (gdb) bt > #0 0x000000010054a72f in terminate_due_to_signal () > #1 0x000303e90000faf0 in ?? () > Backtrace stopped: previous frame inner to this frame (corrupt stack?) How many threads are in the process? Did you type "bt" when the Lisp thread was the current one? > Couldn't fetch xbacktrace either: > > (gdb) source .gdbinit > SIGINT is used by the debugger. > Are you sure you want to change it? (y or n) [answered Y; input not from terminal] > DISPLAY = :0.0 > TERM = xterm > Breakpoint 1 at 0x10054a66a > .gdbinit:1228: Error in sourced command file: > No symbol "defined_HAVE_X_WINDOWS" in current context. Did you build Emacs with -g3 switch to GCC? ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#35204: 27.0.50; Crash on Cygwin 2019-04-09 9:47 ` Eli Zaretskii @ 2019-04-10 4:54 ` Katsumi Yamaoka 2019-04-10 14:37 ` Eli Zaretskii 0 siblings, 1 reply; 16+ messages in thread From: Katsumi Yamaoka @ 2019-04-10 4:54 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 35204 [-- Attachment #1: Type: text/plain, Size: 1780 bytes --] On Tue, 09 Apr 2019 12:47:52 +0300, Eli Zaretskii wrote: >> Date: Tue, 09 Apr 2019 17:07:58 +0900 >> From: Katsumi Yamaoka <yamaoka@jpl.org> >> Here is a gdb backtrace I got after reverting only 1.: >> (gdb) bt >> #0 0x000000010054a66a in terminate_due_to_signal () [...] > Is this when you run Emacs from GDB to begin with? If not, please run > Emacs from GDB, then the backtrace should be more informative. I did so. I rebuilt separately Emacs from scratch from today's Git repo with no modification on the source using these configure options configure --verbose --with-x-toolkit=gtk3 (I detached "CFLAGS=-O0"), run it from gdb, and I got the backtrace that is in the bottom of the attached GDB log. It might be too short to analyze, though. >> I couldn't fetch a backtrace for Emacs before reverting because >> of an error: >> (gdb) bt >> #0 0x000000010054a72f in terminate_due_to_signal () >> #1 0x000303e90000faf0 in ?? () >> Backtrace stopped: previous frame inner to this frame (corrupt stack?) > How many threads are in the process? Did you type "bt" when the Lisp > thread was the current one? There are 121 threads (IIUC). I don't konw what is the Lisp thread, sorry. >> Couldn't fetch xbacktrace either: >> (gdb) source .gdbinit [...] >> .gdbinit:1228: Error in sourced command file: >> No symbol "defined_HAVE_X_WINDOWS" in current context. > Did you build Emacs with -g3 switch to GCC? No, I don't specify -g3 expressly/intendedly. But it came not to issue an error today for an unknown reason. (I don't know why but today's Emacs lived for over an hour, so I was excited over a false hope. The main Emacs that I rebuilt from Git master today is working fine with reverting the three changes in question.) Here is the GDB log. Thanks. [-- Attachment #2: Type: application/octet-stream, Size: 11523 bytes --] cd src gdb ./emacs.exe GNU gdb (GDB) (Cygwin 8.1.1-1) 8.1.1 Copyright (C) 2018 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-cygwin". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from ./emacs.exe...done. warning: File "/Work/emacs-27.0.50/src/.gdbinit" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load". To enable execution of this file add add-auto-load-safe-path /Work/emacs-27.0.50/src/.gdbinit line to your configuration file "/home/yamaoka/.gdbinit". To completely disable this security protection add set auto-load safe-path / line to your configuration file "/home/yamaoka/.gdbinit". For more information about this security protection see the "Auto-loading safe path" section in the GDB manual. E.g., run from the shell: info "(gdb)Auto-loading safe path" (gdb) source .gdbinit SIGINT is used by the debugger. Are you sure you want to change it? (y or n) [answered Y; input not from terminal] DISPLAY = :0.0 TERM = xterm Breakpoint 1 at 0x1004d92b0: file emacs.c, line 370. Breakpoint 2 at 0x1004aa610: file xterm.c, line 9979. (gdb) r Starting program: /Work/emacs-27.0.50/src/emacs.exe [New Thread 1768.0x2ac0] [New Thread 1768.0xee8] [New Thread 1768.0x7ac] [New Thread 1768.0xd50] [New Thread 1768.0x1fd8] [New Thread 1768.0x2630] [New Thread 1768.0xba0] [New Thread 1768.0x187c] [New Thread 1768.0x14d0] [New Thread 1768.0x1cd0] [New Thread 1768.0x2968] [New Thread 1768.0x1ea0] [New Thread 1768.0x7ec] ** (emacs:41723): WARNING **: Error retrieving accessibility bus address: org.freedesktop.DBus.Error.NoReply: Message recipient disconnected from message bus without replying [New Thread 1768.0x10c0] [New Thread 1768.0x222c] [New Thread 1768.0x1b60] [New Thread 1768.0x640] [New Thread 1768.0xf4c] [Thread 1768.0x2968 exited with code 0] [New Thread 1768.0x136c] [New Thread 1768.0x1628] [New Thread 1768.0x18c4] [New Thread 1768.0x18bc] [Thread 1768.0xf4c exited with code 0] [New Thread 1768.0x1af4] [Thread 1768.0x1af4 exited with code 0] [New Thread 1768.0xe24] [Thread 1768.0xe24 exited with code 0] [New Thread 1768.0x2b34] [Thread 1768.0x2b34 exited with code 0] [New Thread 1768.0x2120] [Thread 1768.0x2120 exited with code 0] [New Thread 1768.0x470] [Thread 1768.0x470 exited with code 0] [New Thread 1768.0x1d58] [Thread 1768.0x1d58 exited with code 0] [New Thread 1768.0x298c] [Thread 1768.0x298c exited with code 0] [New Thread 1768.0x2218] [Thread 1768.0x2218 exited with code 0] [New Thread 1768.0x25b4] [Thread 1768.0x25b4 exited with code 0] [New Thread 1768.0x9f8] [Thread 1768.0x9f8 exited with code 0] [New Thread 1768.0x114c] [Thread 1768.0x114c exited with code 0] [New Thread 1768.0x9dc] [Thread 1768.0x9dc exited with code 0] [New Thread 1768.0x2268] [Thread 1768.0x2268 exited with code 0] [New Thread 1768.0x28c4] [Thread 1768.0x28c4 exited with code 0] [New Thread 1768.0x20dc] [Thread 1768.0x20dc exited with code 0] [New Thread 1768.0x808] [Thread 1768.0x808 exited with code 0] [New Thread 1768.0x10e4] [Thread 1768.0x10e4 exited with code 0] [New Thread 1768.0xb70] [Thread 1768.0xb70 exited with code 0] [New Thread 1768.0x103c] [Thread 1768.0x103c exited with code 0] [New Thread 1768.0x2bec] [Thread 1768.0x2bec exited with code 0] [New Thread 1768.0x760] [Thread 1768.0x760 exited with code 0] [New Thread 1768.0xb8c] [Thread 1768.0xb8c exited with code 0] [New Thread 1768.0x2944] [Thread 1768.0x2944 exited with code 0] [New Thread 1768.0x1dd8] [Thread 1768.0x1dd8 exited with code 0] [New Thread 1768.0xb24] [Thread 1768.0xb24 exited with code 0] [New Thread 1768.0xb20] [Thread 1768.0xb20 exited with code 0] [New Thread 1768.0x29ac] [Thread 1768.0x29ac exited with code 0] [New Thread 1768.0x2230] [Thread 1768.0x2230 exited with code 0] [New Thread 1768.0x2b2c] [Thread 1768.0x2b2c exited with code 0] [New Thread 1768.0x2a84] [Thread 1768.0x2a84 exited with code 0] [New Thread 1768.0x22d8] [Thread 1768.0x22d8 exited with code 0] [New Thread 1768.0x15f4] [Thread 1768.0x15f4 exited with code 0] [New Thread 1768.0x2244] [Thread 1768.0x2244 exited with code 0] [New Thread 1768.0x2a80] [Thread 1768.0x2a80 exited with code 0] [New Thread 1768.0x1128] [Thread 1768.0x1128 exited with code 0] [New Thread 1768.0x1a70] [Thread 1768.0x1a70 exited with code 0] [New Thread 1768.0x11f8] [Thread 1768.0x11f8 exited with code 0] [New Thread 1768.0x3bc] [Thread 1768.0x3bc exited with code 0] [New Thread 1768.0x1120] [Thread 1768.0x1120 exited with code 0] [New Thread 1768.0x25b4] [Thread 1768.0x25b4 exited with code 0] [New Thread 1768.0x255c] [Thread 1768.0x255c exited with code 0] [New Thread 1768.0x2c8] [Thread 1768.0x2c8 exited with code 0] [New Thread 1768.0x1304] [Thread 1768.0x1304 exited with code 0] [New Thread 1768.0x510] [Thread 1768.0x510 exited with code 0] [New Thread 1768.0xaa4] [Thread 1768.0xaa4 exited with code 0] [New Thread 1768.0x95c] [Thread 1768.0x95c exited with code 0] [New Thread 1768.0x2a04] [Thread 1768.0x2a04 exited with code 0] [New Thread 1768.0x291c] [Thread 1768.0x291c exited with code 0] [New Thread 1768.0x2528] [Thread 1768.0x2528 exited with code 0] [New Thread 1768.0x1f88] [Thread 1768.0x1f88 exited with code 0] [New Thread 1768.0x28a0] [Thread 1768.0x28a0 exited with code 0] [New Thread 1768.0xb00] [Thread 1768.0xb00 exited with code 0] [New Thread 1768.0x2534] [Thread 1768.0x2534 exited with code 0] [New Thread 1768.0x2ba8] [Thread 1768.0x2ba8 exited with code 0] [New Thread 1768.0x199c] [Thread 1768.0x199c exited with code 0] [New Thread 1768.0x1c70] [Thread 1768.0x1c70 exited with code 0] [New Thread 1768.0xc44] [Thread 1768.0xc44 exited with code 0] [New Thread 1768.0x11a4] [Thread 1768.0x11a4 exited with code 0] [New Thread 1768.0x878] [Thread 1768.0x878 exited with code 0] [New Thread 1768.0x1454] [Thread 1768.0x1454 exited with code 0] [New Thread 1768.0x27ec] [Thread 1768.0x27ec exited with code 0] [New Thread 1768.0x18fc] [Thread 1768.0x18fc exited with code 0] [New Thread 1768.0xe1c] [Thread 1768.0xe1c exited with code 0] [New Thread 1768.0x9cc] [Thread 1768.0x9cc exited with code 0] [New Thread 1768.0x25b4] [Thread 1768.0x25b4 exited with code 0] [New Thread 1768.0x198c] [Thread 1768.0x198c exited with code 0] [New Thread 1768.0x2c8] [Thread 1768.0x2c8 exited with code 0] [New Thread 1768.0x10e0] [Thread 1768.0x10e0 exited with code 0] [New Thread 1768.0x2178] [Thread 1768.0x2178 exited with code 0] [New Thread 1768.0x290c] [Thread 1768.0x290c exited with code 0] [New Thread 1768.0x2608] [Thread 1768.0x2608 exited with code 0] [New Thread 1768.0x28f4] [Thread 1768.0x28f4 exited with code 0] [New Thread 1768.0x2490] [Thread 1768.0x2490 exited with code 0] [New Thread 1768.0x180] [Thread 1768.0x180 exited with code 0] [New Thread 1768.0xb24] [Thread 1768.0xb24 exited with code 0] [New Thread 1768.0x1be8] [Thread 1768.0x1be8 exited with code 0] [New Thread 1768.0x1e0c] [Thread 1768.0x1e0c exited with code 0] [New Thread 1768.0x2918] [Thread 1768.0x2918 exited with code 0] [New Thread 1768.0x10fc] [Thread 1768.0x10fc exited with code 0] [New Thread 1768.0x2a84] [Thread 1768.0x2a84 exited with code 0] [New Thread 1768.0x27bc] [Thread 1768.0x27bc exited with code 0] [New Thread 1768.0xc50] [Thread 1768.0xc50 exited with code 0] [New Thread 1768.0x21b4] [Thread 1768.0x21b4 exited with code 0] [New Thread 1768.0x960] [Thread 1768.0x960 exited with code 0] [New Thread 1768.0x810] [Thread 1768.0x810 exited with code 0] [New Thread 1768.0x2870] [Thread 1768.0x2870 exited with code 0] [New Thread 1768.0x18fc] [Thread 1768.0x18fc exited with code 0] [New Thread 1768.0x1dcc] [Thread 1768.0x1dcc exited with code 0] [New Thread 1768.0xc24] [Thread 1768.0xc24 exited with code 0] [New Thread 1768.0x2c8] [Thread 1768.0x2c8 exited with code 0] [New Thread 1768.0x10e0] [Thread 1768.0x10e0 exited with code 0] [New Thread 1768.0xaa4] [Thread 1768.0xaa4 exited with code 0] [New Thread 1768.0x290c] [Thread 1768.0x290c exited with code 0] [New Thread 1768.0x2004] [Thread 1768.0x2004 exited with code 0] [New Thread 1768.0x28f4] [Thread 1768.0x28f4 exited with code 0] [New Thread 1768.0x24fc] [Thread 1768.0x24fc exited with code 0] [New Thread 1768.0x818] [Thread 1768.0x818 exited with code 0] [New Thread 1768.0x2564] [Thread 1768.0x2564 exited with code 0] [New Thread 1768.0x2bf8] [Thread 1768.0x2bf8 exited with code 0] [New Thread 1768.0x29ac] [Thread 1768.0x29ac exited with code 0] [New Thread 1768.0xd74] [Thread 1768.0xd74 exited with code 0] [New Thread 1768.0x1dac] [Thread 1768.0x1dac exited with code 0] [New Thread 1768.0x4bc] [Thread 1768.0x4bc exited with code 0] [New Thread 1768.0x1b4] [Thread 1768.0x1b4 exited with code 0] [New Thread 1768.0x1408] [Thread 1768.0x1408 exited with code 0] [New Thread 1768.0x2440] [Thread 1768.0x2440 exited with code 0] [New Thread 1768.0x8a4] [Thread 1768.0x8a4 exited with code 0] [New Thread 1768.0x2e0] [Thread 1768.0x2e0 exited with code 0] [New Thread 1768.0x1450] [Thread 1768.0x1450 exited with code 0] [New Thread 1768.0x13e4] [Thread 1768.0x13e4 exited with code 0] [New Thread 1768.0x1ed4] [Thread 1768.0x1ed4 exited with code 0] [New Thread 1768.0x143c] [Thread 1768.0x143c exited with code 0] [New Thread 1768.0x2268] [Thread 1768.0x2268 exited with code 0] [New Thread 1768.0xbac] [Thread 1768.0xbac exited with code 0] [New Thread 1768.0x1e84] [Thread 1768.0x1e84 exited with code 0] [New Thread 1768.0x103c] [Thread 1768.0x103c exited with code 0] [New Thread 1768.0x2258] [Thread 1768.0x2258 exited with code 0] [New Thread 1768.0x1ec4] [Thread 1768.0x136c exited with code 0] [New Thread 1768.0x9dc] [Thread 1768.0x9dc exited with code 0] Thread 1 "emacs" hit Breakpoint 1, terminate_due_to_signal (sig=11, backtrace_limit=40) at emacs.c:370 370 { (gdb) bt #0 terminate_due_to_signal (sig=11, backtrace_limit=40) at emacs.c:370 #1 0x00000001004f134e in handle_fatal_signal (sig=sig@entry=11) at sysdep.c:1793 #2 0x00000001004f153f in deliver_thread_signal (sig=sig@entry=11, handler=0x1004f1340 <handle_fatal_signal>) at sysdep.c:1767 #3 0x00000001004f159f in deliver_fatal_thread_signal (sig=11) at sysdep.c:1805 #4 handle_sigsegv (sig=11, siginfo=0x1009dea10 <sigsegv_stack+32464>, arg=<optimized out>) at sysdep.c:1890 #5 0x000000018005f65a in altstack_wrapper (sig=<optimized out>, siginfo=<optimized out>, sigctx=0xffffde50, handler=0x1004f1580 <handle_sigsegv>) at /usr/src/debug/cygwin-3.0.6-1/winsup/cygwin/exceptions.cc:1595 #6 0x0000000180062dfa in _cygtls::call_signal_handler (this=0xffffce00) at /usr/src/debug/cygwin-3.0.6-1/winsup/cygwin/exceptions.cc:1777 #7 0x0000000000000000 in ?? () Backtrace stopped: previous frame inner to this frame (corrupt stack?) Lisp Backtrace: "x-show-tip" (0xffffac20) "tooltip-show" (0xffffaf60) "tooltip-help-tips" (0xffffb2c8) "run-hook-with-args-until-success" (0xffffb2c0) "tooltip-timeout" (0xffffb670) "apply" (0xffffb668) "timer-event-handler" (0xffffb9a8) (gdb) ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#35204: 27.0.50; Crash on Cygwin 2019-04-10 4:54 ` Katsumi Yamaoka @ 2019-04-10 14:37 ` Eli Zaretskii 2019-04-11 2:31 ` Katsumi Yamaoka 0 siblings, 1 reply; 16+ messages in thread From: Eli Zaretskii @ 2019-04-10 14:37 UTC (permalink / raw) To: Katsumi Yamaoka; +Cc: 35204 > Date: Wed, 10 Apr 2019 13:54:16 +0900 > From: Katsumi Yamaoka <yamaoka@jpl.org> > Cc: 35204@debbugs.gnu.org > > > Is this when you run Emacs from GDB to begin with? If not, please run > > Emacs from GDB, then the backtrace should be more informative. > > I did so. I rebuilt separately Emacs from scratch from today's > Git repo with no modification on the source using these configure > options > > configure --verbose --with-x-toolkit=gtk3 > > (I detached "CFLAGS=-O0") Does it mean you used "CFLAGS=-O0", or does it mean you did NOT use it? It is better to use it, together with -g3, as that makes debugging easier. > run it from gdb, and I got the backtrace that is in the bottom of > the attached GDB log. It might be too short to analyze, though. Yes, it's still not informative enough. > > How many threads are in the process? Did you type "bt" when the Lisp > > thread was the current one? > > There are 121 threads (IIUC). Is it normal to have so many threads? What are they doing? > I don't konw what is the Lisp thread, sorry. That's usually the thread you get when you type "thread 1" at GDB prompt. But let's see what all those threads do, so please type this: (gdb) thread apply all bt and post the results here. > Thread 1 "emacs" hit Breakpoint 1, terminate_due_to_signal (sig=11, > backtrace_limit=40) at emacs.c:370 > 370 { > (gdb) bt > #0 terminate_due_to_signal (sig=11, backtrace_limit=40) at emacs.c:370 > #1 0x00000001004f134e in handle_fatal_signal (sig=sig@entry=11) > at sysdep.c:1793 > #2 0x00000001004f153f in deliver_thread_signal (sig=sig@entry=11, > handler=0x1004f1340 <handle_fatal_signal>) at sysdep.c:1767 > #3 0x00000001004f159f in deliver_fatal_thread_signal (sig=11) at sysdep.c:1805 > #4 handle_sigsegv (sig=11, siginfo=0x1009dea10 <sigsegv_stack+32464>, > arg=<optimized out>) at sysdep.c:1890 > #5 0x000000018005f65a in altstack_wrapper (sig=<optimized out>, > siginfo=<optimized out>, sigctx=0xffffde50, > handler=0x1004f1580 <handle_sigsegv>) > at /usr/src/debug/cygwin-3.0.6-1/winsup/cygwin/exceptions.cc:1595 > #6 0x0000000180062dfa in _cygtls::call_signal_handler (this=0xffffce00) > at /usr/src/debug/cygwin-3.0.6-1/winsup/cygwin/exceptions.cc:1777 > #7 0x0000000000000000 in ?? () > Backtrace stopped: previous frame inner to this frame (corrupt stack?) I don't think this is the thread we are interested in. Let's see what "thread apply all bt" shows us. > Lisp Backtrace: > "x-show-tip" (0xffffac20) > "tooltip-show" (0xffffaf60) > "tooltip-help-tips" (0xffffb2c8) > "run-hook-with-args-until-success" (0xffffb2c0) > "tooltip-timeout" (0xffffb670) > "apply" (0xffffb668) > "timer-event-handler" (0xffffb9a8) > (gdb) This seems to be related to showing a tooltip. Do the crashes generally happen when Emacs is supposed to display a tooltip? Also, you say that the 3 commits you identified cause the problem, but those commits are related to the function x-display-monitor-attributes-list. Is this function being called in your usage pattern? Can you put a breakpoint inside that function and see if it breaks, and how often? Thanks. ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#35204: 27.0.50; Crash on Cygwin 2019-04-10 14:37 ` Eli Zaretskii @ 2019-04-11 2:31 ` Katsumi Yamaoka 2019-04-11 13:19 ` Eli Zaretskii 0 siblings, 1 reply; 16+ messages in thread From: Katsumi Yamaoka @ 2019-04-11 2:31 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 35204 [-- Attachment #1: Type: text/plain, Size: 2348 bytes --] On Wed, 10 Apr 2019 17:37:58 +0300, Eli Zaretskii wrote: >> I did so. I rebuilt separately Emacs from scratch from today's >> Git repo with no modification on the source using these configure >> options >> configure --verbose --with-x-toolkit=gtk3 >> (I detached "CFLAGS=-O0") > Does it mean you used "CFLAGS=-O0", or does it mean you did NOT use > it? It is better to use it, together with -g3, as that makes > debugging easier. At that time I didn't use CFLAGS=-O0 so as to exclude anything special, though I'm not sure it is worthwhile. Today I tried building two types; one uses CFLAGS=-O0 and the other doesn't. The difference between them is that with the one built *with* CFLAGS=-O0 the gdb command `source .gdbinit' ends up with this error: (gdb) source .gdbinit SIGINT is used by the debugger. Are you sure you want to change it? (y or n) [answered Y; input not from terminal] DISPLAY = :0.0 TERM = xterm Breakpoint 1 at 0x10054a66a .gdbinit:1228: Error in sourced command file: No symbol "defined_HAVE_X_WINDOWS" in current context. [...] >> There are 121 threads (IIUC). > Is it normal to have so many threads? What are they doing? It's a result of I did many things to break Emacs since it can't seem to die soon. But I got a good means to break Emacs at once, that is to eval: (x-display-monitor-attributes-list) >> I don't konw what is the Lisp thread, sorry. > That's usually the thread you get when you type "thread 1" at GDB > prompt. But let's see what all those threads do, so please type this: > (gdb) thread apply all bt > and post the results here. Thanks. Attached the one fetched with Emacs built without CFLAGS=-O0 (it has no notably difference from the one fetched with Emacs built with CFLAGS=-O0). Note that gdb crashes when the `thread apply all bt' command is invoked. [...] > Also, you say that the 3 commits you identified cause the problem, but > those commits are related to the function > x-display-monitor-attributes-list. Is this function being called in > your usage pattern? Can you put a breakpoint inside that function and > see if it breaks, and how often? I think I use intendedly neither such a raw function nor functions using it. Moreover the crash happens not when manipurating a frame. So, the attached GDB log might not mention to the one I'm troubled with. Regards, [-- Attachment #2: Type: application/octet-stream, Size: 3607 bytes --] With Emacs build with: ./configure --verbose --with-x-toolkit=gtk3; make GNU gdb (GDB) (Cygwin 8.1.1-1) 8.1.1 Copyright (C) 2018 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-cygwin". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from emacs.exe...done. warning: File "/Work/emacs-27.0.50/src/.gdbinit" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load". To enable execution of this file add add-auto-load-safe-path /Work/emacs-27.0.50/src/.gdbinit line to your configuration file "/home/yamaoka/.gdbinit". To completely disable this security protection add set auto-load safe-path / line to your configuration file "/home/yamaoka/.gdbinit". For more information about this security protection see the "Auto-loading safe path" section in the GDB manual. E.g., run from the shell: info "(gdb)Auto-loading safe path" (gdb) source .gdbinit SIGINT is used by the debugger. Are you sure you want to change it? (y or n) [answered Y; input not from terminal] DISPLAY = :0.0 TERM = xterm Breakpoint 1 at 0x1004d92b0: file emacs.c, line 370. Breakpoint 2 at 0x1004aa610: file xterm.c, line 9979. (gdb) r -Q Starting program: /Work/emacs-27.0.50/src/emacs.exe -Q [New Thread 2120.0x1bc0] [New Thread 2120.0x2950] [New Thread 2120.0xcc8] [New Thread 2120.0x2be4] [New Thread 2120.0x1ff8] [New Thread 2120.0x1880] [New Thread 2120.0xab8] [New Thread 2120.0x1744] [New Thread 2120.0x1274] [New Thread 2120.0x1ea8] [New Thread 2120.0x17a0] [New Thread 2120.0xe50] [New Thread 2120.0xcd8] ** (emacs:25818): WARNING **: Error retrieving accessibility bus address: org.freedesktop.DBus.Error.NoReply: Message recipient disconnected from message bus without replying [New Thread 2120.0x550] [New Thread 2120.0x188] [New Thread 2120.0xd28] [New Thread 2120.0x1c04] [New Thread 2120.0x1378] Thread 1 "emacs" hit Breakpoint 1, terminate_due_to_signal (sig=11, backtrace_limit=40) at emacs.c:370 370 { (gdb) thread apply all bt Thread 18 (Thread 2120.0x1378): #0 0x00007ffb6af0f714 in ntdll!ZwWaitForSingleObject () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll #1 0x00007ffb67b483d3 in WaitForSingleObjectEx () from /cygdrive/c/WINDOWS/System32/KERNELBASE.dll #2 0x0000000180047961 in cygthread::stub ( arg=arg@entry=0x18021e4e8 <threads+616>) at /usr/src/debug/cygwin-3.0.6-1/winsup/cygwin/cygthread.cc:112 #3 0x0000000180048353 in _cygtls::call2 (this=0x9b8ce00, func=0x1800478a0 <cygthread::stub(void*)>, arg=0x18021e4e8 <threads+616>, buf=buf@entry=0x9b8cd20) at /usr/src/debug/cygwin-3.0.6-1/winsup/cygwin/cygtls.cc:40 #4 0x0000000180048404 in _cygtls::call (func=<optimized out>, arg=<optimized out>) at /usr/src/debug/cygwin-3.0.6-1/winsup/cygwin/cygtls.cc:27 #5 0x00007ffb68667974 in KERNEL32!BaseThreadInitThunk () from /cygdrive/c/WINDOWS/System32/KERNEL32.DLL #6 0x00007ffb6aeda271 in ntdll!RtlUserThreadStart () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll #7 0x0000000000000000 in ?? () Segmentation fault (core dumped) ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#35204: 27.0.50; Crash on Cygwin 2019-04-11 2:31 ` Katsumi Yamaoka @ 2019-04-11 13:19 ` Eli Zaretskii 2019-04-11 23:02 ` Katsumi Yamaoka 0 siblings, 1 reply; 16+ messages in thread From: Eli Zaretskii @ 2019-04-11 13:19 UTC (permalink / raw) To: Katsumi Yamaoka; +Cc: 35204 > Date: Thu, 11 Apr 2019 11:31:11 +0900 > From: Katsumi Yamaoka <yamaoka@jpl.org> > Cc: 35204@debbugs.gnu.org > > >> configure --verbose --with-x-toolkit=gtk3 > > >> (I detached "CFLAGS=-O0") > > > Does it mean you used "CFLAGS=-O0", or does it mean you did NOT use > > it? It is better to use it, together with -g3, as that makes > > debugging easier. > > At that time I didn't use CFLAGS=-O0 so as to exclude anything > special, though I'm not sure it is worthwhile. Today I tried > building two types; one uses CFLAGS=-O0 and the other doesn't. > The difference between them is that with the one built *with* > CFLAGS=-O0 the gdb command `source .gdbinit' ends up with this > error: > > (gdb) source .gdbinit > SIGINT is used by the debugger. > Are you sure you want to change it? (y or n) [answered Y; input not from terminal] > DISPLAY = :0.0 > TERM = xterm > Breakpoint 1 at 0x10054a66a > .gdbinit:1228: Error in sourced command file: > No symbol "defined_HAVE_X_WINDOWS" in current context. This is why I suggested to use CFLAGS='-O0 -g3', please try that next. > > Is it normal to have so many threads? What are they doing? > > It's a result of I did many things to break Emacs since it can't > seem to die soon. But I got a good means to break Emacs at once, > that is to eval: (x-display-monitor-attributes-list) So please use this method from now on, to trigger the crash. It is important to have consistency in this. > >> I don't konw what is the Lisp thread, sorry. > > > That's usually the thread you get when you type "thread 1" at GDB > > prompt. But let's see what all those threads do, so please type this: > > > (gdb) thread apply all bt > > > and post the results here. > > Thanks. Attached the one fetched with Emacs built without > CFLAGS=-O0 (it has no notably difference from the one fetched > with Emacs built with CFLAGS=-O0). Note that gdb crashes when > the `thread apply all bt' command is invoked. This is still not the information we need. Since "thread apply all" crashes, please try this alternative: (gdb) thread 1 (gdb) bt And please separately do also this: (gdb) info threads and post the results. Thanks. P.S. I see you are using Cygwin 3.0.6, could it be a bug in Cygwin itself? Is there a newer version of Cygwin? ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#35204: 27.0.50; Crash on Cygwin 2019-04-11 13:19 ` Eli Zaretskii @ 2019-04-11 23:02 ` Katsumi Yamaoka 2019-04-12 1:01 ` Katsumi Yamaoka 2019-04-12 7:11 ` Eli Zaretskii 0 siblings, 2 replies; 16+ messages in thread From: Katsumi Yamaoka @ 2019-04-11 23:02 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 35204 [-- Attachment #1: Type: text/plain, Size: 907 bytes --] On Thu, 11 Apr 2019 16:19:28 +0300, Eli Zaretskii wrote: >> (gdb) source .gdbinit [...] >> .gdbinit:1228: Error in sourced command file: >> No symbol "defined_HAVE_X_WINDOWS" in current context. > This is why I suggested to use CFLAGS='-O0 -g3', please try that next. I did so. [...] > This is still not the information we need. Since "thread apply all" > crashes, please try this alternative: > (gdb) thread 1 > (gdb) bt The result is in the first attachment, and > And please separately do also this: > (gdb) info threads that of it is in the second attachment. > and post the results. > P.S. I see you are using Cygwin 3.0.6, could it be a bug in Cygwin > itself? Is there a newer version of Cygwin? No one mentions Emacs of git master in the Cygwin list so far. I tried to update my Cygwin installation, but setup.exe said it is up-to-date. So, I'll try the snapshot later. Thanks. [-- Attachment #2: Type: application/octet-stream, Size: 3540 bytes --] GNU gdb (GDB) (Cygwin 8.1.1-1) 8.1.1 Copyright (C) 2018 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-cygwin". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from emacs.exe...done. warning: File "/Work/emacs-27.0.50/src/.gdbinit" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load". To enable execution of this file add add-auto-load-safe-path /Work/emacs-27.0.50/src/.gdbinit line to your configuration file "/home/yamaoka/.gdbinit". To completely disable this security protection add set auto-load safe-path / line to your configuration file "/home/yamaoka/.gdbinit". For more information about this security protection see the "Auto-loading safe path" section in the GDB manual. E.g., run from the shell: info "(gdb)Auto-loading safe path" (gdb) source .gdbinit SIGINT is used by the debugger. Are you sure you want to change it? (y or n) [answered Y; input not from terminal] DISPLAY = :0.0 TERM = xterm Breakpoint 1 at 0x10054a670: file emacs.c, line 371. Breakpoint 2 at 0x100513717: file xterm.c, line 9986. (gdb) r -Q Starting program: /Work/emacs-27.0.50/src/emacs.exe -Q [New Thread 416.0x297c] [New Thread 416.0xdd8] [New Thread 416.0x17cc] [New Thread 416.0x28e0] [New Thread 416.0x9e8] [New Thread 416.0x2510] [New Thread 416.0x1650] [New Thread 416.0x221c] [New Thread 416.0x2158] [New Thread 416.0x21c8] [New Thread 416.0x3b0] [New Thread 416.0x10cc] [New Thread 416.0x104c] ** (emacs:13102): WARNING **: Error retrieving accessibility bus address: org.freedesktop.DBus.Error.NoReply: Message recipient disconnected from message bus without replying [New Thread 416.0x238c] [New Thread 416.0xf54] [New Thread 416.0x16d4] [New Thread 416.0xc90] [New Thread 416.0x25c8] Thread 1 "emacs" hit Breakpoint 1, terminate_due_to_signal (sig=11, backtrace_limit=40) at emacs.c:371 371 signal (sig, SIG_DFL); (gdb) thread 1 [Switching to thread 1 (Thread 416.0x297c)] #0 terminate_due_to_signal (sig=11, backtrace_limit=40) at emacs.c:371 371 signal (sig, SIG_DFL); (gdb) bt #0 terminate_due_to_signal (sig=11, backtrace_limit=40) at emacs.c:371 #1 0x000000010057110d in handle_fatal_signal (sig=11) at sysdep.c:1793 #2 0x00000001005710e0 in deliver_thread_signal (sig=11, handler=0x1005710f5 <handle_fatal_signal>) at sysdep.c:1767 #3 0x0000000100571149 in deliver_fatal_thread_signal (sig=11) at sysdep.c:1805 #4 0x0000000100571361 in handle_sigsegv (sig=11, siginfo=0x100acfb70 <sigsegv_stack+32464>, arg=0xffffde50) at sysdep.c:1890 #5 0x000000018005f65a in altstack_wrapper (sig=<optimized out>, siginfo=<optimized out>, sigctx=0xffffde50, handler=0x1005712a5 <handle_sigsegv>) at /usr/src/debug/cygwin-3.0.6-1/winsup/cygwin/exceptions.cc:1595 #6 0x0000000180062dfa in _cygtls::call_signal_handler (this=0xffffce00) at /usr/src/debug/cygwin-3.0.6-1/winsup/cygwin/exceptions.cc:1777 #7 0x0000000000000000 in ?? () Segmentation fault (core dumped) [-- Attachment #3: Type: application/octet-stream, Size: 4877 bytes --] GNU gdb (GDB) (Cygwin 8.1.1-1) 8.1.1 Copyright (C) 2018 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-cygwin". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from emacs.exe...done. warning: File "/Work/emacs-27.0.50/src/.gdbinit" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load". To enable execution of this file add add-auto-load-safe-path /Work/emacs-27.0.50/src/.gdbinit line to your configuration file "/home/yamaoka/.gdbinit". To completely disable this security protection add set auto-load safe-path / line to your configuration file "/home/yamaoka/.gdbinit". For more information about this security protection see the "Auto-loading safe path" section in the GDB manual. E.g., run from the shell: info "(gdb)Auto-loading safe path" (gdb) source .gdbinit SIGINT is used by the debugger. Are you sure you want to change it? (y or n) [answered Y; input not from terminal] DISPLAY = :0.0 TERM = xterm Breakpoint 1 at 0x10054a670: file emacs.c, line 371. Breakpoint 2 at 0x100513717: file xterm.c, line 9986. (gdb) r -Q Starting program: /Work/emacs-27.0.50/src/emacs.exe -Q [New Thread 5348.0x1ee0] [New Thread 5348.0x5a0] [New Thread 5348.0x548] [New Thread 5348.0xce4] [New Thread 5348.0x2990] [New Thread 5348.0xc8] [New Thread 5348.0x2388] [New Thread 5348.0xd64] [New Thread 5348.0x1df0] [New Thread 5348.0x2af4] [New Thread 5348.0x2180] [New Thread 5348.0x22cc] [New Thread 5348.0x1c58] ** (emacs:13111): WARNING **: Error retrieving accessibility bus address: org.freedesktop.DBus.Error.NoReply: Message recipient disconnected from message bus without replying [New Thread 5348.0x2ac4] [New Thread 5348.0x97c] [New Thread 5348.0x2aa8] [New Thread 5348.0x178c] [New Thread 5348.0xa84] Thread 1 "emacs" hit Breakpoint 1, terminate_due_to_signal (sig=11, backtrace_limit=40) at emacs.c:371 371 signal (sig, SIG_DFL); (gdb) info threads Id Target Id Frame * 1 Thread 5348.0x1ee0 "emacs" terminate_due_to_signal (sig=11, backtrace_limit=40) at emacs.c:371 2 Thread 5348.0x5a0 0x00007ffa6a963004 in ntdll!ZwWaitForWorkViaWorkerFactory () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll 3 Thread 5348.0x548 0x00007ffa6a963004 in ntdll!ZwWaitForWorkViaWorkerFactory () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll 4 Thread 5348.0xce4 0x00007ffa6a963004 in ntdll!ZwWaitForWorkViaWorkerFactory () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll 5 Thread 5348.0x2990 "sig" 0x00007ffa6a95f754 in ntdll!ZwReadFile () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll 6 Thread 5348.0xc8 0x00007ffa6a963004 in ntdll!ZwWaitForWorkViaWorkerFactory () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll 7 Thread 5348.0x2388 0x00007ffa6a963004 in ntdll!ZwWaitForWorkViaWorkerFactory () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll 8 Thread 5348.0xd64 "timerfd" 0x00007ffa67469904 in win32u!NtUserMsgWaitForMultipleObjectsEx () from /cygdrive/c/WINDOWS/System32/win32u.dll 9 Thread 5348.0x1df0 "gmain" 0x00007ffa6a9601e4 in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll 10 Thread 5348.0x2af4 "pipesel" 0x00007ffa6a95fd14 in ntdll!ZwDelayExecution () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll 11 Thread 5348.0x2180 0x00007ffa6a95f7b4 in ntdll!ZwRemoveIoCompletion () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll 12 Thread 5348.0x22cc "pipesel" 0x00007ffa6a95fd14 in ntdll!ZwDelayExecution () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll 13 Thread 5348.0x1c58 "socksel" 0x00007ffa6a95f714 in ntdll!ZwWaitForSingleObject () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll 14 Thread 5348.0x2ac4 "dconf worker" 0x00007ffa6a9601e4 in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll 15 Thread 5348.0x97c "pipesel" 0x00007ffa6a95fd14 in ntdll!ZwDelayExecution () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll 16 Thread 5348.0x2aa8 "gdbus" 0x00007ffa6a9601e4 in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll 17 Thread 5348.0x178c "socksel" 0x00007ffa6a9601e4 in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll 18 Thread 5348.0xa84 "socksel" 0x00007ffa6a95f714 in ntdll!ZwWaitForSingleObject () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll (gdb) ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#35204: 27.0.50; Crash on Cygwin 2019-04-11 23:02 ` Katsumi Yamaoka @ 2019-04-12 1:01 ` Katsumi Yamaoka 2019-04-12 7:11 ` Eli Zaretskii 1 sibling, 0 replies; 16+ messages in thread From: Katsumi Yamaoka @ 2019-04-12 1:01 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 35204 On Fri, 12 Apr 2019 08:02:33 +0900, Katsumi Yamaoka wrote: >> P.S. I see you are using Cygwin 3.0.6, could it be a bug in Cygwin >> itself? Is there a newer version of Cygwin? > No one mentions Emacs of git master in the Cygwin list so far. > I tried to update my Cygwin installation, but setup.exe said > it is up-to-date. So, I'll try the snapshot later. Nothing seems to change with Emacs rebuilt on: uname -a CYGWIN_NT-10.0 localhost 3.1.0s(0.338/5/3) 2019-04-10 20:49 x86_64 Cygwin Regards, ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#35204: 27.0.50; Crash on Cygwin 2019-04-11 23:02 ` Katsumi Yamaoka 2019-04-12 1:01 ` Katsumi Yamaoka @ 2019-04-12 7:11 ` Eli Zaretskii 2019-04-12 8:00 ` Katsumi Yamaoka 2019-04-12 14:54 ` Ken Brown 1 sibling, 2 replies; 16+ messages in thread From: Eli Zaretskii @ 2019-04-12 7:11 UTC (permalink / raw) To: Katsumi Yamaoka, Ken Brown; +Cc: 35204 > Date: Fri, 12 Apr 2019 08:02:33 +0900 > From: Katsumi Yamaoka <yamaoka@jpl.org> > Cc: 35204@debbugs.gnu.org > > > (gdb) thread 1 > > (gdb) bt > > The result is in the first attachment, and > > > And please separately do also this: > > > (gdb) info threads > > that of it is in the second attachment. > > > and post the results. It's strange. Looks like there's a bug in your GDB, because it dumps core in this case. I also don't understand why the backtrace ends in the exception handler, it sounds like GDB is not given the first opportunity to handle an exception, as it should? Maybe try upgrading to GDB 8.2, if its Cygwin port is available? Ken, could you please chime in? It is strange that this problem only affects the Cygwin build, and no other bug report points to that change from other GTK builds, including not from other Cygwin users. So it sounds like a Cygwin problem, perhaps triggered by something on Yamaoka-san's machine, but the fact that GDB crashes doesn't allow any reasonable way of investigating the problem past the exception handler. I don't know what to do next. ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#35204: 27.0.50; Crash on Cygwin 2019-04-12 7:11 ` Eli Zaretskii @ 2019-04-12 8:00 ` Katsumi Yamaoka 2019-04-12 14:54 ` Ken Brown 1 sibling, 0 replies; 16+ messages in thread From: Katsumi Yamaoka @ 2019-04-12 8:00 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 35204 On Fri, 12 Apr 2019 10:11:12 +0300, Eli Zaretskii wrote: > Maybe try upgrading to GDB 8.2, if its Cygwin port is available? I'm now trying building GDB 8.2.1 from scratch but time to depart from the office where I have Cygwin installed has come (the configure process is still running as if it is endless). So, I'll try it again next week. Thanks anyway. ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#35204: 27.0.50; Crash on Cygwin 2019-04-12 7:11 ` Eli Zaretskii 2019-04-12 8:00 ` Katsumi Yamaoka @ 2019-04-12 14:54 ` Ken Brown 2019-04-12 15:15 ` Eli Zaretskii 1 sibling, 1 reply; 16+ messages in thread From: Ken Brown @ 2019-04-12 14:54 UTC (permalink / raw) To: Eli Zaretskii, Katsumi Yamaoka; +Cc: 35204@debbugs.gnu.org On 4/12/2019 3:11 AM, Eli Zaretskii wrote: > Ken, could you please chime in? It is strange that this problem only > affects the Cygwin build, and no other bug report points to that > change from other GTK builds Sorry for not chiming in sooner. I saw the bug report but was busy with other things. I can replicate the crash on my system, but reverting only a tiny part of the commits in question seems to fix it, in the sense that I can successfully evaluate x-display-monitor-attributes-list: diff --git a/src/xfns.c b/src/xfns.c index 13f66f0718..3e4d037716 100644 --- a/src/xfns.c +++ b/src/xfns.c @@ -5030,7 +5030,7 @@ Internal use only, use `display-monitor-attributes-list' instead. */) mi->mm_height = height_mm; #if GTK_CHECK_VERSION (3, 22, 0) - mi->name = xstrdup (gdk_monitor_get_model (monitor)); + mi->name = g_strdup (gdk_monitor_get_model (monitor)); #elif GTK_CHECK_VERSION (2, 14, 0) mi->name = gdk_screen_get_monitor_plug_name (gscreen, i); #endif I don't know enough about GTK to know why this fixes it or why no one else has reported the problem. It's hard to see why this would be specific to Cygwin. Ken ^ permalink raw reply related [flat|nested] 16+ messages in thread
* bug#35204: 27.0.50; Crash on Cygwin 2019-04-12 14:54 ` Ken Brown @ 2019-04-12 15:15 ` Eli Zaretskii 2019-04-13 22:26 ` Basil L. Contovounesios 0 siblings, 1 reply; 16+ messages in thread From: Eli Zaretskii @ 2019-04-12 15:15 UTC (permalink / raw) To: Ken Brown; +Cc: yamaoka, 35204 > From: Ken Brown <kbrown@cornell.edu> > CC: "35204@debbugs.gnu.org" <35204@debbugs.gnu.org> > Date: Fri, 12 Apr 2019 14:54:21 +0000 > > I can replicate the crash on my system, but reverting only a tiny part of the > commits in question seems to fix it, in the sense that I can successfully > evaluate x-display-monitor-attributes-list: > > diff --git a/src/xfns.c b/src/xfns.c > index 13f66f0718..3e4d037716 100644 > --- a/src/xfns.c > +++ b/src/xfns.c > @@ -5030,7 +5030,7 @@ Internal use only, use `display-monitor-attributes-list' > instead. */) > mi->mm_height = height_mm; > > #if GTK_CHECK_VERSION (3, 22, 0) > - mi->name = xstrdup (gdk_monitor_get_model (monitor)); > + mi->name = g_strdup (gdk_monitor_get_model (monitor)); > #elif GTK_CHECK_VERSION (2, 14, 0) > mi->name = gdk_screen_get_monitor_plug_name (gscreen, i); > #endif > > I don't know enough about GTK to know why this fixes it or why no one else has > reported the problem. It's hard to see why this would be specific to Cygwin. We release storage of mi->name (in free_monitors) by calling xfree, so I'm surprised g_strdup is right here, as that is documented to need g_free instead. I wonder what am I missing. ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#35204: 27.0.50; Crash on Cygwin 2019-04-12 15:15 ` Eli Zaretskii @ 2019-04-13 22:26 ` Basil L. Contovounesios 2019-04-13 22:50 ` Alex Gramiak 0 siblings, 1 reply; 16+ messages in thread From: Basil L. Contovounesios @ 2019-04-13 22:26 UTC (permalink / raw) To: Eli Zaretskii; +Cc: yamaoka, 35204 Eli Zaretskii <eliz@gnu.org> writes: >> From: Ken Brown <kbrown@cornell.edu> >> CC: "35204@debbugs.gnu.org" <35204@debbugs.gnu.org> >> Date: Fri, 12 Apr 2019 14:54:21 +0000 >> >> I can replicate the crash on my system, but reverting only a tiny part of the >> commits in question seems to fix it, in the sense that I can successfully >> evaluate x-display-monitor-attributes-list: >> >> diff --git a/src/xfns.c b/src/xfns.c >> index 13f66f0718..3e4d037716 100644 >> --- a/src/xfns.c >> +++ b/src/xfns.c >> @@ -5030,7 +5030,7 @@ Internal use only, use `display-monitor-attributes-list' >> instead. */) >> mi->mm_height = height_mm; >> >> #if GTK_CHECK_VERSION (3, 22, 0) >> - mi->name = xstrdup (gdk_monitor_get_model (monitor)); >> + mi->name = g_strdup (gdk_monitor_get_model (monitor)); >> #elif GTK_CHECK_VERSION (2, 14, 0) >> mi->name = gdk_screen_get_monitor_plug_name (gscreen, i); >> #endif >> >> I don't know enough about GTK to know why this fixes it or why no one else has >> reported the problem. It's hard to see why this would be specific to Cygwin. > > We release storage of mi->name (in free_monitors) by calling xfree, so > I'm surprised g_strdup is right here, as that is documented to need > g_free instead. I wonder what am I missing. I think the missing clue is in bug#35259: gdk_monitor_get_model may return NULL, which g_strdup gladly accepts, but xstrdup does not. https://debbugs.gnu.org/35259 -- Basil ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#35204: 27.0.50; Crash on Cygwin 2019-04-13 22:26 ` Basil L. Contovounesios @ 2019-04-13 22:50 ` Alex Gramiak 2019-04-14 2:15 ` Ken Brown 0 siblings, 1 reply; 16+ messages in thread From: Alex Gramiak @ 2019-04-13 22:50 UTC (permalink / raw) To: Basil L. Contovounesios; +Cc: yamaoka, 35204 "Basil L. Contovounesios" <contovob@tcd.ie> writes: > Eli Zaretskii <eliz@gnu.org> writes: > >>> From: Ken Brown <kbrown@cornell.edu> >>> CC: "35204@debbugs.gnu.org" <35204@debbugs.gnu.org> >>> Date: Fri, 12 Apr 2019 14:54:21 +0000 >>> >>> I can replicate the crash on my system, but reverting only a tiny part of the >>> commits in question seems to fix it, in the sense that I can successfully >>> evaluate x-display-monitor-attributes-list: >>> >>> diff --git a/src/xfns.c b/src/xfns.c >>> index 13f66f0718..3e4d037716 100644 >>> --- a/src/xfns.c >>> +++ b/src/xfns.c >>> @@ -5030,7 +5030,7 @@ Internal use only, use `display-monitor-attributes-list' >>> instead. */) >>> mi->mm_height = height_mm; >>> >>> #if GTK_CHECK_VERSION (3, 22, 0) >>> - mi->name = xstrdup (gdk_monitor_get_model (monitor)); >>> + mi->name = g_strdup (gdk_monitor_get_model (monitor)); >>> #elif GTK_CHECK_VERSION (2, 14, 0) >>> mi->name = gdk_screen_get_monitor_plug_name (gscreen, i); >>> #endif >>> >>> I don't know enough about GTK to know why this fixes it or why no one else has >>> reported the problem. It's hard to see why this would be specific to Cygwin. >> >> We release storage of mi->name (in free_monitors) by calling xfree, so >> I'm surprised g_strdup is right here, as that is documented to need >> g_free instead. I wonder what am I missing. > > I think the missing clue is in bug#35259: gdk_monitor_get_model may > return NULL, which g_strdup gladly accepts, but xstrdup does not. > > https://debbugs.gnu.org/35259 Yeah, this is it. I suppose the reason why it wasn't reported before is that it depends on GTK not being able to grab your monitor name, which is hardware-dependent. I must have assumed that using g_strdup meant that I didn't need to check for NULL. It should be fixed with commit 7308c2edf, so please test again. Sorry for the inconvenience. ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#35204: 27.0.50; Crash on Cygwin 2019-04-13 22:50 ` Alex Gramiak @ 2019-04-14 2:15 ` Ken Brown 2019-04-14 23:26 ` Katsumi Yamaoka 0 siblings, 1 reply; 16+ messages in thread From: Ken Brown @ 2019-04-14 2:15 UTC (permalink / raw) To: Alex Gramiak, Basil L. Contovounesios Cc: yamaoka@jpl.org, 35204@debbugs.gnu.org On 4/13/2019 6:50 PM, Alex Gramiak wrote: > "Basil L. Contovounesios" <contovob@tcd.ie> writes: >> I think the missing clue is in bug#35259: gdk_monitor_get_model may >> return NULL, which g_strdup gladly accepts, but xstrdup does not. >> >> https://debbugs.gnu.org/35259 > > Yeah, this is it. I suppose the reason why it wasn't reported before is > that it depends on GTK not being able to grab your monitor name, which > is hardware-dependent. I must have assumed that using g_strdup meant > that I didn't need to check for NULL. > > It should be fixed with commit 7308c2edf, so please test again. Sorry > for the inconvenience. Yes, that fixes it for me. Thanks. Ken ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#35204: 27.0.50; Crash on Cygwin 2019-04-14 2:15 ` Ken Brown @ 2019-04-14 23:26 ` Katsumi Yamaoka 0 siblings, 0 replies; 16+ messages in thread From: Katsumi Yamaoka @ 2019-04-14 23:26 UTC (permalink / raw) To: Alex Gramiak; +Cc: Basil L. Contovounesios, 35204-done On Sun, 14 Apr 2019 02:15:00 +0000, Ken Brown wrote: >> It should be fixed with commit 7308c2edf, so please test again. Sorry >> for the inconvenience. > Yes, that fixes it for me. Emacs built from the fresh git master works fine. Thanks a lot! ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2019-04-14 23:26 UTC | newest] Thread overview: 16+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2019-04-09 8:07 bug#35204: 27.0.50; Crash on Cygwin Katsumi Yamaoka 2019-04-09 9:47 ` Eli Zaretskii 2019-04-10 4:54 ` Katsumi Yamaoka 2019-04-10 14:37 ` Eli Zaretskii 2019-04-11 2:31 ` Katsumi Yamaoka 2019-04-11 13:19 ` Eli Zaretskii 2019-04-11 23:02 ` Katsumi Yamaoka 2019-04-12 1:01 ` Katsumi Yamaoka 2019-04-12 7:11 ` Eli Zaretskii 2019-04-12 8:00 ` Katsumi Yamaoka 2019-04-12 14:54 ` Ken Brown 2019-04-12 15:15 ` Eli Zaretskii 2019-04-13 22:26 ` Basil L. Contovounesios 2019-04-13 22:50 ` Alex Gramiak 2019-04-14 2:15 ` Ken Brown 2019-04-14 23:26 ` Katsumi Yamaoka
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.