bug#28268: 26.0.50; (MS Windows) crash on C-g after closing Git GUI

bug#28268: 26.0.50; (MS Windows) crash on C-g after closing Git GUI

[Richard Copley]

Emacs sometimes crashes when I type C-g just after closing a process.
I've only seen this happen after the following recipe using Magit on MS
Windows. (Not sure whether or not Magit is essential.)

Recipe:

Visit a git repo.
C-x g ; magit-status
! g   ; magit-run-popup, magit-run-git-gui
;; A nasty-looking window pops up (Git GUI, I presume). Close it.
C-g   ; Crashes.

The crash is a SIGTRAP and the stack trace of the faulting thread is
as follows:

#0  0x000007fefcb831f3 in KERNELBASE!DebugBreak ()
   from C:\Windows\system32\KernelBase.dll
No symbol table info available.
#1  0x0000000400244966 in emacs_abort () at w32fns.c:10931
        button = 6
#2  0x00000004001a74ce in signal_or_quit (error_symbol=..., data=...,
    keyboard_quit=true) at eval.c:1535
        conditions = {i = 8565584}
        string = {i = 51800}
        real_error_symbol = {i = 51800}
        clause = {i = 0}
        h = 0x0
#3  0x00000004001a7448 in quit () at eval.c:1513
No locals.
#4  0x00000004001a7379 in process_quit_flag () at eval.c:1460
        flag = {i = 60032}
#5  0x00000004001a73ce in maybe_quit () at eval.c:1483
No locals.
#6  0x000000040027d085 in waitpid (pid=10708, status=0x0, options=1)
    at w32proc.c:1452
        active = 0
        retval = 8566456
        nh = 1
        cp = 0x401bca5a0 <child_procs+288>
        cps = {0x401bca5a0 <child_procs+288>, 0xffffffffffffffff, 0x0, 0x1c,
          0x82b598, 0xffffffffffffffff, 0x4, 0x82b5f0, 0x7,
          0xffffffffffffd8f0, 0x48, 0x1, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
          0x0, 0x15c, 0x158, 0x1e0, 0x284, 0x258, 0x294, 0x3c, 0x0, 0x1, 0x0,
          0x1, 0x76d316e3 <WaitForMultipleObjectsEx+179>}
        wait_hnd = {0x258, 0x0, 0xebb7230, 0x100000001, 0x82b4a0,
          0x40010f048 <unblock_input+24>, 0x0, 0x1, 0x0, 0x0, 0x82b530,
          0x40025b3d4 <w32_read_socket+9323>, 0x82b5d0, 0x0, 0x0, 0x0, 0x0,
          0x0, 0x0, 0x100000000, 0x1c, 0x1c, 0xffffffff, 0x1, 0x1,
          0x600000006, 0x6, 0x0, 0x0, 0x1b, 0x1600000000,
          0x7fefcb51430 <KERNELBASE!GetCurrentProcess+64>}
        timeout_ms = 0
        dont_wait = 1
#7  0x0000000400122068 in get_child_status (child=10708, status=0x0,
    options=1, interruptible=false) at sysdep.c:397
        pid = 0
#8  0x0000000400122157 in child_status_changed (child=10708, status=0x0,
    options=0) at sysdep.c:443
No locals.
#9  0x000000040020a229 in handle_child_signal (sig=18) at process.c:7049
        deleted_pid = 10708
        all_pids_are_fixnums = false
        head = {i = 164145587}
        xpid = {i = 42834}
        tail = {i = 164145571}
        proc = {i = 0}
#10 0x0000000400122f97 in deliver_process_signal (sig=18,
    handler=0x40020a16d <handle_child_signal>) at sysdep.c:1659
        old_errno = 22
        on_main_thread = true
#11 0x000000040020a400 in deliver_child_signal (sig=18) at process.c:7098
No locals.
#12 0x000000040027ecc8 in sys_select (nfds=7, rfds=0x82c108, wfds=0x82c100,
    efds=0x0, timeout=0x82c0e0, ignored=0x0) at w32proc.c:2403
        orfds = {bits = {81, 0}}
        owfds = {bits = {0, 0}}
        timeout_ms = 1
        start_time = 979426646
        i = 7
        nh = 4
        nc = 2
        nr = 0
        active = 4
        cp = 0x401bca5a0 <child_procs+288>
        cps = {0x401bca5a0 <child_procs+288>, 0x401bca510 <child_procs+144>,
          0x82bd60, 0x0, 0x0, 0x0, 0x0, 0x0, 0x82bca0,
          0x4000f98ef <builtin_lisp_symbol+49>, 0x4006a5ee0 <lispsym>, 0x0,
          0x82bcc0, 0x4000f9bb9 <XSETCDR+25>, 0x846cdf3,
          0x4000fb21b <CHECK_LIST_END+36>, 0x0, 0x846cdf3, 0x82bd00,
          0x4000f9f14 <ASIZE+21>, 0x59a482e4, 0x1b4d6cf8, 0x82bd70,
          0x400196f4a <lisp_to_timespec+155>, 0x82bd90, 0x59a482e4,
          0x1b4d6cf8, 0x6fd4b, 0x0, 0x40022f219 <sys_mutex_unlock+25>, 0x0,
          0x82be80}
        wait_hnd = {0x15c, 0x158, 0x1e0, 0x284, 0x258, 0x294,
          0x0 <repeats 72 times>, 0x8, 0x7fefcb518da <ResetEvent+10>, 0x0,
          0x40025f912 <drain_message_queue+107>, 0x0, 0x82bc30, 0x0,
          0x40025f704 <get_next_msg+630>, 0x0, 0x0, 0x0, 0x0, 0x82bc30,
          0x40010f048 <unblock_input+24>, 0x0, 0x0, 0x0, 0x0}
        fdindex = {-1, 0, 4, 6, 0 <repeats 60 times>}
#13 0x000000040022e45e in really_call_select (arg=0x82bf40) at thread.c:566
        sa = 0x82bf40
        self = 0x4006b9a60 <main_thread>
        oldset = 4294967295
#14 0x00000004001829da in flush_stack_call_func (
    func=0x40022e3cc <really_call_select>, arg=0x82bf40) at alloc.c:5158
        end = 0x82be00
        self = 0x4006b9a60 <main_thread>
        sentry = {o = {__max_align_ll = 1503953635,
            __max_align_ld = <invalid float value>}}
#15 0x0000000000000000 in ?? ()
No symbol table info available.
Backtrace stopped: previous frame inner to this frame (corrupt stack?)





In GNU Emacs 26.0.50 (build 1, x86_64-w64-mingw32)
 of 2017-08-22 built on 60678UHB
