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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 28268 in the body.
You can then email your comments to 28268 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Richard Copley <rcopley <at> gmail.com>
To: "bug-gnu-emacs <at> gnu.org" <bug-gnu-emacs <at> gnu.org>
Subject: 26.0.50; (MS Windows) crash on C-g after closing Git GUI
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.

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

Message #8 received at 28268 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Richard Copley <rcopley <at> gmail.com>
Cc: 28268 <at> debbugs.gnu.org
Subject: Re: bug#28268: 26.0.50;
 (MS Windows) crash on C-g after closing Git GUI
Date: Tue, 29 Aug 2017 18:18:25 +0300

> From: Richard Copley <rcopley <at> 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.

Message #11 received at 28268 <at> debbugs.gnu.org (full text, mbox):

From: Richard Copley <rcopley <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 28268 <at> debbugs.gnu.org
Subject: Fwd: bug#28268: 26.0.50;
 (MS Windows) crash on C-g after closing Git GUI
Date: Tue, 29 Aug 2017 17:08:13 +0100

Apologies for dropping the list from the CC.

---------- Forwarded message ----------
From: Richard Copley <rcopley <at> 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 <at> gnu.org>


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

    > From: Richard Copley <rcopley <at> 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").

Message #14 received at 28268 <at> debbugs.gnu.org (full text, mbox):

From: Richard Copley <rcopley <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 28268 <at> debbugs.gnu.org
Subject: Re: bug#28268: 26.0.50;
 (MS Windows) crash on C-g after closing Git GUI
Date: Tue, 29 Aug 2017 17:09:46 +0100

On 29 August 2017 at 17:08, Richard Copley <rcopley <at> gmail.com> wrote:
> Apologies for dropping the list from the CC.
>
> ---------- Forwarded message ----------
> From: Richard Copley <rcopley <at> 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 <at> gnu.org>
>
>
> On 29 Aug 2017 16:18, "Eli Zaretskii" <eliz <at> gnu.org> wrote:
>
>     > From: Richard Copley <rcopley <at> 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.

Message #17 received at 28268 <at> debbugs.gnu.org (full text, mbox):

From: Richard Copley <rcopley <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 28268 <at> debbugs.gnu.org
Subject: Re: bug#28268: 26.0.50;
 (MS Windows) crash on C-g after closing Git GUI
Date: Tue, 29 Aug 2017 17:22:42 +0100

On 29 August 2017 at 17:09, Richard Copley <rcopley <at> gmail.com> wrote:
> On 29 August 2017 at 17:08, Richard Copley <rcopley <at> gmail.com> wrote:
>> Apologies for dropping the list from the CC.
>>
>> ---------- Forwarded message ----------
>> From: Richard Copley <rcopley <at> 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 <at> gnu.org>
>>
>>
>> On 29 Aug 2017 16:18, "Eli Zaretskii" <eliz <at> gnu.org> wrote:
>>
>>     > From: Richard Copley <rcopley <at> 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).

Message #20 received at 28268 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> users.sourceforge.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Richard Copley <rcopley <at> gmail.com>, 28268 <at> debbugs.gnu.org
Subject: Re: bug#28268: 26.0.50;
 (MS Windows) crash on C-g after closing Git GUI
Date: Tue, 29 Aug 2017 12:38:02 -0400

On Tue, Aug 29, 2017 at 11:18 AM, Eli Zaretskii <eliz <at> 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

Message #23 received at 28268 <at> debbugs.gnu.org (full text, mbox):

From: Richard Copley <rcopley <at> gmail.com>
To: Noam Postavsky <npostavs <at> users.sourceforge.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 28268 <at> debbugs.gnu.org
Subject: Re: bug#28268: 26.0.50;
 (MS Windows) crash on C-g after closing Git GUI
Date: Tue, 29 Aug 2017 17:48:36 +0100

On 29 August 2017 at 17:38, Noam Postavsky
<npostavs <at> users.sourceforge.net> wrote:
> On Tue, Aug 29, 2017 at 11:18 AM, Eli Zaretskii <eliz <at> 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.

Message #26 received at 28268 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Richard Copley <rcopley <at> gmail.com>
Cc: 28268 <at> debbugs.gnu.org
Subject: Re: bug#28268: 26.0.50;
 (MS Windows) crash on C-g after closing Git GUI
Date: Tue, 29 Aug 2017 19:53:29 +0300

> From: Richard Copley <rcopley <at> gmail.com>
> Date: Tue, 29 Aug 2017 17:09:46 +0100
> Cc: 28268 <at> 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.

Message #29 received at 28268 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> users.sourceforge.net>
To: Richard Copley <rcopley <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 28268 <at> debbugs.gnu.org
Subject: Re: bug#28268: 26.0.50;
 (MS Windows) crash on C-g after closing Git GUI
Date: Tue, 29 Aug 2017 13:14:09 -0400

On Tue, Aug 29, 2017 at 12:48 PM, Richard Copley <rcopley <at> 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.

Message #32 received at 28268 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Noam Postavsky <npostavs <at> users.sourceforge.net>
Cc: rcopley <at> gmail.com, 28268 <at> debbugs.gnu.org
Subject: Re: bug#28268: 26.0.50;
 (MS Windows) crash on C-g after closing Git GUI
Date: Tue, 29 Aug 2017 20:25:52 +0300

> From: Noam Postavsky <npostavs <at> users.sourceforge.net>
> Date: Tue, 29 Aug 2017 13:14:09 -0400
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 28268 <at> 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...

