View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0001555||Xdebug||Uncategorized||public||2018-05-30 14:18||2021-03-17 10:14|
|Status||resolved||Resolution||no change required|
|Platform||Windows||OS||Windows||OS Version||2012 R2|
|Summary||0001555: PHP crash caused by XDebug fault|
|Description||I am seeing PHP CLI crashing consistently in an application. I have included the information provided by PHP/Windows about the crash. This identifies XDebug 2.6 as the cause of the fault.|
The issue occurs when using 2.6 with either PHP 7.1 or 7.2. The issue does not occur when using XDebug 2.5 with PHP 7.1. The issue occurs when using XDebug 2.7 alpha. A common denominator is that versions causing the issue are compiled using VC 15.
The fault occurs when a descendant of class \Exception is thrown.
A slightly different behaviour is experienced if the native Exception is thrown. In this case the exception will run unless there is a break point somewhere in the function containing the 'throw' statement.
The issue occurs in Eclipse and and also at the command line so long as XDebug is referenced in the ini file.
** The problem goes away if xdebug.collect_params is disabled. **
On Windows exception codes ending in 0005 (as in this case) can indicate a problem writing to a resource. The documentation says that from version 2.x param information is written to disk. Could there be an issue writing to disk? What file is used to store param information?
Is there any alternative to disabling parameter value collection?
|Steps To Reproduce||I have been unable to find a simple case (outside the application) that causes the same issue possibly because the issue occurs at a depth of 12 functions. |
|Additional Information||Problem signature:|
Problem Event Name: APPCRASH
Application Name: php.exe
Application Version: 22.214.171.124
Application Timestamp: 5938ae36
Fault Module Name: php_xdebug-2.6.0-7.1-vc14-nts-x86_64.dll
Fault Module Version: 126.96.36.199
Fault Module Timestamp: 5a6f8657
Exception Code: c0000005
Exception Offset: 00000000000241d1
OS Version: 6.3.9600.2.0.0.272.7
Locale ID: 2057
Additional Information 1: aed9
Additional Information 2: aed9e3f9962ca4c3fb663bbe9b7e6354
Additional Information 3: 89bc
Additional Information 4: 89bceca976a62ec48f5bb220a093eb47
|Tags||No tags attached.|
I'm going to need more than this to debug and find this problem. At least a (small) reproducible case. If that means making a Git repository for me to clone and run, that works as well.
I would *love* be able to provide you a simple or small example. Alas, I cannot find one. Maybe at least I can provide you with something that will demonstrate the the issue with modest effort on your part (but still involving a large library).
Install the library by running the following composer command (assuming 'composer' is a command that runs the composer.phar):
composer require lyquidity/xpath2:dev-master lyquidity/utilities:dev-master lyquidity/xml:dev-master --prefer-dist
You may be familiar with composer but in case not, create a folder (any folder) and at the command line change to that folder and run the command above. It will download the relevant files and store them in sub-folders of a folder called 'vendor' and create two files one called composer.json and one called composer.lock.
At the moment the XPath 2.0 library installed by the composer command is only tested on Windows.
Then run the short script below using 7.1 or later. The XPath expression evaluated is invalid and the evaluator is expected to report an XPath 2.0 specification prescribed error code. The evaluator identifies the issue and throws an XPath2Exception that contains the prescribed error code.
When XDebug 2.6 is used and xdebug.collect_params is disabled then you see the message from the 'catch' clause. That is, it works correctly. When xdebug.collect_params is enabled then PHP crashes with a fault generated by XDebug 2.6. At least that is my experience.
It is the act of throwing the exception that seems to generate the fault. To save you hunting it down, the XPath2Exception is thrown in ./vendor/lyquidity/xpath2/Proxy/FloatProxy.php line 237. The exception instance is created OK. The fault occurs when the 'throw' statement is executed.
require_once __DIR__ . '/vendor/autoload.php';
$result = XPath2Expression::EvaluateWithArg( "xs:float(\"NaN\") idiv 1", null );
catch ( Exception $ex )
echo "This exception should appear. When xdebug.collect_params is enabled PHP will crash.\n";
These instructions are good enough. However, they don't work. Even without Xdebug loaded (notice the -n in the CMD command), I get an exception:
derick@singlemalt:/tmp/1555 $ php -n test.php
Fatal error: Uncaught Error: Class 'lyquidity\xml\MS\XmlNameTable' not found in /tmp/1555/vendor/lyquidity/xpath2/XPath2Context.php:54
#0 /tmp/1555/vendor/lyquidity/xpath2/XPath2Expression.php(273): lyquidity\XPath2\XPath2Context->__construct(NULL)
#1 /tmp/1555/vendor/lyquidity/xpath2/XPath2Expression.php(178): lyquidity\XPath2\XPath2Expression::Compile('xs:float("NaN")...', NULL)
0000002 /tmp/1555/vendor/lyquidity/xpath2/XPath2Expression.php(166): lyquidity\XPath2\XPath2Expression::EvaluateWithArgAndResolver('xs:float("NaN")...', NULL, NULL)
0000003 /tmp/1555/test.php(7): lyquidity\XPath2\XPath2Expression::EvaluateWithArg('xs:float("NaN")...', NULL)
thrown in /tmp/1555/vendor/lyquidity/xpath2/XPath2Context.php on line 54
I can reproduce your error when running on Linux. As I mentioned in an earlier post, and I should have mentioned again in the post with the instructions, the library has not yet been tested on Linux. The error I see occurs on Windows.
If it is important to you to be able to run the issue on Linux let me know and let you know when you can refresh to install a version that works on Linux.
I don't have Windows, so I'll need it to at least *run* on Linux—it's fine for now if you can't reproduce the crash on Linux.
I bet the fatal error error is just a capitalisation issue in a class name.
I have updated the project to fix the issue on Linux. My guess was some capitalization issue as well but it turns out the problem was in the auto loader of the xml sub-project. It assumed the the file name could include the classname to generate the file name but the classname contains the namespace which uses backslashes. This is OK on windows. On Linux not so much.
Although I updated the project references on packagist.org I found could not just update and instead had to reinstall. First it was necessary to remove the vendor directory and the composer.json and composer.lock files.
I also discovered that it was necessary to install the bcmath, mbstring and intl extensions.
I can confirm the same issue arises on Linux when collect_params is enabled. The message emitted is 'Segmentation fault'. It runs correctly when collect_params is not enabled.
In this example I used PHP 7.2 with XDebug 2.6 on Amazon Linux 2 (which is a RHEL/Fedora clone)
||I can reproduce this now, but I am afraid that a fix is not going to be too easy.|
It's great that you are able to reproduce it. At least you know of the issue and are in a position to investigate. Maybe some point in the future you will have a moment of inspiration and be able to address it. In the meantime I'll just make sure collect_params is disabled.
||Is this issue still relevant to you?|
||Probably not. At the time the issue was reported i was using Eclipse and PHP 7.1/7.2 and XDebug 2.6. Plus I was creating and debugging an XPath 2.0 processor that uses recursion to proceess queries. None of these are true today as most work uses PHP 8.0, XDebug 3.x on VS Code while the XPath processor is stable and untouched for a while now. Plus I was able to get by not collecting params.|
||OK. I'm closing it out then. Thanks!|
|2018-05-30 14:18||bseddon||New Issue|
|2018-06-03 20:26||derick||Note Added: 0004660|
|2018-06-03 20:26||derick||Assigned To||=> derick|
|2018-06-03 20:26||derick||Status||new => feedback|
|2018-06-03 22:01||bseddon||Note Added: 0004663|
|2018-06-03 22:01||bseddon||Status||feedback => assigned|
|2018-06-05 10:06||derick||Note Added: 0004665|
|2018-06-05 10:06||derick||Status||assigned => feedback|
|2018-06-05 13:49||bseddon||Note Added: 0004666|
|2018-06-05 13:49||bseddon||Status||feedback => assigned|
|2018-06-05 13:53||derick||Note Added: 0004667|
|2018-06-05 16:25||bseddon||Note Added: 0004668|
|2018-06-05 16:26||bseddon||Note Edited: 0004668|
|2018-06-05 16:26||bseddon||Note Edited: 0004668|
|2018-06-05 18:22||bseddon||Note Added: 0004669|
|2018-06-05 18:23||bseddon||Note Edited: 0004669|
|2018-06-06 11:23||derick||Note Added: 0004670|
|2018-06-06 12:58||bseddon||Note Added: 0004671|
|2020-03-12 16:35||derick||Category||Usage problems (Wrong Results) => Variable Display|
|2020-03-12 16:38||derick||Category||Variable Display => Uncategorized|
|2021-03-17 09:27||derick||Status||assigned => feedback|
|2021-03-17 09:27||derick||Note Added: 0005748|
|2021-03-17 09:53||bseddon||Note Added: 0005777|
|2021-03-17 09:53||bseddon||Status||feedback => assigned|
|2021-03-17 10:14||derick||Status||assigned => resolved|
|2021-03-17 10:14||derick||Resolution||open => no change required|
|2021-03-17 10:14||derick||Note Added: 0005780|