bug#35204: 27.0.50; Crash on Cygwin

[Katsumi Yamaoka <yamaoka@jpl.org>]

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