Repository revision: 036a92eb006cc175d13ad7ada80225eb8340724d
Windowing system distributor 'Microsoft Corp.', version 6.1.7601
Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
<nil> <wheel-down> is undefined
<nil> <double-wheel-down> is undefined
<nil> <triple-wheel-down> is undefined

Configured using:
 'configure --prefix=/mingw64 --config-cache --with-modules
 --without-pop CFLAGS=-O2'

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND NOTIFY ACL GNUTLS LIBXML2 ZLIB
TOOLKIT_SCROLL_BARS MODULES

Important settings:
  value of $LANG: ENG
  locale-coding-system: cp1252

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message subr-x puny seq byte-opt gv
bytecomp byte-compile cconv cl-loaddefs cl-lib dired dired-loaddefs
format-spec rfc822 mml easymenu mml-sec password-cache epa derived epg
epg-config gnus-util rmail rmail-loaddefs mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils elec-pair time-date
mule-util tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel dos-w32 ls-lisp disp-table term/w32-win w32-win
w32-vars term/common-win tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow isearch timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame cl-generic cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932
hebrew greek romanian slovak czech european ethiopic indian cyrillic
chinese composite charscript charprop case-table epa-hook jka-cmpr-hook
help simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote w32notify w32 multi-tty make-network-process emacs)

Memory information:
((conses 16 98353 8762)
 (symbols 56 20130 1)
 (miscs 48 40 107)
 (strings 32 30128 1430)
 (string-bytes 1 780999)
 (vectors 16 14782)
 (vector-slots 8 489133 4992)
 (floats 8 53 142)
 (intervals 56 235 0)
 (buffers 992 12))

bug#28268: 26.0.50; (MS Windows) crash on C-g after closing Git GUI

[Eli Zaretskii]

> From: Richard Copley <rcopley@gmail.com>
> Date: Mon, 28 Aug 2017 22:10:56 +0100
> 
> Emacs sometimes crashes when I type C-g just after closing a process.
> I've only seen this happen after the following recipe using Magit on MS
> Windows. (Not sure whether or not Magit is essential.)
> 
> Recipe:
> 
> Visit a git repo.
> C-x g ; magit-status
> ! g   ; magit-run-popup, magit-run-git-gui
> ;; A nasty-looking window pops up (Git GUI, I presume). Close it.
> C-g   ; Crashes.

I couldn't reproduce this here: the Git GUI didn't pop up for me.
Perhaps something is missing from the recipe ("C-x g" was also
unbound), or maybe it's because my Git is configured to be run only
from Git Bash, not from anywhere else on Windows.

