homepage

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 :-)