GNU bug report logs - #12829
24.3.50; emacs_abort () called from w32proc.c:1128

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stephen Powell <stephen_powell <at> optusnet.com.au>
Cc: 12829 <at> debbugs.gnu.org
Subject: bug#12829: 24.3.50; emacs_abort () called from w32proc.c:1128
Date: Fri, 09 Nov 2012 11:41:33 +0200

> Date: Thu, 08 Nov 2012 15:48:54 +0000
> From: Stephen Powell <stephen_powell <at> optusnet.com.au>
> 
> (gdb) p *dead_child
> $2 = {
>   fd = 6,
>   pid = 3744,
>   char_avail = 0x5718,
>   char_consumed = 0x571c,
>   thrd = 0x5720,
>   hwnd = 0x0,
>   procinfo = {
>     hProcess = 0x0,
>     hThread = 0x0,
>     dwProcessId = 3744,
>     dwThreadId = 3964
>   },
>   status = 2,

It looks like Emacs was trying to reap a wrong process.  dead_child
says its PID is 3744, but record_child_status_change, up above it in
the call stack, thinks its PID was 5412:

> #4  0x0101f2c6 in record_child_status_change (pid=-1, w=256) at process.c:6344
>         deleted_pid = 5412
>         all_pids_are_fixnums = false
>         xpid = 21648
>         record_at_most_one_child = true
>         tail = 91890086

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.

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.

Thanks.

Previous Next

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