However, I installed a change which might fix this problem.  Please
test the current master.  Also, just so I'm sure I didn't miss
anything, please post the backtrace from all the threads ("thread
apply all bt" at GDB prompt), from the binary where you get these
aborts.

Thanks.

bug#28268: Fwd: bug#28268: 26.0.50; (MS Windows) crash on C-g after closing Git GUI

[Richard Copley]

Apologies for dropping the list from the CC.

---------- Forwarded message ----------
From: Richard Copley <rcopley@gmail.com>
Date: 29 August 2017 at 17:01
Subject: Re: bug#28268: 26.0.50; (MS Windows) crash on C-g after closing Git GUI
To: Eli Zaretskii <eliz@gnu.org>


On 29 Aug 2017 16:18, "Eli Zaretskii" <eliz@gnu.org> wrote:

    > From: Richard Copley <rcopley@gmail.com>
    > Date: Mon, 28 Aug 2017 22:10:56 +0100
    >
    > Emacs sometimes crashes when I type C-g just after closing a process.
    > I've only seen this happen after the following recipe using Magit on MS
    > Windows. (Not sure whether or not Magit is essential.)
    >
    > Recipe:
    >
    > Visit a git repo.
    > C-x g ; magit-status
    > ! g   ; magit-run-popup, magit-run-git-gui
    > ;; A nasty-looking window pops up (Git GUI, I presume). Close it.
    > C-g   ; Crashes.

    I couldn't reproduce this here: the Git GUI didn't pop up for me.

Those commands are from the Magit package (available on MELPA).

    Perhaps something is missing from the recipe ("C-x g" was also
    unbound), or maybe it's because my Git is configured to be run only
    from Git Bash, not from anywhere else on Windows.

Via the PATH environment variable? (You declined the offer from the
Git For Windows installer to add stuff to your path?) Adding
"C:\Program Files\Git\cmd" to your path temporarily might work if
you want to test.

    However, I installed a change which might fix this problem.  Please
    test the current master.

Thanks. I will do that.

    Also, just so I'm sure I didn't miss
    anything, please post the backtrace from all the threads ("thread
    apply all bt" at GDB prompt), from the binary where you get these
    aborts.

I tried that, but only after sending this Emacs bug report.
Unfortunately it reliably crashes GDB (GDB bug report:
"https://sourceware.org/bugzilla/show_bug.cgi?id=22024").

bug#28268: 26.0.50; (MS Windows) crash on C-g after closing Git GUI

[Richard Copley]

On 29 August 2017 at 17:08, Richard Copley <rcopley@gmail.com> wrote:
> Apologies for dropping the list from the CC.
>
> ---------- Forwarded message ----------
> From: Richard Copley <rcopley@gmail.com>
> Date: 29 August 2017 at 17:01
> Subject: Re: bug#28268: 26.0.50; (MS Windows) crash on C-g after closing Git GUI
> To: Eli Zaretskii <eliz@gnu.org>
>
>
> On 29 Aug 2017 16:18, "Eli Zaretskii" <eliz@gnu.org> wrote:
>
>     > From: Richard Copley <rcopley@gmail.com>
>     > Date: Mon, 28 Aug 2017 22:10:56 +0100
>     >
>     >
>     > Visit a git repo.
>     > C-x g ; magit-status
>     > ! g   ; magit-run-popup, magit-run-git-gui
>     > ;; A nasty-looking window pops up (Git GUI, I presume). Close it.
>     > C-g   ; Crashes.
>
>
>     However, I installed a change which might fix this problem.  Please
>     test the current master.
>
> Thanks. I will do that.

It seems to have done the trick (there isn't an abort now, with that recipe).
Thanks again.

bug#28268: 26.0.50; (MS Windows) crash on C-g after closing Git GUI

[Richard Copley]

On 29 August 2017 at 17:09, Richard Copley <rcopley@gmail.com> wrote:
> On 29 August 2017 at 17:08, Richard Copley <rcopley@gmail.com> wrote:
>> Apologies for dropping the list from the CC.
>>
>> ---------- Forwarded message ----------
>> From: Richard Copley <rcopley@gmail.com>
>> Date: 29 August 2017 at 17:01
>> Subject: Re: bug#28268: 26.0.50; (MS Windows) crash on C-g after closing Git GUI
>> To: Eli Zaretskii <eliz@gnu.org>
>>
>>
>> On 29 Aug 2017 16:18, "Eli Zaretskii" <eliz@gnu.org> wrote:
>>
>>     > From: Richard Copley <rcopley@gmail.com>
>>     > Date: Mon, 28 Aug 2017 22:10:56 +0100
>>     >
>>     >
>>     > Visit a git repo.
>>     > C-x g ; magit-status
>>     > ! g   ; magit-run-popup, magit-run-git-gui
>>     > ;; A nasty-looking window pops up (Git GUI, I presume). Close it.
>>     > C-g   ; Crashes.
>>
>>
>>     However, I installed a change which might fix this problem.  Please
>>     test the current master.
>>
>> Thanks. I will do that.
>
> It seems to have done the trick (there isn't an abort now, with that recipe).
> Thanks again.

With the abort out of the picture, I notice that after launching Git GUI,
Emacs is consuming 100% of one CPU core.

Simplified recipe:
  (async-shell-command "c:\Program Files\git\cmd\git-gui.exe")

Presumably this also happens for programs other than Git GUI.
It isn't caused by your recent change (was already present before).

bug#28268: 26.0.50; (MS Windows) crash on C-g after closing Git GUI

[Noam Postavsky]

On Tue, Aug 29, 2017 at 11:18 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Recipe:
>>
>> Visit a git repo.
>> C-x g ; magit-status
>> ! g   ; magit-run-popup, magit-run-git-gui
>> ;; A nasty-looking window pops up (Git GUI, I presume). Close it.
>> C-g   ; Crashes.
>
> I couldn't reproduce this here: the Git GUI didn't pop up for me.
> Perhaps something is missing from the recipe ("C-x g" was also
> unbound), or maybe it's because my Git is configured to be run only
> from Git Bash, not from anywhere else on Windows.

I can't reproduce this here either. I need the patch at [1] to make
the GUI pop up, but even after applying that I get no crash.

(magit provides a Makefile such that "C-x g" is bound to magit-status
if you do 'make emacs-Q', although I don't normally use this on
Windows since I don't have 'make' on PATH)

[1]: https://patch-diff.githubusercontent.com/raw/magit/magit/pull/3155.patch

bug#28268: 26.0.50; (MS Windows) crash on C-g after closing Git GUI

[Richard Copley]

On 29 August 2017 at 17:38, Noam Postavsky
<npostavs@users.sourceforge.net> wrote:
> On Tue, Aug 29, 2017 at 11:18 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>>> Recipe:
>>>
>>> Visit a git repo.
>>> C-x g ; magit-status
>>> ! g   ; magit-run-popup, magit-run-git-gui
>>> ;; A nasty-looking window pops up (Git GUI, I presume). Close it.
>>> C-g   ; Crashes.
>>
>> I couldn't reproduce this here: the Git GUI didn't pop up for me.
>> Perhaps something is missing from the recipe ("C-x g" was also
>> unbound), or maybe it's because my Git is configured to be run only
>> from Git Bash, not from anywhere else on Windows.
>
> I can't reproduce this here either. I need the patch at [1] to make
> the GUI pop up, but even after applying that I get no crash.
>
> (magit provides a Makefile such that "C-x g" is bound to magit-status
> if you do 'make emacs-Q', although I don't normally use this on
> Windows since I don't have 'make' on PATH)
>
> [1]: https://patch-diff.githubusercontent.com/raw/magit/magit/pull/3155.patch

It doesn't turn out to be a Magit bug. Please try this recipe instead.

Evaluate this:

  (async-shell-command "\"C:\\Program Files\\Git\\cmd\\Git-GUI.exe\"")

Now type C-g in Emacs about 6 times to see the abort.

Note that the abort is fixed by Eli's recent change.

bug#28268: 26.0.50; (MS Windows) crash on C-g after closing Git GUI

[Eli Zaretskii]

> From: Richard Copley <rcopley@gmail.com>
> Date: Tue, 29 Aug 2017 17:09:46 +0100
> Cc: 28268@debbugs.gnu.org
> 
> >     However, I installed a change which might fix this problem.  Please
> >     test the current master.
> >
> > Thanks. I will do that.
> 
> It seems to have done the trick (there isn't an abort now, with that recipe).

Thanks for testing.

I'd still like to see the other threads, if possible.  I don't need to
see "bt full", so if "thread apply all bt" works, that is good enough.

bug#28268: 26.0.50; (MS Windows) crash on C-g after closing Git GUI

[Noam Postavsky]

On Tue, Aug 29, 2017 at 12:48 PM, Richard Copley <rcopley@gmail.com> wrote:
>
> It doesn't turn out to be a Magit bug. Please try this recipe instead.
>
> Evaluate this:
>
>   (async-shell-command "\"C:\\Program Files\\Git\\cmd\\Git-GUI.exe\"")
>
> Now type C-g in Emacs about 6 times to see the abort.

Ah, yes I see that too.

> Note that the abort is fixed by Eli's recent change.

Yes, and I see the high CPU use as well. Also, it seems that Emacs
fails to notice when the program exits (e.g., it shows as still
running in M-x list-processes).

By the way, a shell is not needed,

   (start-process "git gui" "*git gui*" "C:\\Program
Files\\Git\\cmd\\Git-GUI.exe")

shows the problem too.

bug#28268: 26.0.50; (MS Windows) crash on C-g after closing Git GUI

[Eli Zaretskii]

> From: Noam Postavsky <npostavs@users.sourceforge.net>
> Date: Tue, 29 Aug 2017 13:14:09 -0400
> Cc: Eli Zaretskii <eliz@gnu.org>, 28268@debbugs.gnu.org
> 
> Yes, and I see the high CPU use as well. Also, it seems that Emacs
> fails to notice when the program exits (e.g., it shows as still
> running in M-x list-processes).

It's not an "also", it's the reason _why_ Emacs spins.  I think it's a
race condition: git-gui.exe is a GUI program, so it releases the shell
and the shell exits before Emacs has a chance to set up the machinery
which watches the sub-process.

Of course, invoking a program such as git-gui asynchronously makes
very little sense anyway...

bug#28268: 26.0.50; (MS Windows) crash on C-g after closing Git GUI

[Eli Zaretskii]

> Date: Tue, 29 Aug 2017 20:25:52 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: rcopley@gmail.com, 28268@debbugs.gnu.org
> 
> git-gui.exe is a GUI program, so it releases the shell and the shell
> exits

Correction: git-gui.exe launches wish and exits.

bug#28268: 26.0.50; (MS Windows) crash on C-g after closing Git GUI

[Richard Copley]

[-- Attachment #1: Type: text/plain, Size: 996 bytes --]

On 29 August 2017 at 18:33, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Tue, 29 Aug 2017 20:25:52 +0300
>> From: Eli Zaretskii <eliz@gnu.org>
>> Cc: rcopley@gmail.com, 28268@debbugs.gnu.org
>>
>> git-gui.exe is a GUI program, so it releases the shell and the shell
>> exits
>
> Correction: git-gui.exe launches wish and exits.

Rebuilt Emacs from (Eli's fix)~1:

;; Git cmd/bash
git clean -xfd
git reset --hard b65cb981cc

;; Mingw64 bash
./autogen.sh
./configure --config-cache "CFLAGS=-O0 -g3 -ggdb"
make -j17 ;; I love this machine!

gdb --quiet -ex run --args src/emacs.exe -Q -eval \
"(start-process \"git gui\" \"*git gui*\" \
\"C:\\\\Program Files\\\\Git\\\\cmd\\\\Git-GUI.exe\")"

;; Close Git GUI, or not, doesn't matter

;; In Emacs
C-g ;; Repeat until the abort

;; In GDB in mingw64 bash
thread apply all
thread apply all bt full

The output is attached. Apparently the GDB crash happens if
you run GDB from the Windows (7 or 10) command prompt and
not if you run it from msys bash.

[-- Attachment #2: transcript.txt --]
[-- Type: text/plain, Size: 23602 bytes --]

$ gdb --quiet -ex run --args src/emacs.exe -Q -eval \
> "(start-process \"git gui\" \"*git gui*\" \
> \"C:\\\\Program Files\\\\Git\\\\cmd\\\\Git-GUI.exe\")"
Reading symbols from src/emacs.exe...done.
Starting program: C:\projects\emacs\src\emacs.exe -Q -eval "(start-process \"git gui\" \"*git gui*\" \"C:\\Program Files\\Git\\cmd\\Git-GUI.exe\")"
[New Thread 13832.0x1ce4]
[New Thread 13832.0x33b0]
[New Thread 13832.0x2c38]
[New Thread 13832.0x1c50]
[New Thread 13832.0x2ab8]
[New Thread 13832.0x3328]
[New Thread 13832.0x1744]
[Thread 13832.0x1744 exited with code 0]

Thread 1 received signal SIGTRAP, Trace/breakpoint trap.
0x00007ffac3b2a953 in KERNELBASE!DebugBreak ()
   from C:\WINDOWS\System32\KernelBase.dll
(gdb) thread apply all bt

Thread 6 (Thread 13832.0x3328):
#0  0x00007ffac49d1ca4 in win32u!NtGdiDrawStream ()
   from C:\WINDOWS\System32\win32u.dll
#1  0x00007ffac47cd1dc in gdi32full!GdiDrawStream ()
   from C:\WINDOWS\System32\gdi32full.dll
#2  0x00007ffac2022819 in UxTheme!DrawThemeBackground ()
   from C:\WINDOWS\system32\uxtheme.dll
#3  0x00007ffac2021f6c in UxTheme!DrawThemeBackground ()
   from C:\WINDOWS\system32\uxtheme.dll
#4  0x00007ffac2020d2c in UxTheme!DrawThemeBackground ()
   from C:\WINDOWS\system32\uxtheme.dll
#5  0x00007ffac201f7ca in UxTheme!GetUserColorPreference ()
   from C:\WINDOWS\system32\uxtheme.dll
#6  0x00007ffac201e3f1 in UxTheme!GetUserColorPreference ()
   from C:\WINDOWS\system32\uxtheme.dll
#7  0x00007ffac5099be7 in USER32!GetWindowTextW ()
   from C:\WINDOWS\System32\user32.dll
#8  0x0000000400234097 in w32_wnd_proc (hwnd=0x929de, msg=146, wParam=0,
    lParam=79622992) at w32fns.c:5383
#9  0x00007ffac509bc50 in USER32!CallWindowProcW ()
   from C:\WINDOWS\System32\user32.dll
#10 0x00007ffac509b94c in USER32!CallWindowProcW ()
   from C:\WINDOWS\System32\user32.dll
#11 0x00007ffac50b31f9 in USER32!IsWinEventHookInstalled ()
   from C:\WINDOWS\System32\user32.dll
#12 0x00007ffac75390a4 in ntdll!KiUserCallbackDispatcher ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#13 0x00007ffac49d2ca4 in win32u!NtUserPaintMenuBar ()
   from C:\WINDOWS\System32\win32u.dll
#14 0x00007ffac2019525 in UxTheme!GetUserColorPreference ()
   from C:\WINDOWS\system32\uxtheme.dll
#15 0x00007ffac2016d4e in UxTheme!IsThemeActive ()
   from C:\WINDOWS\system32\uxtheme.dll
#16 0x00007ffac201f8e1 in UxTheme!GetUserColorPreference ()
   from C:\WINDOWS\system32\uxtheme.dll
#17 0x00007ffac201e3f1 in UxTheme!GetUserColorPreference ()
   from C:\WINDOWS\system32\uxtheme.dll
#18 0x00007ffac5099be7 in USER32!GetWindowTextW ()
   from C:\WINDOWS\System32\user32.dll
#19 0x0000000400234097 in w32_wnd_proc (hwnd=0x929de, msg=134, wParam=1,
    lParam=0) at w32fns.c:5383
#20 0x00007ffac509bc50 in USER32!CallWindowProcW ()
   from C:\WINDOWS\System32\user32.dll
#21 0x00007ffac509b94c in USER32!CallWindowProcW ()
   from C:\WINDOWS\System32\user32.dll
#22 0x00007ffac50b11f3 in USER32!GetTopWindow ()
   from C:\WINDOWS\System32\user32.dll
#23 0x00007ffac75390a4 in ntdll!KiUserCallbackDispatcher ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#24 0x00007ffac49d1144 in win32u!NtUserGetMessage ()
   from C:\WINDOWS\System32\win32u.dll
#25 0x00007ffac50b2c66 in USER32!GetMessageW ()
   from C:\WINDOWS\System32\user32.dll
#26 0x0000000400230034 in w32_msg_pump (msg_buf=0x4befec0) at w32fns.c:3255
#27 0x00000004002302d4 in w32_msg_worker (arg=0x0) at w32fns.c:3478
#28 0x00007ffac6d42774 in KERNEL32!BaseThreadInitThunk ()
   from C:\WINDOWS\System32\kernel32.dll
#29 0x00007ffac7500d51 in ntdll!RtlUserThreadStart ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#30 0x0000000000000000 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Thread 5 (Thread 13832.0x2ab8):
#0  0x00007ffac7535a24 in ntdll!ZwDelayExecution ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#1  0x00007ffac3aa7287 in SleepEx () from C:\WINDOWS\System32\KernelBase.dll
#2  0x0000000400276a7f in timer_loop (arg=0x401bc5080 <real_itimer>)
    at w32proc.c:383
#3  0x00007ffac6d42774 in KERNEL32!BaseThreadInitThunk ()
   from C:\WINDOWS\System32\kernel32.dll
#4  0x00007ffac7500d51 in ntdll!RtlUserThreadStart ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#5  0x0000000000000000 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Thread 4 (Thread 13832.0x1c50):
#0  0x00007ffac7538c34 in ntdll!ZwWaitForWorkViaWorkerFactory ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#1  0x00007ffac74d1553 in ntdll!TpReleaseWork ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#2  0x00007ffac6d42774 in KERNEL32!BaseThreadInitThunk ()
   from C:\WINDOWS\System32\kernel32.dll
#3  0x00007ffac7500d51 in ntdll!RtlUserThreadStart ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#4  0x0000000000000000 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Thread 3 (Thread 13832.0x2c38):
#0  0x00007ffac7538c34 in ntdll!ZwWaitForWorkViaWorkerFactory ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#1  0x00007ffac74d1553 in ntdll!TpReleaseWork ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#2  0x00007ffac6d42774 in KERNEL32!BaseThreadInitThunk ()
   from C:\WINDOWS\System32\kernel32.dll
#3  0x00007ffac7500d51 in ntdll!RtlUserThreadStart ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#4  0x0000000000000000 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Thread 2 (Thread 13832.0x33b0):
#0  0x00007ffac7538c34 in ntdll!ZwWaitForWorkViaWorkerFactory ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#1  0x00007ffac74d1553 in ntdll!TpReleaseWork ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#2  0x00007ffac6d42774 in KERNEL32!BaseThreadInitThunk ()
   from C:\WINDOWS\System32\kernel32.dll
#3  0x00007ffac7500d51 in ntdll!RtlUserThreadStart ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#4  0x0000000000000000 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Thread 1 (Thread 13832.0x1ce4):
#0  0x00007ffac3b2a953 in KERNELBASE!DebugBreak ()
   from C:\WINDOWS\System32\KernelBase.dll
#1  0x000000040023ff7c in emacs_abort () at w32fns.c:10931
#2  0x00000004001a745e in signal_or_quit (error_symbol=..., data=...,
    keyboard_quit=true) at eval.c:1535
#3  0x00000004001a73d8 in quit () at eval.c:1513
#4  0x00000004001a7309 in process_quit_flag () at eval.c:1460
#5  0x00000004001a735e in maybe_quit () at eval.c:1483
#6  0x000000040027862d in waitpid (pid=10576, status=0xbfe39c, options=11)
    at w32proc.c:1452
#7  0x0000000400122108 in get_child_status (child=10576, status=0xbfe39c,
    options=11, interruptible=false) at sysdep.c:397
#8  0x00000004001221f7 in child_status_changed (child=10576, status=0xbfe39c,
    options=10) at sysdep.c:443
#9  0x000000040020599f in handle_child_signal (sig=18) at process.c:7065
#10 0x0000000400123037 in deliver_process_signal (sig=18,
    handler=0x400205841 <handle_child_signal>) at sysdep.c:1659
#11 0x0000000400205ad4 in deliver_child_signal (sig=18) at process.c:7098
#12 0x000000040027a27e in sys_select (nfds=6, rfds=0xbfed68, wfds=0xbfed60,
    efds=0x0, timeout=0xbfed40, ignored=0x0) at w32proc.c:2403
#13 0x0000000400229abe in really_call_select (arg=0xbfeba0) at thread.c:566
#14 0x0000000400182a38 in flush_stack_call_func (
    func=0x400229a2c <really_call_select>, arg=0xbfeba0) at alloc.c:5158
#15 0x0000000000000000 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb) thread apply all bt full

Thread 6 (Thread 13832.0x3328):
#0  0x00007ffac49d1ca4 in win32u!NtGdiDrawStream ()
   from C:\WINDOWS\System32\win32u.dll
No symbol table info available.
#1  0x00007ffac47cd1dc in gdi32full!GdiDrawStream ()
   from C:\WINDOWS\System32\gdi32full.dll
No symbol table info available.
#2  0x00007ffac2022819 in UxTheme!DrawThemeBackground ()
   from C:\WINDOWS\system32\uxtheme.dll
No symbol table info available.
#3  0x00007ffac2021f6c in UxTheme!DrawThemeBackground ()
   from C:\WINDOWS\system32\uxtheme.dll
No symbol table info available.
#4  0x00007ffac2020d2c in UxTheme!DrawThemeBackground ()
   from C:\WINDOWS\system32\uxtheme.dll
No symbol table info available.
#5  0x00007ffac201f7ca in UxTheme!GetUserColorPreference ()
   from C:\WINDOWS\system32\uxtheme.dll
No symbol table info available.
#6  0x00007ffac201e3f1 in UxTheme!GetUserColorPreference ()
   from C:\WINDOWS\system32\uxtheme.dll
No symbol table info available.
#7  0x00007ffac5099be7 in USER32!GetWindowTextW ()
   from C:\WINDOWS\System32\user32.dll
No symbol table info available.
#8  0x0000000400234097 in w32_wnd_proc (hwnd=0x929de, msg=146, wParam=0,
    lParam=79622992) at w32fns.c:5383
        f = 0xc0
        dpyinfo = 0x4006b40a0 <one_w32_display_info>
        wmsg = {
          msg = {
            hwnd = 0x4beef90,
            message = 0,
            wParam = 980,
            lParam = 980,
            time = 980,
            pt = {
              x = 0,
              y = 0
            }
          },
          dwModifiers = 0,
          rect = {
            left = 0,
            top = 79623120,
            right = 0,
            bottom = 79622724
          }
        }
        windows_translate = 1
        key = 1073741922
#9  0x00007ffac509bc50 in USER32!CallWindowProcW ()
   from C:\WINDOWS\System32\user32.dll
No symbol table info available.
#10 0x00007ffac509b94c in USER32!CallWindowProcW ()
   from C:\WINDOWS\System32\user32.dll
No symbol table info available.
#11 0x00007ffac50b31f9 in USER32!IsWinEventHookInstalled ()
   from C:\WINDOWS\System32\user32.dll
No symbol table info available.
#12 0x00007ffac75390a4 in ntdll!KiUserCallbackDispatcher ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
No symbol table info available.
#13 0x00007ffac49d2ca4 in win32u!NtUserPaintMenuBar ()
   from C:\WINDOWS\System32\win32u.dll
No symbol table info available.
#14 0x00007ffac2019525 in UxTheme!GetUserColorPreference ()
   from C:\WINDOWS\system32\uxtheme.dll
No symbol table info available.
#15 0x00007ffac2016d4e in UxTheme!IsThemeActive ()
   from C:\WINDOWS\system32\uxtheme.dll
No symbol table info available.
#16 0x00007ffac201f8e1 in UxTheme!GetUserColorPreference ()
   from C:\WINDOWS\system32\uxtheme.dll
No symbol table info available.
#17 0x00007ffac201e3f1 in UxTheme!GetUserColorPreference ()
   from C:\WINDOWS\system32\uxtheme.dll
No symbol table info available.
#18 0x00007ffac5099be7 in USER32!GetWindowTextW ()
   from C:\WINDOWS\System32\user32.dll
No symbol table info available.
#19 0x0000000400234097 in w32_wnd_proc (hwnd=0x929de, msg=134, wParam=1,
    lParam=0) at w32fns.c:5383
        f = 0x0
        dpyinfo = 0x4006b40a0 <one_w32_display_info>
        wmsg = {
          msg = {
            hwnd = 0x929de,
            message = 28,
            wParam = 1,
            lParam = 7396,
            time = 1073446703,
            pt = {
              x = 0,
              y = 0
            }
          },
          dwModifiers = 23,
          rect = {
            left = 0,
            top = 676319269,
            right = 35119,
            bottom = 71
          }
        }
        windows_translate = 0
        key = 79625856
#20 0x00007ffac509bc50 in USER32!CallWindowProcW ()
   from C:\WINDOWS\System32\user32.dll
No symbol table info available.
#21 0x00007ffac509b94c in USER32!CallWindowProcW ()
   from C:\WINDOWS\System32\user32.dll
No symbol table info available.
#22 0x00007ffac50b11f3 in USER32!GetTopWindow ()
   from C:\WINDOWS\System32\user32.dll
No symbol table info available.
#23 0x00007ffac75390a4 in ntdll!KiUserCallbackDispatcher ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
No symbol table info available.
#24 0x00007ffac49d1144 in win32u!NtUserGetMessage ()
   from C:\WINDOWS\System32\win32u.dll
No symbol table info available.
#25 0x00007ffac50b2c66 in USER32!GetMessageW ()
   from C:\WINDOWS\System32\user32.dll
No symbol table info available.
#26 0x0000000400230034 in w32_msg_pump (msg_buf=0x4befec0) at w32fns.c:3255
        msg = {
          hwnd = 0x0,
          message = 275,
          wParam = 17281,
          lParam = 140715060728336,
          time = 1073446703,
          pt = {
            x = 1305,
            y = 848
          }
        }
        result = 0
        focus_window = 0x7ffac50b6a75 <USER32!PostThreadMessageA+101>
#27 0x00000004002302d4 in w32_msg_worker (arg=0x0) at w32fns.c:3478
        msg = {
          hwnd = 0x0,
          message = 0,
          wParam = 0,
          lParam = 0,
          time = 0,
          pt = {
            x = 0,
            y = 0
          }
        }
        dummy_buf = {
          next = 0x0,
          w32msg = {
            msg = {
              hwnd = 0x0,
              message = 0,
              wParam = 0,
              lParam = 0,
              time = 0,
              pt = {
                x = 0,
                y = 0
              }
            },
            dwModifiers = 0,
            rect = {
              left = 0,
              top = 0,
              right = 0,
              bottom = 0
            }
          },
          result = 0,
          completed = 0
        }
#28 0x00007ffac6d42774 in KERNEL32!BaseThreadInitThunk ()
   from C:\WINDOWS\System32\kernel32.dll
No symbol table info available.
#29 0x00007ffac7500d51 in ntdll!RtlUserThreadStart ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
No symbol table info available.
#30 0x0000000000000000 in ?? ()
No symbol table info available.
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Thread 5 (Thread 13832.0x2ab8):
#0  0x00007ffac7535a24 in ntdll!ZwDelayExecution ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
No symbol table info available.
#1  0x00007ffac3aa7287 in SleepEx () from C:\WINDOWS\System32\KernelBase.dll
No symbol table info available.
#2  0x0000000400276a7f in timer_loop (arg=0x401bc5080 <real_itimer>)
    at w32proc.c:383
        sleep_time = 2
        handler = 0x400212c57 <handle_alarm_signal>
        now = 13148503974242
        expire = 0
        reload = 0
        itimer = 0x401bc5080 <real_itimer>
        which = 0
        sig = 14
        crit = 0x401bc5100 <crit_real>
        max_sleep = 30
        hth = 0x0
#3  0x00007ffac6d42774 in KERNEL32!BaseThreadInitThunk ()
   from C:\WINDOWS\System32\kernel32.dll
No symbol table info available.
#4  0x00007ffac7500d51 in ntdll!RtlUserThreadStart ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
No symbol table info available.
#5  0x0000000000000000 in ?? ()
No symbol table info available.
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Thread 4 (Thread 13832.0x1c50):
#0  0x00007ffac7538c34 in ntdll!ZwWaitForWorkViaWorkerFactory ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
No symbol table info available.
#1  0x00007ffac74d1553 in ntdll!TpReleaseWork ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
No symbol table info available.
#2  0x00007ffac6d42774 in KERNEL32!BaseThreadInitThunk ()
   from C:\WINDOWS\System32\kernel32.dll
No symbol table info available.
#3  0x00007ffac7500d51 in ntdll!RtlUserThreadStart ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
No symbol table info available.
#4  0x0000000000000000 in ?? ()
No symbol table info available.
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Thread 3 (Thread 13832.0x2c38):
#0  0x00007ffac7538c34 in ntdll!ZwWaitForWorkViaWorkerFactory ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
No symbol table info available.
#1  0x00007ffac74d1553 in ntdll!TpReleaseWork ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
No symbol table info available.
#2  0x00007ffac6d42774 in KERNEL32!BaseThreadInitThunk ()
   from C:\WINDOWS\System32\kernel32.dll
No symbol table info available.
#3  0x00007ffac7500d51 in ntdll!RtlUserThreadStart ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
No symbol table info available.
#4  0x0000000000000000 in ?? ()
No symbol table info available.
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Thread 2 (Thread 13832.0x33b0):
#0  0x00007ffac7538c34 in ntdll!ZwWaitForWorkViaWorkerFactory ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
No symbol table info available.
#1  0x00007ffac74d1553 in ntdll!TpReleaseWork ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
No symbol table info available.
#2  0x00007ffac6d42774 in KERNEL32!BaseThreadInitThunk ()
   from C:\WINDOWS\System32\kernel32.dll
No symbol table info available.
#3  0x00007ffac7500d51 in ntdll!RtlUserThreadStart ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
No symbol table info available.
#4  0x0000000000000000 in ?? ()
No symbol table info available.
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Thread 1 (Thread 13832.0x1ce4):
#0  0x00007ffac3b2a953 in KERNELBASE!DebugBreak ()
   from C:\WINDOWS\System32\KernelBase.dll
No symbol table info available.
#1  0x000000040023ff7c in emacs_abort () at w32fns.c:10931
        button = 6
#2  0x00000004001a745e in signal_or_quit (error_symbol=..., data=...,
    keyboard_quit=true) at eval.c:1535
        conditions = {
          i = 12574640
        }
        string = {
          i = 51240
        }
        real_error_symbol = {
          i = 51240
        }
        clause = {
          i = 0
        }
        h = 0xc
