Charles-François Natali added the comment: 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 :-) ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue18623> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com