richi: https://github.com/nemomobile-packages/python3/blob/master/Modules/faulthandler.c#L903 richi: LD_LIBRARY_PATH=/builddir/build/BUILD/Python-3.4.2/build/debug/ /builddir/build/BUILD/Python-3.4.2/build/debug/python -E -c 'import faulthandler; faulthandler.enable(); faulthandler._stack_overflow()' i.e. what Jakub says richi: the function certainly shouldn't return address of a local variable; dunno what would happen if you just cast that to an integer though richi: and it better should do something to avoid tail calls there richi: the if (sp < min_sp |
max_sp < sp) is also undefined behavior ah, I get python segfaults building some extensions instead (but can't reproduce locally...) jakub: so what's your fix? richi: I don't have a fix, we just documented it not to be a gcc fault, we'll leave fixing to the package maintainer ah, I see richi: dunno if e.g. uintptr_t x; memcpy (&x, &sp, sizeof (x)); would DTRT and be portable enough richi: and then of course pass uintptr_t min_sp/max_sp, compare the x against that etc. well, just (uintptr_t)&buffer should be enough
faulthandler._stack_overflow() is written to crash. The comparison on stack pointers is just here to avoid an unlimited loop. A stack of 100 MB is something really large. I never seen an OS where faulthandler._stack_overflow() doesn't crash yet. Here is a patch using Py_uintptr_t instead of void*. Can someone test with GCC 5?