#3  0x00000004001a73d8 in quit () at eval.c:1513
No locals.
#4  0x00000004001a7309 in process_quit_flag () at eval.c:1460
        flag = {
          i = 59472
        }
#5  0x00000004001a735e in maybe_quit () at eval.c:1483
No locals.
#6  0x000000040027862d in waitpid (pid=10576, status=0xbfe39c, options=11)
    at w32proc.c:1452
        active = 0
        retval = 259
        nh = 1
        cp = 0x401bc3d60 <child_procs>
        cps = {0x401bc3d60 <child_procs>, 0x0, 0x3f70000, 0x450000163, 0x30,
          0x60, 0x0, 0xbfe238, 0x4006ec600 <dumped_data+168736>, 0x3f70000,
          0x30, 0x0, 0x40, 0x1, 0x50000163, 0x0, 0x3f70000,
          0x7ffac75210d7 <ntdll!RtlCreateHashTableEx+2311>, 0x4c13960, 0x0,
          0x3f70000, 0x400180000 <sweep_vectors+921>, 0x8501, 0x4c13970,
          0x40000062, 0x0, 0x0, 0x4, 0x40000060,
          0x7ffac7548294 <ntdll!memset+50260>, 0x3f70000, 0x450000163}
        wait_hnd = {0x374, 0x2, 0xffffffffee749350, 0x50000163, 0x48,
          0x400000001, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x3f70150,
          0x6, 0x4ffff080a, 0x2a, 0xbfe1d0, 0x4001aa527 <Ffuncall+849>,
          0x4008dfe10 <dumped_data+2214704>, 0x4, 0x1a04001e,
          0x40017e045 <mark_interval+46>, 0x0, 0x4000fb2ff <CHECK_LIST+44>,
          0x30, 0x0, 0x40, 0x0, 0x50000100,
          0x7ffac7520812 <ntdll!RtlCreateHashTableEx+66>}
        timeout_ms = 0
        dont_wait = 1
