bug#12829: 24.3.50; emacs_abort () called from w32proc.c:1128

[Eli Zaretskii <eliz@gnu.org>]

> Date: Fri, 09 Nov 2012 20:16:36 +0000
> From: Stephen Powell <stephen_powell@optusnet.com.au>
> CC: 12829@debbugs.gnu.org
> 
> Ok this breakpoint 4 seems to have triggered just before the crash
> 
> (gdb) break process.c:6278 if have != desired
> Breakpoint 4 at 0x101f310: file process.c, line 6278.
> (gdb) commands
> Type commands for breakpoint(s) 4, one per line.
> End with a line saying just "end".
> >p have
> >p desired
> >p status
> >continue
> >end

Thanks, that figures.  Basically, the modified code that handles
demise of child processes is incompatible with the emulated 'wait'
function, because it does not support waiting for a process by its
PID.  I think we will have to rewrite 'sys_wait' to emulate 'waitpid',
although I'll try first to come up with a simpler band-aid.

Paul, are there other supported platforms that use 'wait' here?  If
there are, they are in danger of the same problem, because the new
record_child_status_change assumes 'waitpid' functionality with the
first argument non-negative.

> Breakpoint 3, reap_subprocess (cp=0x144aaf0) at w32proc.c:1096
> 1096          cp->procinfo.hProcess = NULL;
> #0  reap_subprocess (cp=0x144aaf0) at w32proc.c:1096
> #1  0x01022d26 in sys_wait (status=0x88f264) at w32proc.c:1236
> #2  0x0101f2fb in process_status_retrieved (desired=8032, have=-1,
> status=0x88f264) at process.c:6274
> #3  0x0101f3be in record_child_status_change (pid=-1, w=256) at
> process.c:6344
> #4  0x0101f65d in handle_child_signal (sig=18) at process.c:6417
> #5  0x010e0f64 in deliver_process_signal (sig=18, handler=0x101f643
> <handle_child_signal>) at sysdep.c:1580
> $26 = 7176
> 
> Breakpoint 4, process_status_retrieved (desired=8032, have=7176,
> status=0x88f264) at process.c:6278
> 6278      return have == desired;
> $27 = 7176
> $28 = 8032
> $29 = (int *) 0x88f264

Just so my understanding of the exact scenario is better, could you
please add "bt 10" to the commands of breakpoint 4, the one set in
process_status_retrieved, and again post the full transcript of the
GDB session leading to the crash?

Thanks.