Author neologix
Recipients ezio.melotti, lambertv, ncoghlan, neologix, pitrou, vstinner
Date 2013-08-27.10:04:40
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <CAH_1eM2oP26pax83Et9fOndEJJw2FrohZMwS5sFXwO=oW153+g@mail.gmail.com>
In-reply-to <1377592056.61.0.475718560961.issue18623@psf.upfronthosting.co.za>
Content
The test works for me. The only problem is that faulthandler dumps a
stack: it might be better to use subprocess with stderr=devnull).

As for the status code, it looks like a bash bug:
"""
$ cat /tmp/test_core.py
import os

if os.fork() == 0:
    os.abort()
else:
    pid, status = os.waitpid(-1, 0)
    print("%d: %s" % (status, os.WCOREDUMP(status)))
$ python /tmp/test_core.py
134: True
$ ulimit -c 0
$ python /tmp/test_core.py
6: False
$ python -c "print(0x80 | 6)"
134
"""

And it's funny, because bash does detect the coredump generation, compare:
"""
$ python -c "import os; os.abort()"; echo $?
Abandon
134
"""

to

"""
$ python -c "import os; os.abort()"; echo $?
Abandon (core dumped)
134
"""

I had a quick look at the code, and indeed there's a bug: there's a
function rebuilding the exit status from the exit code:

"""
static int
process_exit_status (status)
     WAIT status;
{
  if (WIFSIGNALED (status))
    return (128 + WTERMSIG (status));
  else if (WIFSTOPPED (status) == 0)
    return (WEXITSTATUS (status));
  else
    return (EXECUTION_SUCCESS);
}
"""

Unfortunately, adding 128 sets the coredump flag every time,
regardless of the actual coredump status.
Never thought I'd encounter such a bug in bash :-)
History
Date User Action Args
2013-08-27 10:04:40neologixsetrecipients: + neologix, ncoghlan, pitrou, vstinner, ezio.melotti, lambertv
2013-08-27 10:04:40neologixlinkissue18623 messages
2013-08-27 10:04:40neologixcreate