Bug #66499 [Fbk->NoF]: strace segfault with opcache > php 5.5.7

Edit report at https://bugs.php.net/bug.php?id=66499&edit=1 ID: 66499 Updated by: php-bugs@lists.php.net Reported by: spam2 at rhsoft dot net Summary: strace segfault with opcache > php 5.5.7 -Status: Feedback +Status: No Feedback Type: Bug Package: opcache Operating System: Linux PHP Version: 5.5.8 Assigned To: cmb Private report: N New Comment: No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Re-Opened". Thank you. Previous Comments: ------------------------------------------------------------------------ [2021-07-08 11:17:38] cmb@php.net Is this still an issue with any of the actively supported PHP versions[1]? [1] <https://www.php.net/supported-versions.php> ------------------------------------------------------------------------ [2014-01-17 16:40:48] spam2 at rhsoft dot net i tried that, running with gdb it does not happen :-( however, opcache.optimization_level = 0 does not crash at all, so obviously the optimizer is broken after 5.5.6 and as you said "it wasn't noticed because many people run with the optimization_level set to 0" the main question is why this is not the default if nobody cares about? > As for one-commit per tarball. Who does that? > That's what git bisect is for i do not work with GIT at all nor i am C developer i am a pure php-developer wokring with subversion and a sysadmin knowing to handle rpmbuild well ________________________________________________________________ gdb /usr/sbin/httpd GNU gdb (GDB) Fedora 7.6.1-46.fc19 Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /usr/sbin/httpd...(no debugging symbols found)...done. (gdb) run -X Starting program: /usr/sbin/httpd -X [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Detaching after fork from child process 13712. Detaching after fork from child process 13714. Detaching after fork from child process 13723. Detaching after fork from child process 13725. Detaching after fork from child process 13727. Detaching after fork from child process 13729. Detaching after fork from child process 13755. Detaching after fork from child process 13757. Detaching after fork from child process 13759. Detaching after fork from child process 13761. Detaching after fork from child process 13770. Detaching after fork from child process 13772. Detaching after fork from child process 13774. Detaching after fork from child process 13776. Detaching after fork from child process 13789. Detaching after fork from child process 13791. Detaching after fork from child process 13796. ------------------------------------------------------------------------ [2014-01-17 16:22:00] rasmus@php.net Nope, we are only interested in the symbols from opcache and possibly php, so it is sufficient to not strip opcache.so and get us the gdb backtrace from that to start with. As for one-commit per tarball. Who does that? That's what git bisect is for. ------------------------------------------------------------------------ [2014-01-17 09:31:45] spam2 at rhsoft dot net if you *really* would be interested in solve that problem someone would provide tarballs of opcache-source from 5.5.6 to 5.5.7 containing only one commit or simply would review the code changes as otehr upstream projects do > An strace is not useful why is it for other upstream projects and not for PHP? > We need a reproducing code snippet there is no "code snippet", there are whole applications there is a 3000 LOC large library and there is a script using it, MySQL and a Asterisk phonebox via passthru() and the other application are 250000 LOC > or a gdb backtrace you are aware that this means compile apache, apache-modules, php-core again without strip debug symbols and install hundrets of megabytes debug-packages and that we are talking about a production machine? you could provide opcache-tarballs from 5.5.6 to 5.5.7 each containing only one change - the extension-build takes a few seconds and it should be easy that way to identify by knowing now it is the optimizer someone could also review the changes from 5.5.6 to 5.5.7 critical or even try to solve the intention of the changes in a different way - sadly there are too few upstream-developers like dbmail where you find a problem and most of the time need not more to say then between which commits in case of only a few change lines of code ------------------------------------------------------------------------ [2014-01-17 00:30:00] rasmus@php.net An strace is not useful. We need a reproducing code snippet or a gdb backtrace. ------------------------------------------------------------------------ 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=66499 -- Edit this bug report at https://bugs.php.net/bug.php?id=66499&edit=1