Bug #81580 [Com]: SEGV (probably stack limits) while autoloading from a shutdown function

Edit report at https://bugs.php.net/bug.php?id=81580&edit=1 ID: 81580 Comment by: kimsay12 at aol dot com Reported by: patrick dot schaaf at yalwa dot com Summary: SEGV (probably stack limits) while autoloading from a shutdown function Status: Open Type: Bug Package: Reproducible crash Operating System: openSUSE Tumbleweed PHP Version: 8.0.12 Block user comment: N Private report: N New Comment: (https://www.barstoolsports.com/blog/3465562/mark-wahlberg-has-officially-spoken-on-an-entourage-reboot-and-its-promising)github.com Previous Comments: ------------------------------------------------------------------------ [2023-02-01 08:13:31] brandencaufield at gmail dot com Thanks for the info i will try to figure it out for more (https://apps.apple.com/vn/app/dinar-chronics/id1642043789)github.com ------------------------------------------------------------------------ [2021-11-04 14:48:52] patrick dot schaaf at yalwa dot com I will try that valgrind approach on my dev server, thanks for the hint. ------------------------------------------------------------------------ [2021-11-04 14:46:20] patrick dot schaaf at yalwa dot com Thanks for your reply, Niki. This can't be something generally bad about our detect_bot class source / file, as we are really using that sprintf+detect_bot sequence for almost all web requests of our production codebase, and that has been active with php 8 (8.0.9, mostly, but now also 8.0.12) on several dozen web developer VMs, as well as a few internal web tools servers used every day by employees. That specific coredump with that backtrace, only triggered on our public facing imageserver, and there, quite quickly and repeatedly. So I fear this will be some corruption elsewhere cross-interfering. Regardless, given your hint that a long sequence of concatenations can lead to that backtrace, I can confirm that we indeed DO have something like that in the file, during define() of a few constants (building up large many-alternative regexpen). Quite needlessly so, just for readability, maybe I should reconsider that... The larger of these, actually concatenates 728 times, which times three, almost gives the depth of that backtrace. So call me silly for that. Nevertheless, would you have any idea on how to debug this further regarding the actual SEGV seen there, or a suspicion I could followup on to try to make it reproducible? ------------------------------------------------------------------------ [2021-11-04 14:32:45] nikic@php.net If this is due to memory corruption, then running apache under valgrind (using USE_ZEND_ALLOC=0 valgrind httpd -X I believe) may show where it originates (possibly also reliably without requiring multiple requests). ------------------------------------------------------------------------ [2021-11-04 14:22:01] nikic@php.net Not sure this is a stack overflow, the crash location is pretty typical for memory corruption. Deeply nested zend_compile_binary_op() can occur for code containing a very large "a" . "b" . "c" style expression with many operands. Is something like that present in the detect_bot file? ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=81580 -- Edit this bug report at https://bugs.php.net/bug.php?id=81580&edit=1