[issue12468] longjmp causes uninitialized stack frame

[Charles-François Natali]

Charles-François Natali <neologix at free.fr> added the comment:

longjmp() is used in only two places:

./Modules/fpectlmodule.c:        longjmp(PyFPE_jbuf, 1);
./Modules/readline.c:    longjmp(jbuf, 1);

Both use it to jump out of a signal handler, which can lead to undefined behaviour (see https://www.securecoding.cert.org/confluence/display/seccode/SIG32-C.+Do+not+call+longjmp()+from+inside+a+signal+handler).
Now, there are two reasons for this behaviour:
/lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x37)[0x7f2415de61d7]
/lib/x86_64-linux-gnu/libc.so.6(+0xfe169)[0x7f2415de6169]
/lib/x86_64-linux-gnu/libc.so.6(__longjmp_chk+0x33)[0x7f2415de60d3]

see the __longjmp_chk and __fortify_fail?
That means that Python's been compiled with gcc -D_FORTIFY_SOURCE option option, and the runtime check probably detects this and aborts the program (and the fact that it's a multi-threaded application probably.

The other reason is that it's a multi-threaded application, so if you end up doing a longjmp and restore the environment saved by another thread, you're screwed.

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12468>
_______________________________________