"for/while ... break(by any means) ... else" make sense?

Zachary Ware zachary.ware+pylist at gmail.com
Thu Jun 30 00:47:55 EDT 2016


On Wed, Jun 29, 2016 at 11:12 PM, Steven D'Aprano <steve at pearwood.info> wrote:
> On Thu, 30 Jun 2016 11:28 am, Chris Angelico wrote:
>
>> On Thu, Jun 30, 2016 at 10:27 AM, Steven D'Aprano <steve at pearwood.info>
>> wrote:
>>> Following os.abort(), the interpreter exits in the hardest, quickest
>>> manner possible.
>>
>> os.kill(os.getpid(), 9)
>>
>> Now THAT is the hardest way to abort. You ain't comin' back from this one!
>
> The docs say it will abort in the hardest way possible, by dumping core or
> equivalent. I *think* I recall seeing os.abort() actually segfault at some
> point, but I can't replicate that now.
>
> I tried to find the actual implementation of os.abort(), but I couldn't work
> out where it was or what it does. Can somebody enlighten me?

Right here: https://hg.python.org/cpython/file/default/Modules/posixmodule.c#l10528

Here's the entire implementation of os.abort:
{
    abort();
    /*NOTREACHED*/
    Py_FatalError("abort() called from Python code didn't abort!");
    return NULL;
}

abort(3) is a standard C function, see the manpage.  If execution
somehow makes it past the abort() call, Python does its best to make
sure it really doesn't by calling Py_FatalError, which dumps a scary
message to stderr along with any traceback it can get its hands on,
then calls abort() again.  I tried setting a signal handler for
SIGABRT (I tried `signal.signal(signal.SIGABRT, print)`), but it
didn't trigger a Py_FatalError call on OSX or Linux.

On Windows, abort() causes the "some.exe has stopped working" dialog
to pop up and "search for solutions".  Similarly, the Crash Reporter
pops up on OSX.

-- 
Zach



More information about the Python-list mailing list