#7  0x0000000400122108 in get_child_status (child=10576, status=0xbfe39c,
    options=11, interruptible=false) at sysdep.c:397
        pid = 0
#8  0x00000004001221f7 in child_status_changed (child=10576, status=0xbfe39c,
    options=10) at sysdep.c:443
No locals.
#9  0x000000040020599f in handle_child_signal (sig=18) at process.c:7065
        p = 0x400b33da0 <dumped_data+4655808>
        status = 4
        tail = {
          i = 17187343859
        }
        proc = {
          i = 17191615909
        }
#10 0x0000000400123037 in deliver_process_signal (sig=18,
    handler=0x400205841 <handle_child_signal>) at sysdep.c:1659
        old_errno = 0
        on_main_thread = true
#11 0x0000000400205ad4 in deliver_child_signal (sig=18) at process.c:7098
No locals.
#12 0x000000040027a27e in sys_select (nfds=6, rfds=0xbfed68, wfds=0xbfed60,
    efds=0x0, timeout=0xbfed40, ignored=0x0) at w32proc.c:2403
        orfds = {
          bits = {33, 0}
        }
        owfds = {
          bits = {0, 0}
        }
        timeout_ms = 29435
        start_time = 1073444390
        i = 6
        nh = 3
        nc = 1
        nr = 1
        active = 3
        cp = 0x401bc3d60 <child_procs>
        cps = {0x401bc3d60 <child_procs>, 0x4002569c0 <w32_read_socket+9331>,
          0xbfe9c0, 0x0, 0xbfe940, 0x400109f66 <decode_timer+100>,
          0x400000000, 0x0, 0xbfe900, 0x4000f9a4f <builtin_lisp_symbol+49>,
          0x84cd1f78, 0x7ffac74ec713 <ntdll!RtlGetSystemTimePrecise+83>,
          0xbfe920, 0x4000f9d19 <XSETCDR+25>, 0x4ceef53,
          0x4000fb346 <CHECK_LIST_END+36>, 0x0, 0x0, 0xbfe960,
          0x4000fa074 <ASIZE+21>, 0x400b91fe5 <dumped_data+5041413>,
          0x7ffac3ab085f <KERNELBASE!GetSystemTimePreciseAsFileTime+15>,
          0x4011dfdd8a7, 0xbfe990, 0xbfe990, 0x0, 0xbfe990,
          0x4000f9a4f <builtin_lisp_symbol+49>, 0x0,
          0x40022a879 <sys_mutex_unlock+25>, 0x1f4ce0, 0x9}
        wait_hnd = {0x2a4, 0x270, 0x364, 0x374, 0x4012e2ec6bce8534, 0xbfe600,
          0x22, 0x2a, 0x59a5aea5, 0x32063a88, 0x0, 0x557e802e2eff8, 0x0,
          0x557e800000004, 0x4006e7603 <dumped_data+148259>,
          0x4006e72c3 <dumped_data+147427>, 0x4006e71c3 <dumped_data+147171>,
          0x4006e7083 <dumped_data+146851>, 0x30, 0x0, 0x40, 0x0, 0x4,
          0x40000060, 0x3f70000, 0x7ffac74bb88a <ntdll!RtlAllocateHeap+2698>,
          0x3f70000, 0x40000062, 0x30, 0x40, 0x0, 0xbfe6d8, 0x0, 0x64e370,
          0x0, 0x0, 0x20, 0x28, 0x1f4ce0, 0x4, 0xbfe710,
          0x400274003 <malloc_after_dump+40>, 0x0, 0x30, 0x4ce1763, 0x0,
          0x4c139a0, 0x4c13970, 0xbfe750, 0x40017ddb2 <lmalloc+48>,
          0x4c13970, 0x30, 0x3efd, 0xb, 0xab, 0xcda02f0, 0xbfe790,
          0x40018179a <mem_insert_fixup+240>, 0x4c3aa60,
          0x4000fb022 <BUFFER_OBJFWDP+21>, 0x40069f540 <o_fwd>, 0x6,
          0x4c3aa00, 0x4c13970, 0xbfe7e0, 0x4001816a0 <mem_insert+341>,
          0xcda03b0, 0x4, 0xbfe7f0, 0x400274003 <malloc_after_dump+40>, 0x0,
          0x4c13970, 0x4c13910, 0x40069e080 <mem_z>, 0xbfe840, 0x0, 0xbfe820,
          0x4000f9a4f <builtin_lisp_symbol+49>, 0x0,
          0x7ffac3aad61a <ResetEvent+10>, 0x1f4ce0,
          0x40025af02 <drain_message_queue+107>, 0x0, 0xbfe890, 0x0,
          0x40025acf4 <get_next_msg+630>, 0x1f4ce0, 0x4000fa074 <ASIZE+21>,
          0x400b91fe5 <dumped_data+5041413>,
          0x7ffac3ab085f <KERNELBASE!GetSystemTimePreciseAsFileTime+15>,
          0xbfe890, 0x40010f0e0 <unblock_input+24>, 0x0, 0x0, 0xbfe8b0,
          0xf9a4f}
        fdindex = {-1, 0, 5, -623312752, 1221920518, 9536034, -1306328101,
          -2063497215, 218235047, 10978622, -892303102, -1241402807, 8857986,
          4, 34, 0, 0, 0, 2783789, 4, 12576016, 0, 1023257, 4, 7233427, 4,
          1023257, 4, 0, 0, 48427000, 350184, 0, 0, 2783626, 4, 12576080, 0,
          1561600, 4, 7234455, 4, 0, 0, 48, 0, 0, 0, 64, 0, 0, 0, 4, 0,
          1073741920, 0, 66519040, 0, -951338870, 32762, 66519040, 0,
          1073741922, 350184}
