[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#12829: 24.3.50; emacs_abort () called from w32proc.c:1128
From: |
Eli Zaretskii |
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@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.
bug#12829: 24.3.50; emacs_abort () called from w32proc.c:1128, Stephen Powell, 2012/11/10
bug#12829: 24.3.50; emacs_abort () called from w32proc.c:1128, Stephen Powell, 2012/11/10