Author peadar
Recipients bkabrda, justbennet, markmcclain, miss-islington, opoplawski, peadar, vstinner
Date 2019-08-15.09:41:18
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <CAO1X7juYo3-QeZcFUoUaXiuHZQ1KUkZjf+LtVPpxZxDhCDP=VA@mail.gmail.com>
In-reply-to <1565818374.03.0.188467063522.issue21131@roundup.psfhosted.org>
Content
On Wed, 14 Aug 2019 at 22:32, STINNER Victor <report@bugs.python.org> wrote:

>
> We are talking abou the faulthandler_user() function of
> Modules/faulthandler.c. It is implemented in pure C, it doesn't allocate
> memory on the heap, it uses a very small set of functions (write(),
> sigaction(), raise()) and it tries to minimize its usage of the stack
> memory.
>

I was more concerned about what was happening in the chained handler, which
will also run on the restricted stack: I had assumed that was potentially
running arbitrary python code. That's actually probably incorrect, now that
I think about it, but it's harder to infer much about its stack usage
directly in faulthandler.c. I'll take a look (just to satisfy myself, more
than anything)

> It is very different than the traceback module which is implemented in
> pure Python.
>

Right, totally - I had jumped to the conclusion that it would end up
executing in the interpreter via the chain, but, as I say, that's probably
wrong. I'm not sure what guarantees the chained signal handler makes about
its stack usage. (Will educate myself)

> faulthandler is really designed to debug segmentation fault, stack
> overflow, Python hang (like a deadlock), etc.

> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <https://bugs.python.org/issue21131>
> _______________________________________
>
History
Date User Action Args
2019-08-15 09:41:18peadarsetrecipients: + peadar, vstinner, bkabrda, opoplawski, miss-islington, markmcclain, justbennet
2019-08-15 09:41:18peadarlinkissue21131 messages
2019-08-15 09:41:18peadarcreate