bug#35204: 27.0.50; Crash on Cygwin

[Katsumi Yamaoka]

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,

binxh6AlB8q_y.bin
Description: Binary data