Hi,
I'm using Ondřej Surý's ppa which was recently upgraded to PHP 7.0.3. My
test-suite is causing segmentation faults since 7.0.0 RC5, including the
7.0.3 release.
I can reproduce this consistently by running my test-suite in PHPUnit.
Identifying the tests executing when the fault occurs (using --debug)
and rerunning them one-by-one does not reproduce the segmentation faults.
I'm running this on Ubuntu 14.04.3 LTS. My application is built on with
Laravel 5.1 and Doctrine 2.5. I'm using PHPUnit 4.8 and an in-memory
sqlite database for the tests. (I'm mentioning this to convey what type
of code is running.)
My test-suite works on PHP 5.6 and HHVM.
I've got a gist with a gdb backtrace, with and without opcache. (There's
no difference.)
With: https://gist.github.com/sisve/0f75be357e557d439c19
Without: https://gist.github.com/sisve/01542193a27fd9da2b7b
I've verified that the opcache is disabled by '/usr/bin/php7.0 -i | grep
"opcache.enable"' not returning anything, and '/usr/bin/php7.0 -m' does
not contain any entry for opcache. (I'm unsure if this is enough.)
I've got some older backtraces from my previous failures. These may be
related, or related to something totally different. These have unknown
opcache-status (probably enabled).
PHP 7.0.2: https://gist.github.com/sisve/05b4c4075ef223c4ab52
PHP 7.0.0-RC?: https://gist.github.com/sisve/fe8e1b85b4cc488ff457
PHP 7.0.0-RC5: https://gist.github.com/sisve/7ce5980e05068972b8e6
PHP 7.0.0-RC5: https://gist.github.com/sisve/ad318ca820a38bdb8133
I've been whining some time on irc about this, and finally got my thumb
out of my behind to write this email.
I doubt that these traces are enough to identify and solve the problem.
What can I do to gather more information and debug this further?
// Simon
Hi,
I'm using Ondřej Surý's ppa which was recently upgraded to PHP 7.0.3. My
test-suite is causing segmentation faults since 7.0.0 RC5, including the
7.0.3 release.I can reproduce this consistently by running my test-suite in PHPUnit.
Identifying the tests executing when the fault occurs (using --debug)
and rerunning them one-by-one does not reproduce the segmentation faults.I'm running this on Ubuntu 14.04.3 LTS. My application is built on with
Laravel 5.1 and Doctrine 2.5. I'm using PHPUnit 4.8 and an in-memory
sqlite database for the tests. (I'm mentioning this to convey what type
of code is running.)My test-suite works on PHP 5.6 and HHVM.
I've got a gist with a gdb backtrace, with and without opcache. (There's
no difference.)
With: https://gist.github.com/sisve/0f75be357e557d439c19
Without: https://gist.github.com/sisve/01542193a27fd9da2b7bI've verified that the opcache is disabled by '/usr/bin/php7.0 -i | grep
"opcache.enable"' not returning anything, and '/usr/bin/php7.0 -m' does
not contain any entry for opcache. (I'm unsure if this is enough.)I've got some older backtraces from my previous failures. These may be
related, or related to something totally different. These have unknown
opcache-status (probably enabled).
PHP 7.0.2: https://gist.github.com/sisve/05b4c4075ef223c4ab52
PHP 7.0.0-RC?: https://gist.github.com/sisve/fe8e1b85b4cc488ff457
PHP 7.0.0-RC5: https://gist.github.com/sisve/7ce5980e05068972b8e6
PHP 7.0.0-RC5: https://gist.github.com/sisve/ad318ca820a38bdb8133I've been whining some time on irc about this, and finally got my thumb
out of my behind to write this email.I doubt that these traces are enough to identify and solve the problem.
What can I do to gather more information and debug this further?
Interesting.
The traces tell us some really vague clue, we'd really need a reproducer.
It seems to be involving generators triggered through reflection,
faulting on a foreach() by value.
However, can you confirm that you don't reproduce with a debug build
of PHP ? (exact same reproducer)
This is really weird. You may try -O0 -g only.
Julien.Pauli
Hi,
I'm using Ondřej Surý's ppa which was recently upgraded to PHP 7.0.3. My
test-suite is causing segmentation faults since 7.0.0 RC5, including the
7.0.3 release.I can reproduce this consistently by running my test-suite in PHPUnit.
Identifying the tests executing when the fault occurs (using --debug)
and rerunning them one-by-one does not reproduce the segmentation faults.I'm running this on Ubuntu 14.04.3 LTS. My application is built on with
Laravel 5.1 and Doctrine 2.5. I'm using PHPUnit 4.8 and an in-memory
sqlite database for the tests. (I'm mentioning this to convey what type
of code is running.)My test-suite works on PHP 5.6 and HHVM.
I've got a gist with a gdb backtrace, with and without opcache. (There's
no difference.)
With: https://gist.github.com/sisve/0f75be357e557d439c19
Without: https://gist.github.com/sisve/01542193a27fd9da2b7bI've verified that the opcache is disabled by '/usr/bin/php7.0 -i | grep
"opcache.enable"' not returning anything, and '/usr/bin/php7.0 -m' does
not contain any entry for opcache. (I'm unsure if this is enough.)I've got some older backtraces from my previous failures. These may be
related, or related to something totally different. These have unknown
opcache-status (probably enabled).
PHP 7.0.2: https://gist.github.com/sisve/05b4c4075ef223c4ab52
PHP 7.0.0-RC?: https://gist.github.com/sisve/fe8e1b85b4cc488ff457
PHP 7.0.0-RC5: https://gist.github.com/sisve/7ce5980e05068972b8e6
PHP 7.0.0-RC5: https://gist.github.com/sisve/ad318ca820a38bdb8133I've been whining some time on irc about this, and finally got my thumb
out of my behind to write this email.I doubt that these traces are enough to identify and solve the problem.
What can I do to gather more information and debug this further?Interesting.
The traces tell us some really vague clue, we'd really need a reproducer.
It seems to be involving generators triggered through reflection,
faulting on a foreach() by value.However, can you confirm that you don't reproduce with a debug build
of PHP ? (exact same reproducer)
This is really weird. You may try -O0 -g only.Julien.Pauli
Hi,
At least the latest traces comes from the php7.0-dbg package. If I
recall correctly the normal php7.0 package caused very
hard-to-understand backtraces with memory addresses instead of proper
function names.
I've recompiled the latest from master on a vagrant machine
(marcus/php7dev) that calls configure with --enable-debug. However, I do
not speak configure-ish so I do not know if that's enough use the
requested compilation flags.
I am unable to reproduce the error with this recompiled source, both
with the /usr/local/php70/bin/php and /usr/local/php70-debug/bin/php.
This is the same experience I had with earlier releases, where I have
been unable to reproduce the segmentation faults when recompiling (but
always have them occur from the ppa).
Is there any guide for compiling the source? I could attempt to setup a
new virtual machine with Ubuntu 14.04 (instead of php7dev's Debian) to
reproduce the error, but I do know know the steps needed to compile
everything.
The newly build, and working, versions:
/usr/local/php70/bin/php --version:
PHP 7.0.4-dev (cli) (built: Feb 5 2016 19:14:08) ( NTS )
Copyright (c) 1997-2016 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2016 Zend Technologies
with Zend OPcache v7.0.6-dev, Copyright (c) 1999-2016, by Zend
Technologies
/usr/local/php70-debug/bin/php --version:
PHP 7.0.4-dev (cli) (built: Feb 5 2016 19:19:10) ( NTS DEBUG )
Copyright (c) 1997-2016 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2016 Zend Technologies
with Zend OPcache v7.0.6-dev, Copyright (c) 1999-2016, by Zend
Technologies
// Simon
I am unable to reproduce the error with this recompiled source, both
with the /usr/local/php70/bin/php and /usr/local/php70-debug/bin/php.
This is the same experience I had with earlier releases, where I have
been unable to reproduce the segmentation faults when recompiling (but
always have them occur from the ppa).Is there any guide for compiling the source? I could attempt to setup a
new virtual machine with Ubuntu 14.04 (instead of php7dev's Debian) to
reproduce the error, but I do know know the steps needed to compile
everything.The newly build, and working, versions:
/usr/local/php70/bin/php --version:
PHP 7.0.4-dev (cli) (built: Feb 5 2016 19:14:08) ( NTS )
Copyright (c) 1997-2016 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2016 Zend Technologies
with Zend OPcache v7.0.6-dev, Copyright (c) 1999-2016, by Zend
Technologies/usr/local/php70-debug/bin/php --version:
PHP 7.0.4-dev (cli) (built: Feb 5 2016 19:19:10) ( NTS DEBUG )
Copyright (c) 1997-2016 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2016 Zend Technologies
with Zend OPcache v7.0.6-dev, Copyright (c) 1999-2016, by Zend
Technologies
"php -i" will show you the configure flags that were used to build it,
so you could try to match those to see if you can reproduce with sources
from php.net. Otherwise, if it is something that only happens with the
distro build then there isn't a while lot we can do to help you.
-Rasmus
I am unable to reproduce the error with this recompiled source, both
with the /usr/local/php70/bin/php and /usr/local/php70-debug/bin/php.
This is the same experience I had with earlier releases, where I have
been unable to reproduce the segmentation faults when recompiling (but
always have them occur from the ppa).Is there any guide for compiling the source? I could attempt to setup a
new virtual machine with Ubuntu 14.04 (instead of php7dev's Debian) to
reproduce the error, but I do know know the steps needed to compile
everything.The newly build, and working, versions:
/usr/local/php70/bin/php --version:
PHP 7.0.4-dev (cli) (built: Feb 5 2016 19:14:08) ( NTS )
Copyright (c) 1997-2016 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2016 Zend Technologies
with Zend OPcache v7.0.6-dev, Copyright (c) 1999-2016, by Zend
Technologies/usr/local/php70-debug/bin/php --version:
PHP 7.0.4-dev (cli) (built: Feb 5 2016 19:19:10) ( NTS DEBUG )
Copyright (c) 1997-2016 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2016 Zend Technologies
with Zend OPcache v7.0.6-dev, Copyright (c) 1999-2016, by Zend
Technologies"php -i" will show you the configure flags that were used to build it,
so you could try to match those to see if you can reproduce with sources
from php.net. Otherwise, if it is something that only happens with the
distro build then there isn't a while lot we can do to help you.-Rasmus
An update to avoid leaving the thread hanging in suspense.
I was in contact with Ondřej Surý, the author of the PPA I was using,
and got help in grabbing build-logs so that I should be able to
reproduce the compile locally, this time without all the optimization.
However, since I still do not speak configure-ish I failed to resolve
all packages/libraries needed for a complete build, but I managed to
smash my keyboard enough to get a working configure & make.
My test-suite now terminates like this:
PHPUnit 4.8.21 by Sebastian Bergmann and contributors.
Runtime: PHP 7.0.3
Configuration: /root/web/phpunit.xml
........................................... 43 / 1229 ( 3%)
........................................... 86 / 1229 ( 6%)
........................................... 129 / 1229 ( 10%)
........................................... 172 / 1229 ( 13%)
........................................... 215 / 1229 ( 17%)
...............R........................... 258 / 1229 ( 20%)
........................................... 301 / 1229 ( 24%)
........................................... 344 / 1229 ( 27%)
.R.R.....................R................. 387 / 1229 ( 31%)
........................................... 430 / 1229 ( 34%)
........................................... 473 / 1229 ( 38%)
........................................... 516 / 1229 ( 41%)
........................................... 559 / 1229 ( 45%)
........................................... 602 / 1229 ( 48%)
........................................... 645 / 1229 ( 52%)
.php: /root/php-src/Zend/zend_execute.h:275:
zend_vm_stack_free_call_frame_ex: Assertion
`(executor_globals.vm_stack_top) > (zval *) (executor_globals.vm_stack)
&& (executor_globals.vm_stack_end) > (zval *)
(executor_globals.vm_stack) && (executor_globals.vm_stack_top) <=
(executor_globals.vm_stack_end)' failed.
Aborted (core dumped)
The failed assertion and my backtrace matches exactly that of
https://bugs.php.net/bug.php?id=71474 which was fixed a few days ago,
and is not part of the 7.0.3 release. It's part of the PHP-7.0 branch,
so I presume this will be fixed in the 7.0.4 release.
I've recompiled using the PHP-7.0 branch, and my test-suite works there.
I look forward to the 7.0.4 release!
// Simon
I am unable to reproduce the error with this recompiled source, both
with the /usr/local/php70/bin/php and /usr/local/php70-debug/bin/php.
This is the same experience I had with earlier releases, where I have
been unable to reproduce the segmentation faults when recompiling (but
always have them occur from the ppa).Is there any guide for compiling the source? I could attempt to setup a
new virtual machine with Ubuntu 14.04 (instead of php7dev's Debian) to
reproduce the error, but I do know know the steps needed to compile
everything.The newly build, and working, versions:
/usr/local/php70/bin/php --version:
PHP 7.0.4-dev (cli) (built: Feb 5 2016 19:14:08) ( NTS )
Copyright (c) 1997-2016 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2016 Zend Technologies
with Zend OPcache v7.0.6-dev, Copyright (c) 1999-2016, by Zend
Technologies/usr/local/php70-debug/bin/php --version:
PHP 7.0.4-dev (cli) (built: Feb 5 2016 19:19:10) ( NTS DEBUG )
Copyright (c) 1997-2016 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2016 Zend Technologies
with Zend OPcache v7.0.6-dev, Copyright (c) 1999-2016, by Zend
Technologies"php -i" will show you the configure flags that were used to build it,
so you could try to match those to see if you can reproduce with sources
from php.net. Otherwise, if it is something that only happens with the
distro build then there isn't a while lot we can do to help you.-Rasmus
An update to avoid leaving the thread hanging in suspense.
I was in contact with Ondřej Surý, the author of the PPA I was using,
and got help in grabbing build-logs so that I should be able to
reproduce the compile locally, this time without all the optimization.
However, since I still do not speak configure-ish I failed to resolve
all packages/libraries needed for a complete build, but I managed to
smash my keyboard enough to get a working configure & make.My test-suite now terminates like this:
PHPUnit 4.8.21 by Sebastian Bergmann and contributors.
Runtime: PHP 7.0.3
Configuration: /root/web/phpunit.xml........................................... 43 / 1229 ( 3%)
........................................... 86 / 1229 ( 6%)
........................................... 129 / 1229 ( 10%)
........................................... 172 / 1229 ( 13%)
........................................... 215 / 1229 ( 17%)
...............R........................... 258 / 1229 ( 20%)
........................................... 301 / 1229 ( 24%)
........................................... 344 / 1229 ( 27%)
.R.R.....................R................. 387 / 1229 ( 31%)
........................................... 430 / 1229 ( 34%)
........................................... 473 / 1229 ( 38%)
........................................... 516 / 1229 ( 41%)
........................................... 559 / 1229 ( 45%)
........................................... 602 / 1229 ( 48%)
........................................... 645 / 1229 ( 52%)
.php: /root/php-src/Zend/zend_execute.h:275:
zend_vm_stack_free_call_frame_ex: Assertion
`(executor_globals.vm_stack_top) > (zval *) (executor_globals.vm_stack)
&& (executor_globals.vm_stack_end) > (zval *)
(executor_globals.vm_stack) && (executor_globals.vm_stack_top) <=
(executor_globals.vm_stack_end)' failed.
Aborted (core dumped)The failed assertion and my backtrace matches exactly that of
https://bugs.php.net/bug.php?id=71474 which was fixed a few days ago,
and is not part of the 7.0.3 release. It's part of the PHP-7.0 branch,
so I presume this will be fixed in the 7.0.4 release.I've recompiled using the PHP-7.0 branch, and my test-suite works there.
I look forward to the 7.0.4 release!
Thank you very much for your persistence on this. It is motivating for
us when people put a bit of effort into tracking down issues. And yes,
that fix will be in 7.0.4. It came in too late to be part of 7.0.3.
-Rasmus