#13 0x0000000400229abe in really_call_select (arg=0xbfeba0) at thread.c:566
        sa = 0xbfeba0
        self = 0x4006b3340 <main_thread>
        oldset = 17192001512
#14 0x0000000400182a38 in flush_stack_call_func (
    func=0x400229a2c <really_call_select>, arg=0xbfeba0) at alloc.c:5158
        end = 0xbfea60
        self = 0x4006b3340 <main_thread>
        sentry = {
          o = {
            __max_align_ll = 4,
            __max_align_ld = <invalid float value>
          }
        }
#15 0x0000000000000000 in ?? ()
No symbol table info available.
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb)

bug#28268: 26.0.50; (MS Windows) crash on C-g after closing Git GUI

[Eli Zaretskii]

> Date: Tue, 29 Aug 2017 20:33:49 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 28268@debbugs.gnu.org
> 
> > Date: Tue, 29 Aug 2017 20:25:52 +0300
> > From: Eli Zaretskii <eliz@gnu.org>
> > Cc: rcopley@gmail.com, 28268@debbugs.gnu.org
> > 
> > git-gui.exe is a GUI program, so it releases the shell and the shell
> > exits
> 
> Correction: git-gui.exe launches wish and exits.

It looks like not entirely our problem, or not at all: Windows itself
thinks that the process is still running, although waiting on its
handle to become signaled exits immediately, something that should
never happen.

