STINNER Victor added the comment: > 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.) ---------- Added file: http://bugs.python.org/file38470/volatile.patch _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue23654> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
