This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vstinner
Recipients WanderingLogic, vstinner
Date 2015-03-13.10:27:59
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1426242479.59.0.171794553559.issue23654@psf.upfronthosting.co.za>
In-reply-to
Content
> When the faulthandler module is compiled at -O3 (the default for non-debug builds) with a compiler that does tailcall optimization ...

test_faulthandler pass with GCC 4.9.2 (Fedora 21) when faulthandler.c is compiled in -O3 mode. I guess that such config doesn't support tailcall optimization.

I guess that this issue is currently specific to Intel C compiler (ICC), right?

> ... with a compiler that does tailcall optimization the Modules/faulthandler.c:stack_overflow() function may become an infinite loop that does not expand the stack.

Hum, I didn't expect that I would be so hard to write a reliable stack overflow :-) I modified recently the function in issue #23433 to a different issue with void*/intptr_t conversion.

My function writes into a buffer allocated on the stack. How the compiler avoids to allocate 4 KB for each loop iteration? It doesn't matter if the function is recursive or not, it only matters if each iteration allocates 4 KB on the stack.

I'm writing into the buffer allocated on the stack to ensure that the buffer is really allocated. Maybe the pattern is too reliable?

Can you try to mark the buffer with the volatile keyword? (See attached patch.) This keyword is already used in faulthandler_read_null() and faulthandler_sigfpe() to workaround issues with compiler optimizations. (See attached patch.)
History
Date User Action Args
2015-03-13 10:27:59vstinnersetrecipients: + vstinner, WanderingLogic
2015-03-13 10:27:59vstinnersetmessageid: <1426242479.59.0.171794553559.issue23654@psf.upfronthosting.co.za>
2015-03-13 10:27:59vstinnerlinkissue23654 messages
2015-03-13 10:27:59vstinnercreate