Message #35 received at 28268 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: npostavs <at> users.sourceforge.net, rcopley <at> gmail.com
Cc: 28268 <at> debbugs.gnu.org
Subject: Re: bug#28268: 26.0.50;
 (MS Windows) crash on C-g after closing Git GUI
Date: Tue, 29 Aug 2017 20:33:49 +0300

> Date: Tue, 29 Aug 2017 20:25:52 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: rcopley <at> gmail.com, 28268 <at> 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.

Message #38 received at 28268 <at> debbugs.gnu.org (full text, mbox):

From: Richard Copley <rcopley <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 28268 <at> debbugs.gnu.org, Noam Postavsky <npostavs <at> users.sourceforge.net>
Subject: Re: bug#28268: 26.0.50;
 (MS Windows) crash on C-g after closing Git GUI
Date: Tue, 29 Aug 2017 19:15:06 +0100

[Message part 1 (text/plain, inline)]

On 29 August 2017 at 18:33, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> Date: Tue, 29 Aug 2017 20:25:52 +0300
>> From: Eli Zaretskii <eliz <at> gnu.org>
>> Cc: rcopley <at> gmail.com, 28268 <at> 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.

[transcript.txt (text/plain, attachment)]

Message #41 received at 28268 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: npostavs <at> users.sourceforge.net, rcopley <at> gmail.com
Cc: 28268 <at> debbugs.gnu.org
Subject: Re: bug#28268: 26.0.50;
 (MS Windows) crash on C-g after closing Git GUI
Date: Tue, 29 Aug 2017 21:59:07 +0300

> Date: Tue, 29 Aug 2017 20:33:49 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 28268 <at> debbugs.gnu.org
> 
> > Date: Tue, 29 Aug 2017 20:25:52 +0300
> > From: Eli Zaretskii <eliz <at> gnu.org>
> > Cc: rcopley <at> gmail.com, 28268 <at> 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.

Message #44 received at 28268 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Richard Copley <rcopley <at> gmail.com>
Cc: 28268 <at> debbugs.gnu.org, npostavs <at> users.sourceforge.net
Subject: Re: bug#28268: 26.0.50;
 (MS Windows) crash on C-g after closing Git GUI
Date: Tue, 29 Aug 2017 22:00:51 +0300

> From: Richard Copley <rcopley <at> gmail.com>
> Date: Tue, 29 Aug 2017 19:15:06 +0100
> Cc: Noam Postavsky <npostavs <at> users.sourceforge.net>, 28268 <at> 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.

Message #47 received at 28268 <at> debbugs.gnu.org (full text, mbox):

From: Richard Copley <rcopley <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 28268 <at> debbugs.gnu.org, Noam Postavsky <npostavs <at> users.sourceforge.net>
Subject: Re: bug#28268: 26.0.50;
 (MS Windows) crash on C-g after closing Git GUI
Date: Tue, 29 Aug 2017 20:02:33 +0100

On 29 August 2017 at 19:59, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> Date: Tue, 29 Aug 2017 20:33:49 +0300
>> From: Eli Zaretskii <eliz <at> gnu.org>
>> Cc: 28268 <at> debbugs.gnu.org
>>
>> > Date: Tue, 29 Aug 2017 20:25:52 +0300
>> > From: Eli Zaretskii <eliz <at> gnu.org>
>> > Cc: rcopley <at> gmail.com, 28268 <at> 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.

Message #50 received at 28268 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Richard Copley <rcopley <at> gmail.com>
Cc: 28268 <at> debbugs.gnu.org, npostavs <at> users.sourceforge.net
Subject: Re: bug#28268: 26.0.50;
 (MS Windows) crash on C-g after closing Git GUI
Date: Tue, 29 Aug 2017 22:28:12 +0300

> From: Richard Copley <rcopley <at> gmail.com>
> Date: Tue, 29 Aug 2017 20:02:33 +0100
> Cc: Noam Postavsky <npostavs <at> users.sourceforge.net>, 28268 <at> 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.

Message #53 received at 28268 <at> debbugs.gnu.org (full text, mbox):

From: Richard Copley <rcopley <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 28268 <at> debbugs.gnu.org, Noam Postavsky <npostavs <at> users.sourceforge.net>
Subject: Re: bug#28268: 26.0.50;
 (MS Windows) crash on C-g after closing Git GUI
Date: Tue, 29 Aug 2017 20:38:18 +0100

On 29 August 2017 at 20:02, Richard Copley <rcopley <at> gmail.com> wrote:
> On 29 August 2017 at 19:59, Eli Zaretskii <eliz <at> 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.

Message #58 received at 28268-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Richard Copley <rcopley <at> gmail.com>
Cc: 28268-done <at> debbugs.gnu.org, npostavs <at> users.sourceforge.net
Subject: Re: bug#28268: 26.0.50;
 (MS Windows) crash on C-g after closing Git GUI
Date: Wed, 30 Aug 2017 17:15:31 +0300

> From: Richard Copley <rcopley <at> gmail.com>
> Date: Tue, 29 Aug 2017 20:38:18 +0100
> Cc: Noam Postavsky <npostavs <at> users.sourceforge.net>, 28268 <at> debbugs.gnu.org
> 
> On 29 August 2017 at 20:02, Richard Copley <rcopley <at> gmail.com> wrote:
> > On 29 August 2017 at 19:59, Eli Zaretskii <eliz <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.