* bug#28268: 26.0.50; (MS Windows) crash on C-g after closing Git GUI @ 2017-08-28 21:10 Richard Copley 2017-08-29 15:18 ` Eli Zaretskii 0 siblings, 1 reply; 18+ messages in thread From: Richard Copley @ 2017-08-28 21:10 UTC (permalink / raw) To: 28268 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)) ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#28268: 26.0.50; (MS Windows) crash on C-g after closing Git GUI 2017-08-28 21:10 bug#28268: 26.0.50; (MS Windows) crash on C-g after closing Git GUI Richard Copley @ 2017-08-29 15:18 ` Eli Zaretskii [not found] ` <CAPM58oj8XRzUJpRtbB_TCYxsfaWncDjwnGqTg-FFo6w2P5m8Qw@mail.gmail.com> 2017-08-29 16:38 ` Noam Postavsky 0 siblings, 2 replies; 18+ messages in thread From: Eli Zaretskii @ 2017-08-29 15:18 UTC (permalink / raw) To: Richard Copley; +Cc: 28268 > 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
[parent not found: <CAPM58oj8XRzUJpRtbB_TCYxsfaWncDjwnGqTg-FFo6w2P5m8Qw@mail.gmail.com>]
* bug#28268: Fwd: bug#28268: 26.0.50; (MS Windows) crash on C-g after closing Git GUI [not found] ` <CAPM58oj8XRzUJpRtbB_TCYxsfaWncDjwnGqTg-FFo6w2P5m8Qw@mail.gmail.com> @ 2017-08-29 16:08 ` Richard Copley 2017-08-29 16:09 ` Richard Copley 0 siblings, 1 reply; 18+ messages in thread From: Richard Copley @ 2017-08-29 16:08 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 28268 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"). ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#28268: 26.0.50; (MS Windows) crash on C-g after closing Git GUI 2017-08-29 16:08 ` bug#28268: Fwd: " Richard Copley @ 2017-08-29 16:09 ` Richard Copley 2017-08-29 16:22 ` Richard Copley 2017-08-29 16:53 ` Eli Zaretskii 0 siblings, 2 replies; 18+ messages in thread From: Richard Copley @ 2017-08-29 16:09 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 28268 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#28268: 26.0.50; (MS Windows) crash on C-g after closing Git GUI 2017-08-29 16:09 ` Richard Copley @ 2017-08-29 16:22 ` Richard Copley 2017-08-29 16:53 ` Eli Zaretskii 1 sibling, 0 replies; 18+ messages in thread From: Richard Copley @ 2017-08-29 16:22 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 28268 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). ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#28268: 26.0.50; (MS Windows) crash on C-g after closing Git GUI 2017-08-29 16:09 ` Richard Copley 2017-08-29 16:22 ` Richard Copley @ 2017-08-29 16:53 ` Eli Zaretskii 1 sibling, 0 replies; 18+ messages in thread From: Eli Zaretskii @ 2017-08-29 16:53 UTC (permalink / raw) To: Richard Copley; +Cc: 28268 > 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#28268: 26.0.50; (MS Windows) crash on C-g after closing Git GUI 2017-08-29 15:18 ` Eli Zaretskii [not found] ` <CAPM58oj8XRzUJpRtbB_TCYxsfaWncDjwnGqTg-FFo6w2P5m8Qw@mail.gmail.com> @ 2017-08-29 16:38 ` Noam Postavsky 2017-08-29 16:48 ` Richard Copley 1 sibling, 1 reply; 18+ messages in thread From: Noam Postavsky @ 2017-08-29 16:38 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Richard Copley, 28268 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#28268: 26.0.50; (MS Windows) crash on C-g after closing Git GUI 2017-08-29 16:38 ` Noam Postavsky @ 2017-08-29 16:48 ` Richard Copley 2017-08-29 17:14 ` Noam Postavsky 0 siblings, 1 reply; 18+ messages in thread From: Richard Copley @ 2017-08-29 16:48 UTC (permalink / raw) To: Noam Postavsky; +Cc: 28268 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#28268: 26.0.50; (MS Windows) crash on C-g after closing Git GUI 2017-08-29 16:48 ` Richard Copley @ 2017-08-29 17:14 ` Noam Postavsky 2017-08-29 17:25 ` Eli Zaretskii 0 siblings, 1 reply; 18+ messages in thread From: Noam Postavsky @ 2017-08-29 17:14 UTC (permalink / raw) To: Richard Copley; +Cc: 28268 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#28268: 26.0.50; (MS Windows) crash on C-g after closing Git GUI 2017-08-29 17:14 ` Noam Postavsky @ 2017-08-29 17:25 ` Eli Zaretskii 2017-08-29 17:33 ` Eli Zaretskii 0 siblings, 1 reply; 18+ messages in thread From: Eli Zaretskii @ 2017-08-29 17:25 UTC (permalink / raw) To: Noam Postavsky; +Cc: rcopley, 28268 > 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... ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#28268: 26.0.50; (MS Windows) crash on C-g after closing Git GUI 2017-08-29 17:25 ` Eli Zaretskii @ 2017-08-29 17:33 ` Eli Zaretskii 2017-08-29 18:15 ` Richard Copley 2017-08-29 18:59 ` Eli Zaretskii 0 siblings, 2 replies; 18+ messages in thread From: Eli Zaretskii @ 2017-08-29 17:33 UTC (permalink / raw) To: npostavs, rcopley; +Cc: 28268 > 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#28268: 26.0.50; (MS Windows) crash on C-g after closing Git GUI 2017-08-29 17:33 ` Eli Zaretskii @ 2017-08-29 18:15 ` Richard Copley 2017-08-29 19:00 ` Eli Zaretskii 2017-08-29 18:59 ` Eli Zaretskii 1 sibling, 1 reply; 18+ messages in thread From: Richard Copley @ 2017-08-29 18:15 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 28268, Noam Postavsky [-- 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) ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#28268: 26.0.50; (MS Windows) crash on C-g after closing Git GUI 2017-08-29 18:15 ` Richard Copley @ 2017-08-29 19:00 ` Eli Zaretskii 0 siblings, 0 replies; 18+ messages in thread From: Eli Zaretskii @ 2017-08-29 19:00 UTC (permalink / raw) To: Richard Copley; +Cc: 28268, npostavs > 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#28268: 26.0.50; (MS Windows) crash on C-g after closing Git GUI 2017-08-29 17:33 ` Eli Zaretskii 2017-08-29 18:15 ` Richard Copley @ 2017-08-29 18:59 ` Eli Zaretskii 2017-08-29 19:02 ` Richard Copley 1 sibling, 1 reply; 18+ messages in thread From: Eli Zaretskii @ 2017-08-29 18:59 UTC (permalink / raw) To: npostavs, rcopley; +Cc: 28268 > 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#28268: 26.0.50; (MS Windows) crash on C-g after closing Git GUI 2017-08-29 18:59 ` Eli Zaretskii @ 2017-08-29 19:02 ` Richard Copley 2017-08-29 19:28 ` Eli Zaretskii 2017-08-29 19:38 ` Richard Copley 0 siblings, 2 replies; 18+ messages in thread From: Richard Copley @ 2017-08-29 19:02 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 28268, Noam Postavsky 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#28268: 26.0.50; (MS Windows) crash on C-g after closing Git GUI 2017-08-29 19:02 ` Richard Copley @ 2017-08-29 19:28 ` Eli Zaretskii 2017-08-29 19:38 ` Richard Copley 1 sibling, 0 replies; 18+ messages in thread From: Eli Zaretskii @ 2017-08-29 19:28 UTC (permalink / raw) To: Richard Copley; +Cc: 28268, npostavs > 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#28268: 26.0.50; (MS Windows) crash on C-g after closing Git GUI 2017-08-29 19:02 ` Richard Copley 2017-08-29 19:28 ` Eli Zaretskii @ 2017-08-29 19:38 ` Richard Copley 2017-08-30 14:15 ` Eli Zaretskii 1 sibling, 1 reply; 18+ messages in thread From: Richard Copley @ 2017-08-29 19:38 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 28268, Noam Postavsky 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#28268: 26.0.50; (MS Windows) crash on C-g after closing Git GUI 2017-08-29 19:38 ` Richard Copley @ 2017-08-30 14:15 ` Eli Zaretskii 0 siblings, 0 replies; 18+ messages in thread From: Eli Zaretskii @ 2017-08-30 14:15 UTC (permalink / raw) To: Richard Copley; +Cc: npostavs, 28268-done > 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2017-08-30 14:15 UTC | newest] Thread overview: 18+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2017-08-28 21:10 bug#28268: 26.0.50; (MS Windows) crash on C-g after closing Git GUI Richard Copley 2017-08-29 15:18 ` Eli Zaretskii [not found] ` <CAPM58oj8XRzUJpRtbB_TCYxsfaWncDjwnGqTg-FFo6w2P5m8Qw@mail.gmail.com> 2017-08-29 16:08 ` bug#28268: Fwd: " Richard Copley 2017-08-29 16:09 ` Richard Copley 2017-08-29 16:22 ` Richard Copley 2017-08-29 16:53 ` Eli Zaretskii 2017-08-29 16:38 ` Noam Postavsky 2017-08-29 16:48 ` Richard Copley 2017-08-29 17:14 ` Noam Postavsky 2017-08-29 17:25 ` Eli Zaretskii 2017-08-29 17:33 ` Eli Zaretskii 2017-08-29 18:15 ` Richard Copley 2017-08-29 19:00 ` Eli Zaretskii 2017-08-29 18:59 ` Eli Zaretskii 2017-08-29 19:02 ` Richard Copley 2017-08-29 19:28 ` Eli Zaretskii 2017-08-29 19:38 ` Richard Copley 2017-08-30 14:15 ` Eli Zaretskii
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.