Sam Kerr <kerr....@gmail.com> added the comment:
I was also able to get the stack smashing behavior with the following: OS: Linux slaptop 4.19.12-arch1-1-ARCH #1 SMP PREEMPT Fri Dec 21 13:56:54 UTC 2018 x86_64 GNU/Linux GCC: gcc (GCC) 8.2.1 20181127 I was able to track down the issue into the src/x86/ffi64.c file inside libffi. Because more than 4 (the #define'd MAX_CLASSES value in libffi) items were passed, libffi writes outside an array boundary, which is what causes the stack smashing. I forked libffi and added an assert to prove this is what is happening. You can find it at https://github.com/stkerr/libffi/commit/80bca6647702ffd846c655be14d8306ef24ca2dd. Just as a quick test, I tried to increase the MAX_CLASSES value to 40, which is far more than the 9 in the crashing example. I'm 99% positive changing the MAX_CLASSES magic value isn't the right way to solve this issue, but it may give a hint on the proper way to address it. I'm not sure at this point if this behavior is something for libffi to fix or how Python calls libffi though. I'll keep looking, but hopefully this helps someone else make some progress. ---------- nosy: +Sam.Kerr _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue22171> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
