Charles-François Natali <neolo...@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 <rep...@bugs.python.org> <http://bugs.python.org/issue12468> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
