bug#35204: 27.0.50; Crash on Cygwin

[Katsumi Yamaoka]

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.

binvzY6szI0Vm.bin
Description: Binary data