bug#35204: 27.0.50; Crash on Cygwin

bug#35204: 27.0.50; Crash on Cygwin

[Katsumi Yamaoka]

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,

bug#35204: 27.0.50; Crash on Cygwin

[Eli Zaretskii]

> 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?

bug#35204: 27.0.50; Crash on Cygwin

[Katsumi Yamaoka]

[-- 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) 

bug#35204: 27.0.50; Crash on Cygwin

[Eli Zaretskii]

> 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.

bug#35204: 27.0.50; Crash on Cygwin

[Katsumi Yamaoka]

[-- 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) 

bug#35204: 27.0.50; Crash on Cygwin

[Eli Zaretskii]

> 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?

bug#35204: 27.0.50; Crash on Cygwin

[Katsumi Yamaoka]

[-- 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) 

bug#35204: 27.0.50; Crash on Cygwin

[Katsumi Yamaoka]

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,

bug#35204: 27.0.50; Crash on Cygwin

[Eli Zaretskii]

> 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.

bug#35204: 27.0.50; Crash on Cygwin

[Katsumi Yamaoka]

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.

bug#35204: 27.0.50; Crash on Cygwin

[Ken Brown]

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

bug#35204: 27.0.50; Crash on Cygwin

[Eli Zaretskii]

> 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.

bug#35204: 27.0.50; Crash on Cygwin

[Basil L. Contovounesios]

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

bug#35204: 27.0.50; Crash on Cygwin

[Alex Gramiak]

"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.

bug#35204: 27.0.50; Crash on Cygwin

[Ken Brown]

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

bug#35204: 27.0.50; Crash on Cygwin

[Katsumi Yamaoka]

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!