I installed a semi-kludgey workaround which seems to avoid spinning
the CPU in this obscure case.  Please see that the problem is solved
on your systems as well.

bug#28268: 26.0.50; (MS Windows) crash on C-g after closing Git GUI

[Eli Zaretskii]

> From: Richard Copley <rcopley@gmail.com>
> Date: Tue, 29 Aug 2017 19:15:06 +0100
> Cc: Noam Postavsky <npostavs@users.sourceforge.net>, 28268@debbugs.gnu.org
> 
> ;; In Emacs
> C-g ;; Repeat until the abort
> 
> ;; In GDB in mingw64 bash
> thread apply all
> thread apply all bt full
> 
> The output is attached. Apparently the GDB crash happens if
> you run GDB from the Windows (7 or 10) command prompt and
> not if you run it from msys bash.

Thanks.  No surprises here, so I think the problem is indeed solved.

bug#28268: 26.0.50; (MS Windows) crash on C-g after closing Git GUI

[Richard Copley]

On 29 August 2017 at 19:59, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Tue, 29 Aug 2017 20:33:49 +0300
>> From: Eli Zaretskii <eliz@gnu.org>
>> Cc: 28268@debbugs.gnu.org
>>
>> > Date: Tue, 29 Aug 2017 20:25:52 +0300
>> > From: Eli Zaretskii <eliz@gnu.org>
>> > Cc: rcopley@gmail.com, 28268@debbugs.gnu.org
>> >
>> > git-gui.exe is a GUI program, so it releases the shell and the shell
>> > exits
>>
>> Correction: git-gui.exe launches wish and exits.
>
> It looks like not entirely our problem, or not at all: Windows itself
> thinks that the process is still running, although waiting on its
> handle to become signaled exits immediately, something that should
> never happen.

