Message139610
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. |
|
Date |
User |
Action |
Args |
2011-07-01 21:49:50 | neologix | set | recipients:
+ neologix, eric.smith, skrah, mik_os |
2011-07-01 21:49:50 | neologix | set | messageid: <1309556990.34.0.134695489363.issue12468@psf.upfronthosting.co.za> |
2011-07-01 21:49:49 | neologix | link | issue12468 messages |
2011-07-01 21:49:49 | neologix | create | |
|