MantisBT - Xdebug
View Issue Details
0001555XdebugUsage problems (Wrong Results)public2018-05-30 15:182018-06-06 13:58
WindowsWindows2012 R2
0001555: PHP crash caused by XDebug fault
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?
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.
Problem signature:
  Problem Event Name: APPCRASH
  Application Name: php.exe
  Application Version:
  Application Timestamp: 5938ae36
  Fault Module Name: php_xdebug-2.6.0-7.1-vc14-nts-x86_64.dll
  Fault Module Version:
  Fault Module Timestamp: 5a6f8657
  Exception Code: c0000005
  Exception Offset: 00000000000241d1
  OS Version: 6.3.9600.
  Locale ID: 2057
  Additional Information 1: aed9
  Additional Information 2: aed9e3f9962ca4c3fb663bbe9b7e6354
  Additional Information 3: 89bc
  Additional Information 4: 89bceca976a62ec48f5bb220a093eb47
No tags attached.
Issue History
2018-05-30 15:18bseddonNew Issue
2018-06-03 21:26derickNote Added: 0004660
2018-06-03 21:26derickAssigned To => derick
2018-06-03 21:26derickStatusnew => feedback
2018-06-03 23:01bseddonNote Added: 0004663
2018-06-03 23:01bseddonStatusfeedback => assigned
2018-06-05 11:06derickNote Added: 0004665
2018-06-05 11:06derickStatusassigned => feedback
2018-06-05 14:49bseddonNote Added: 0004666
2018-06-05 14:49bseddonStatusfeedback => assigned
2018-06-05 14:53derickNote Added: 0004667
2018-06-05 17:25bseddonNote Added: 0004668
2018-06-05 17:26bseddonNote Edited: 0004668bug_revision_view_page.php?bugnote_id=4668#r442
2018-06-05 17:26bseddonNote Edited: 0004668bug_revision_view_page.php?bugnote_id=4668#r443
2018-06-05 19:22bseddonNote Added: 0004669
2018-06-05 19:23bseddonNote Edited: 0004669bug_revision_view_page.php?bugnote_id=4669#r445
2018-06-06 12:23derickNote Added: 0004670
2018-06-06 13:58bseddonNote Added: 0004671

2018-06-03 21:26   

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.

2018-06-03 23:01   
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';
use lyquidity\XPath2\XPath2Expression;

    $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";

echo "Finished\n";



Bill Seddon
2018-06-05 11:06   
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
Stack trace:
#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)
0000004 {main}
  thrown in /tmp/1555/vendor/lyquidity/xpath2/XPath2Context.php on line 54
2018-06-05 14:49   
Hi Derick

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.

Bill Seddon
2018-06-05 14:53   
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.
2018-06-05 17:25   
(edited on: 2018-06-05 17:26)
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 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.

2018-06-05 19:22   
(edited on: 2018-06-05 19:23)
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)

2018-06-06 12:23   
I can reproduce this now, but I am afraid that a fix is not going to be too easy.
2018-06-06 13:58   
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.

Best wishes.