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>, Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 12829 <at> debbugs.gnu.org
Subject: bug#12829: 24.3.50; emacs_abort () called from w32proc.c:1128
Date: Sat, 10 Nov 2012 10:27:10 +0200

> Date: Fri, 09 Nov 2012 20:16:36 +0000
> From: Stephen Powell <stephen_powell <at> optusnet.com.au>
> CC: 12829 <at> 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.

Previous Next

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