Could it be that the (wish) subprocess inherited its parents' STDIN
and STDOUT handles and so the process can't completely die until
the subprocess does? It's a pain when that happens.

> I installed a semi-kludgey workaround which seems to avoid spinning
> the CPU in this obscure case.  Please see that the problem is solved
> on your systems as well.

OK will do.

bug#28268: 26.0.50; (MS Windows) crash on C-g after closing Git GUI

[Eli Zaretskii]

> From: Richard Copley <rcopley@gmail.com>
> Date: Tue, 29 Aug 2017 20:02:33 +0100
> Cc: Noam Postavsky <npostavs@users.sourceforge.net>, 28268@debbugs.gnu.org
> 
> > It looks like not entirely our problem, or not at all: Windows itself
> > thinks that the process is still running, although waiting on its
> > handle to become signaled exits immediately, something that should
> > never happen.
> 
> Could it be that the (wish) subprocess inherited its parents' STDIN
> and STDOUT handles and so the process can't completely die until
> the subprocess does?

No, because closing wish doesn't stop the loop.

bug#28268: 26.0.50; (MS Windows) crash on C-g after closing Git GUI

[Richard Copley]

On 29 August 2017 at 20:02, Richard Copley <rcopley@gmail.com> wrote:
> On 29 August 2017 at 19:59, Eli Zaretskii <eliz@gnu.org> wrote:

>> I installed a semi-kludgey workaround which seems to avoid spinning
>> the CPU in this obscure case.  Please see that the problem is solved
>> on your systems as well.

Seems fine now. Thanks very much.

bug#28268: 26.0.50; (MS Windows) crash on C-g after closing Git GUI

[Eli Zaretskii]

> From: Richard Copley <rcopley@gmail.com>
> Date: Tue, 29 Aug 2017 20:38:18 +0100
> Cc: Noam Postavsky <npostavs@users.sourceforge.net>, 28268@debbugs.gnu.org
> 
> On 29 August 2017 at 20:02, Richard Copley <rcopley@gmail.com> wrote:
> > On 29 August 2017 at 19:59, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> >> I installed a semi-kludgey workaround which seems to avoid spinning
> >> the CPU in this obscure case.  Please see that the problem is solved
> >> on your systems as well.
> 
> Seems fine now. Thanks very much.

OK, thanks, I'm therefore closing the bug.  I'm still puzzled how come
GetExitCodeProcess reports STILL_ACTIVE in this when the process most
definitely died, but I'm out of ideas.