View Issue Details

IDProjectCategoryView StatusLast Update
0001772XdebugUncategorizedpublic2020-04-04 11:08
Reporterbag64 Assigned To 
PriorityhighSeveritycrashReproducibilityalways
Status closedResolutionfixed 
Product Version2.9.4 
Target Version2.9.5Fixed in Version2.9.5 
Summary0001772: Crash with exception thrown inside a destructor
Description

PHP crashes when XDebug is enabled.
And this only happens when code is wrapped in a PHPunit test for some reason, here's a snipet of the code:

class X
{
public function __destruct(){
throw new \Exception('eee');
}
}

class InstanceTest extends \PHPUnit\Framework\TestCase
{

// This part is important, and is what's causing the crash:
private ?X $x = null;
function get_instance():X{return $this->x = $this->get_new_instance();}
function get_new_instance():X{return new X();}

public function test_instance()
{
    $this->get_instance();
    $this->assertTrue(true);
}

}

Result = Process finished with exit code -1073741819 (0xC0000005)

Steps To Reproduce

just run phpunit with instanceTest.php (file attached)

Additional Information

Tested on both: (same error)

php_xdebug-2.9.2-7.4-vc15-x86_64.dll
php_xdebug-2.9.4-7.4-vc15-x86_64.dll

PHPUnit version: 8.4.3

TagsNo tags attached.
Operating SystemWindows 7
PHP Version7.4.0-7.4.4

Activities

bag64

2020-04-02 17:47

reporter   ~0005362

I attached a complete workspace example (nothing to setup)
Just double click "crash_test_windows.bat" on Windows and see the crash in action.

I don't know about linux, but "crash_test_linux.sh" should also work in theory.

I hope this could help.

derick

2020-04-03 00:03

administrator   ~0005363

I can't reproduce this (on Linux). I had to do "rm -rf vendor" and "composer install" to make the code run, but I am not getting a crash (or a valgrind memory checking warning). Which settings do you have enabled for PHP/Xdebug? Can you check the html_errors, display_errors, and error_reporting settings, as well as the phpinfo section of Xdebug, and attach these as a file? You can get these by running "php -i" (but please leave out the things I didn't ask for).

bag64

2020-04-03 10:10

reporter   ~0005365

Would you like me to setup and attach a Standalone test environement (that includes php binaries) and upload it here for you to test and execute ?
In the meanwhile I will try to setup this and test it in linux and report back if I find anything.

derick

2020-04-03 10:18

administrator   ~0005366

Happy to test a specific set-up that you can make and share. I'm not quite sure what that would include though? I don't think this bug system wants really large files :-)

bag64

2020-04-03 11:32

reporter   ~0005367

Hi Derick. Yes I'm aware of the 5MB limit :( This is why I made this batch script for you,
and it is (x86) 32bits compatible so you can run in any Win7+ Virtual Machine painlessly.

You need to download: https://windows.php.net/downloads/releases/php-7.4.4-nts-Win32-vc15-x86.zip
And extract it in "./php" folder, WITHOUT overriding the exisiting files.

Also, you need to extract this in "C:\xdebug_crash" for it to work properly.

Once you setup the workspace, you will notice a curios phenomenon:
If you double click "crash_test.bat" it will crash, but if you edit "CrashTest.php" and replace

public function test_crash()
{
$this->get_instance();
$this->assertTrue(true);
}

by

public function test_crash()
{
$this->get_new_instance(); // <-- notice "new"
$this->assertTrue(true);
}

It will NOT crash ! weird huh..
Let me know if the workspace works for you and if you were able to see it crash.

bag64

2020-04-03 11:41

reporter   ~0005368

for sake of clarity here's the steps again:

1) Download "xdebug_crash.rar" above and extract content in "c:\xdebug_crash\"
2) Download "php-7.4.4-nts-Win32-vc15-x86.zip" above and extract content in "c:\xdebug_crash\php\"
3) Run "crash_test.bat" (Expecting crash)
4) Edit "CrashTest.php" and replace "get_instance" by "get_new_instance()" as explained above
5) Run "crash_test.bat" (Expecting NO crash this time)

derick

2020-04-03 12:14

administrator   ~0005370

I don't have Windows at all, so that makes testing on it hard...

bag64

2020-04-03 12:31

reporter   ~0005371

Oh. I could setup a temporary VNC for you if it could help.
Either VNC, RDP, TeamViewer or whatever would work and help you, would that be ok ?

derick

2020-04-03 14:15

administrator   ~0005372

Hey,

thanks for setting that up. I've managed to find where the problem is, and I can now reproduce this locally on Linux. I also have a fix already, but I would like to come up with a small reproducible case before I commit this.

cheers,
Derick

bag64

2020-04-03 14:27

reporter   ~0005373

Happy to hear that :-) And sorry for making you go through that VS registration pain.
I'll make sure it's up to date next time
Thank you !

derick

2020-04-04 10:01

administrator   ~0005375

This is now fixed in Git. Once AppVeyor finishes building the binaries, you can find your right configuration at https://ci.appveyor.com/project/derickr/xdebug/builds/31949378 . Click on the configuration, and then the artifacts tab. I did not manage to make a small reproducible case unfortunately.

bag64

2020-04-04 11:08

reporter   ~0005376

Great ! Problem seems to be solved, no more crashes :)