From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#12829: 24.3.50; emacs_abort () called from w32proc.c:1128 Date: Fri, 09 Nov 2012 21:38:08 +0200 Message-ID: <83wqxuy3bz.fsf@gnu.org> References: <509D529F.9090106@optusnet.com.au> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1352489938 9729 80.91.229.3 (9 Nov 2012 19:38:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 9 Nov 2012 19:38:58 +0000 (UTC) Cc: 12829@debbugs.gnu.org To: Stephen Powell Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Nov 09 20:39:08 2012 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1TWuQ0-000140-3c for geb-bug-gnu-emacs@m.gmane.org; Fri, 09 Nov 2012 20:39:08 +0100 Original-Received: from localhost ([::1]:48477 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TWuPq-00087Q-So for geb-bug-gnu-emacs@m.gmane.org; Fri, 09 Nov 2012 14:38:58 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:47903) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TWuPn-00086m-NE for bug-gnu-emacs@gnu.org; Fri, 09 Nov 2012 14:38:56 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TWuPm-000439-He for bug-gnu-emacs@gnu.org; Fri, 09 Nov 2012 14:38:55 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:48124) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TWuPm-000435-Dr for bug-gnu-emacs@gnu.org; Fri, 09 Nov 2012 14:38:54 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1TWuPu-0003Gn-TM for bug-gnu-emacs@gnu.org; Fri, 09 Nov 2012 14:39:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 09 Nov 2012 19:39:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 12829 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 12829-submit@debbugs.gnu.org id=B12829.135248991012527 (code B ref 12829); Fri, 09 Nov 2012 19:39:02 +0000 Original-Received: (at 12829) by debbugs.gnu.org; 9 Nov 2012 19:38:30 +0000 Original-Received: from localhost ([127.0.0.1]:58375 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TWuPK-0003Ft-Le for submit@debbugs.gnu.org; Fri, 09 Nov 2012 14:38:30 -0500 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:60831) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TWuP9-0003FM-Fx for 12829@debbugs.gnu.org; Fri, 09 Nov 2012 14:38:18 -0500 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MD800L00JO6DW00@a-mtaout22.012.net.il> for 12829@debbugs.gnu.org; Fri, 09 Nov 2012 21:38:02 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MD800L3XJVDC7I0@a-mtaout22.012.net.il>; Fri, 09 Nov 2012 21:38:02 +0200 (IST) In-reply-to: <509D529F.9090106@optusnet.com.au> X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:66709 Archived-At: > Date: Fri, 09 Nov 2012 18:59:43 +0000 > From: Stephen Powell > > > Did this problem happen again since the original report? If it does > > happen from time to time, I might ask you to run Emacs under GDB > > with a couple of breakpoints in strategic places, because usually > > when dead_child's handle is NULL, it is too late: the evidence of > > the crime is already forgotten. > > Sure. It happens frequently but not always. OK. There;s only 1 place where the handle of the process is set to NULL. Here: static void reap_subprocess (child_process *cp) { if (cp->procinfo.hProcess) { /* Reap the process */ #ifdef FULL_DEBUG /* Process should have already died before we are called. */ if (WaitForSingleObject (cp->procinfo.hProcess, 0) != WAIT_OBJECT_0) DebPrint (("reap_subprocess: child fpr fd %d has not died yet!", cp->fd)); #endif CloseHandle (cp->procinfo.hProcess); <<<<<<<<<<<<<<<<<<<<<<< cp->procinfo.hProcess = NULL; (One other place is when the process is launched, but I don't think this is our case.) So please put a breakpoint on this line, like this: (gdb) break w32proc.c:1096 (gdb) commands > bt 6 > p cp->pid > continue > end In addition, please put a breakpoint here: static bool process_status_retrieved (pid_t desired, pid_t have, int *status) { if (have < 0) { /* Invoke waitpid only with a known process ID; do not invoke waitpid with a nonpositive argument. Otherwise, Emacs might reap an unwanted process by mistake. For example, invoking waitpid (-1, ...) can mess up glib by reaping glib's subprocesses, so that another thread running glib won't find them. */ do have = waitpid (desired, status, WNOHANG | WUNTRACED); while (have < 0 && errno == EINTR); } return have == desired; <<<<<<<<<<<<<<<<<<<<<<<<<< } Like this: (gdb) process.c:6278 if have != desired (gdb) commands > p have > p desired > p status > continue > end Then run Emacs as you normally would, and tell if these breakpoints ever break, and if so, what do you see there. The breakpoint commands arrange for GDB to continue Emacs after it reports the values as specified in the breakpoint commands. Thanks. > > If that GDB session is still active, can you show the entire list in > > deleted_pid_list? The 'pp' command should be able to display it in > > a human-readable format. > > (gdb) pp deleted_pid_list > (5144 5412) Interesting. I need to think...