View Issue Details

IDProjectCategoryView StatusLast Update
0001763XdebugCode Coveragepublic2020-03-24 18:20
ReporterJeremyDunnAssigned Toderick 
PriorityhighSeveritycrashReproducibilityalways
Status closedResolutionfixed 
Product Version2.9.3 
Target VersionFixed in Version2.9.4 
Summary0001763: Crash while setting opcode overrides in ZTS mode
DescriptionI've been using xdebug for many years.

Most recently, apache 2.4.41 + PHP 7.3.13 + xdebug 2.8.0b1 (all x64 version)

today I upgraded to PHP 7.3.15 and xdebug 2.9.3. No change to apache.

Now, apache crashes on every request.

Windows event log shows:

Faulting application name: httpd.exe, version: 2.4.41.0, time stamp: 0x5d4d8786
Faulting module name: php_xdebug-2.9.3-7.3-vc15-x86_64.dll, version: 2.9.3.2, time stamp: 0x5e6bbef6
Exception code: 0xc0000005
Fault offset: 0x000000000000bf10
Faulting process id: 0x4f30
Faulting application start time: 0x01d5fae75df2302d
Faulting application path: C:\Program Files\Apache2.4.41\bin\httpd.exe
Faulting module path: C:\Program Files\php7.3.15\ext\php_xdebug-2.9.3-7.3-vc15-x86_64.dll
Report Id: 9e38dacf-66da-11ea-8295-b4b676b69bd4
Faulting package full name:
Faulting package-relative application ID:
Steps To Reproducemake any request to local website
Additional InformationPHP Version drop-down only includes 7.3.14.

I have just installed 7.3.15 (thread-safe, VC15, x64) from here:
https://windows.php.net/downloads/releases/php-7.3.15-Win32-VC15-x64.zip
TagsNo tags attached.
Operating SystemWindows 8.1 Pro
PHP Version7.3.10-7.3.14

Relationships

has duplicate 0001765 resolvedderick PHP crashes on every Apache PHP served page consistently. Outside of Apache (from the console) PHP works fine. 
has duplicate 0001767 resolvedderick xdebug-2.9.3-7.4-vc15-x86_64.dll causes Xampp Apache Server crash - recommended by Debug Wizard 

Activities

JeremyDunn

2020-03-15 16:51

reporter   ~0005298

reverting to xdebug 2.9.2 works fine.

mlocati

2020-03-17 15:51

reporter   ~0005299

Same here. I'm using Apache 2.4.37 with this configuration:

PHPIniDir "C:\Dev\PHP7.2"
LoadModule php7_module "C:\Dev\PHP7.2\php7apache2_4.dll"

I'm using PHP 7.2.28 with this configuration:
zend_extension=xdebug
xdebug.remote_enable=1

When browsing to the website (even without starting the xdebug session), I have the same Exception code (0xc0000005) in the Windows Event Viewer.

Otomatic

2020-03-18 16:56

reporter   ~0005300

I'm the developer of Wampserver since version 3 and xDebug is integrated in every version of PHP.
There is no problem with all versions of PHP from 7.1.0 to 7.4.4 with xDebug 2.9.2 in 32 or 64 bit.
By only changing the line of a php.ini:
zend_extension="E:/wamp64/bin/php/php7.4.4/zend_ext/php_xdebug-2.9.2-7.4-vc15-x86_64.dll"
by
zend_extension="E:/wamp64/bin/php/php7.4.4/zend_ext/php_xdebug-2.9.3-7.4-vc15-x86_64.dll"
without changing anything else for any version of PHP, simply starting a local site, even 'http://localhost/', will cause Apache to reboot several times in a row with the following errors in the Apache log:
AH00428: Parent: child process 8536 exited with status 3221225477 -- Restarting.

derick

2020-03-21 11:21

administrator   ~0005304

Can any of you reproduce this with the built-in PHP webserver, instead of apache? Serving your "docroot" with "php -dxdebug.remote_enable=1 -dxdebug.remote_autoconnect -S localhost:8123" and then requesting a PHP script through http://localhost:8123/scriptphp" should do the trick. It looks like this is only related to Windows, and I haven't been able to reproduce this with Linux on ZTS, and I don't have a Windows install.

jjo5555

2020-03-21 11:27

reporter   ~0005305

It is not just Windows
my 1765 is Linux

jjo5555

2020-03-21 11:28

reporter   ~0005306

If you want to email me or IM me exact instructions I can test for you.

derick

2020-03-21 11:47

administrator   ~0005307

@jjo5555 — thanks. I don't really have Apache (And it shouldn't really be needed to reproduce this), so I am looking for a way to reproduce this locally. Preferably without Apache. A docker container/setup could be helpful if you know how to make one? In any case, without having the exact steps to reproduce this locally, there is not too much I can do :-/

JeremyDunn

2020-03-21 13:21

reporter   ~0005308

xdebug 2.9.3 does NOT fail, running with the command specified in https://bugs.xdebug.org/view.php?id=1763#c5304, outside of apache

however if I leave 2.9.3 enabled in php.ini, and restart apache
apache restarts OK

but requesting any page gives the same error as originally reported:

Faulting application name: httpd.exe, version: 2.4.41.0, time stamp: 0x5d4d8786
Faulting module name: php_xdebug-2.9.3-7.3-vc15-x86_64.dll, version: 2.9.3.2, time stamp: 0x5e6bbef6
Exception code: 0xc0000005
Fault offset: 0x000000000000bf10
Faulting process id: 0x4f7c
Faulting application start time: 0x01d5ff820ead7316
Faulting application path: C:\Program Files\Apache2.4.41\bin\httpd.exe
Faulting module path: C:\Program Files\php7.3.15\ext\php_xdebug-2.9.3-7.3-vc15-x86_64.dll
Report Id: 62e3ab49-6b75-11ea-8295-b4b676b69bd4
Faulting package full name:
Faulting package-relative application ID:

I don't know if it's of any value to you (or perhaps others helping to debug) , but I've attached the Windows Error Reporting (WER) file generated when apache crashes....

Perhaps this part of the report would be helpful?
Sig[6].Name=Exception Code
Sig[6].Value=c0000005
Sig[7].Name=Exception Offset
Sig[7].Value=000000000000bf10

https://stackoverflow.com/questions/17168982/exception-error-c0000005-in-vc
c0000005 is an "access violation"

does the "Offset" value give a clue as to which line of code is faulting ?

Report.wer (17,108 bytes)

JeremyDunn

2020-03-21 13:34

reporter   ~0005309

@derick - if you have (or can create) a build of xdebug which emits a ton of debugging information (maybe line-by-line tracing?) then email it to me or send me a link where I can download - I'll run it and return output here, if that would be helpful.

alternately if there is any xdebug setting I can enable which would show debug info for xdebug itself, please tell me what is that setting and I will try it and return the results. There is nothing obvious to me on this page: https://xdebug.org/docs/all_settings

Finally, here are my xdebug settings from php.ini:
[xdebug]
xdebug.default_enable=1
xdebug.remote_enable=1
xdebug.remote_autostart=0
xdebug.remote_connect_back=0
xdebug.remote_host=localhost
xdebug.remote_port=9000
xdebug.remote_handler=dbgp
xdebug.idekey=netbeans-xdebug
xdebug.remote_mode=req
xdebug.overload_var_dump=1
xdebug.extended_info=1
xdebug.coverage_enable=0
xdebug.collect_includes=0
xdebug.profiler_enable=0
xdebug.profiler_append=0
xdebug.profiler_enable_trigger=0
xdebug.profiler_output_dir="C:\temp\xdebug"
xdebug.profiler_output_name=cachegrind.out

Otomatic

2020-03-21 15:51

reporter   ~0005310

@derick - If I can be of any use, it will be with pleasure, of course provided you tell me what to set up and do.

derick

2020-03-21 16:40

administrator   ~0005311

I've just spend some time getting Centos with apache, php 7.3 and Xdebug going, and for me it starts fine.

@JeremyDunn I can't really change Xdebug to have that information line by line. It's also not going to be helpful as there is likely some memory corruption that that will not show in the right place.
@jjo5555 and @Otomatic — I need a way to produce this *myself* with debugging tools available. If you can reproduce this in a virtual machine, or if you can set-it up somewhere where I can SSH in and be root, that would be very useful.

If I can't reproduce it myself, I can't fix it. So please provide a set-up where this is already broken, or the exact steps for me to run in a clean (Linux) OS install to reproduce this issue. Assume I know nothing about your set-up. If you want, feel free to drop by in Freenode/#xdebug on IRC (https://webchat.freenode.net/#xdebug).

JeremyDunn

2020-03-21 16:51

reporter   ~0005312

@derick - thank you very much for your attention to this matter.

From everything that has been written, it seems to affect *only* Windows; so how would it help to "run in a clean (Linux) OS install" ??

I might be able to setup a *Windows* environment in which this problem can be reproduced, and give you root access (e.g. a small AWS instance). Would this be useful ??

jjo5555

2020-03-21 19:48

reporter   ~0005313

@JeremyDunn - no see my report 1765. This is Centos/Linux

jjo5555

2020-03-21 19:52

reporter   ~0005314

@derick

> I've just spend some time getting Centos with apache, php 7.3 and Xdebug going, and for me it starts fine.

It starts fine but does it server PHP pages?

> I need a way to produce this *myself* with debugging tools available. If you can reproduce this in a virtual machine,
> or if you can set-it up somewhere where I can SSH in and be root, that would be very useful.

Happy to let you SSH into my production box. Ideally from a fixed IP I can let through the firewall and for a set time period because I will have to upgrade again and thus break a production box.

derick

2020-03-21 20:15

administrator   ~0005316

@jjo5555

> > I've just spend some time getting Centos with apache, php 7.3 and Xdebug going, and for me it starts fine.
>
> It starts fine but does it server PHP pages?

Yes, no problem at all.

> Happy to let you SSH into my production box. Ideally from a fixed IP I can let through the firewall and for a set time period because I will have to upgrade again and thus break a production box.

That sounds a bit scary, especially because you shouldn't really run Xdebug in production :-) And, would I be able to poke around and start/stop things at leisure?

jjo5555

2020-03-21 20:26

reporter   ~0005317

> That sounds a bit scary, especially because you shouldn't really run Xdebug in production :-)

Not really sure why I am. I figured it is running as it is part of my PHP/PECL set-up and was required. I have not consciously turned it on.
If it shouldn't be running maybe I need to turn it off.

> And, would I be able to poke around and start/stop things at leisure?

Yes in a set time window as long as you are able to revert things back after.

jjo5555

2020-03-21 21:35

reporter   ~0005318

OK so I commented out the line:
zend_extension=xdebug.so
in /etc/php-zts.d/15-xdebug.ini
and upgraded to xdebug 2.9.3
and of course, after a httpd restart everything works, because xdebug is disabled.
But at least is is there ready to be enabled for testing.

By the way this may be relevant: I am using PHP ZTS (Zend Thread Safety) module and pthreads

derick

2020-03-22 11:12

administrator   ~0005319

Thanks for that hint @jjo5555 ­— It definitely needs ZTS, but not pthreads. I can now reproduce this and get the following valgrind error:

==3590== Use of uninitialised value of size 8
==3590==    at 0x1541C100: xdebug_set_in_ex (set.c:70)
==3590==    by 0x1541BD02: xdebug_call_original_opcode_handler_if_set (lib.c:258)
==3590==    by 0x12CC80F8: ??? (in /usr/lib64/httpd/modules/libphp7-zts.so)
==3590==    by 0x12CCB31F: execute_ex (in /usr/lib64/httpd/modules/libphp7-zts.so)
==3590==    by 0x1541285E: xdebug_execute_ex (base.c:380)
==3590==    by 0x12CD2D42: zend_execute (in /usr/lib64/httpd/modules/libphp7-zts.so)
==3590==    by 0x12C39AA1: zend_execute_scripts (in /usr/lib64/httpd/modules/libphp7-zts.so)
==3590==    by 0x12BC9BDD: php_execute_script (in /usr/lib64/httpd/modules/libphp7-zts.so)
==3590==    by 0x12CD5621: ??? (in /usr/lib64/httpd/modules/libphp7-zts.so)
==3590==    by 0x149AEF: ap_run_handler (in /usr/sbin/httpd)
==3590==    by 0x14A038: ap_invoke_handler (in /usr/sbin/httpd)
==3590==    by 0x15EC49: ap_process_async_request (in /usr/sbin/httpd)
==3590== 
==3590== Invalid read of size 8
==3590==    at 0x1541C100: xdebug_set_in_ex (set.c:70)
==3590==    by 0x1541BD02: xdebug_call_original_opcode_handler_if_set (lib.c:258)
==3590==    by 0x12CC80F8: ??? (in /usr/lib64/httpd/modules/libphp7-zts.so)
==3590==    by 0x12CCB31F: execute_ex (in /usr/lib64/httpd/modules/libphp7-zts.so)
==3590==    by 0x1541285E: xdebug_execute_ex (base.c:380)
==3590==    by 0x12CD2D42: zend_execute (in /usr/lib64/httpd/modules/libphp7-zts.so)
==3590==    by 0x12C39AA1: zend_execute_scripts (in /usr/lib64/httpd/modules/libphp7-zts.so)
==3590==    by 0x12BC9BDD: php_execute_script (in /usr/lib64/httpd/modules/libphp7-zts.so)
==3590==    by 0x12CD5621: ??? (in /usr/lib64/httpd/modules/libphp7-zts.so)
==3590==    by 0x149AEF: ap_run_handler (in /usr/sbin/httpd)
==3590==    by 0x14A038: ap_invoke_handler (in /usr/sbin/httpd)
==3590==    by 0x15EC49: ap_process_async_request (in /usr/sbin/httpd)
==3590==  Address 0x8 is not stack'd, malloc'd or (recently) free'd

xeuron

2020-03-22 12:45

reporter   ~0005320

Same story here. Debugged (heh) for days. Problem was with xdebug version 2.9.3 (TS x64). Reproduced with PHP 7.2/3/4 on both laragon and xampp; xdebug that came with xampp worked as it was xdebug v2.8.1 and that helped me pin point the problem.
Problem : When browsing through apache, it wouldn't stop "loading" for at least a few minutes.
Solution: downgrade xdebug version to at most 2.9.2.
Extra note: However, it works PERFECTLY fine using the CLI to run the same website. Module shows up as loaded in php -m.

derick

2020-03-22 18:24

administrator   ~0005321

I have a potential fix.

Can you all please test the following:

@JeremyDunn: Download https://ci.appveyor.com/api/buildjobs/5naxtrg30ij5d1od/artifacts/php_xdebug-c9c23258-7.3-vc15-x86_64.zip to replace C:\Program Files\php7.3.15\ext\php_xdebug-2.9.3-7.3-vc15-x86_64.dll
@Otomatic: Download https://ci.appveyor.com/api/buildjobs/n1iwi5emjjrs1r4v/artifacts/php_xdebug-c9c23258-7.4-vc15-x86_64.zip, and use the contents to replace E:/wamp64/bin/php/php7.4.4/zend_ext/php_xdebug-2.9.3-7.4-vc15-x86_64.dll
@jj0555: git clone https://github.com/derickr/xdebug.git, cd into the "xdebug" directory, switch to the right branch with "git checkout issue1763-crash", and compile and install xdebug (https://xdebug.org/docs/install#compile for extra information)

Windows binaries for other PHP versions are also being built. Select the right option from https://ci.appveyor.com/project/derickr/xdebug/builds/31637026, and then click on the Artifacts tab to find other .zip files.

JeremyDunn

2020-03-22 19:46

reporter   ~0005323

> @JeremyDunn: Download https://ci.appveyor.com/api/buildjobs/5naxtrg30ij5d1od/artifacts/php_xdebug-c9c23258-7.3-vc15-x86_64.zip
> to replace C:\Program Files\php7.3.15\ext\php_xdebug-2.9.3-7.3-vc15-x86_64.dll

that FIXED the problem:
 * apache starts and handles requests w/o error
 * I can set a breakpoint and launch my IDE (NetBeans) in debug mode; and it stops on that breakpoint
 * all other normal xdebug functions within the IDE (stepping, variable-inspection, etc.) work as expected

Thanks!

jjo5555

2020-03-22 19:55

reporter   ~0005324

> @jj0555: git clone https://github.com/derickr/xdebug.git, cd into the "xdebug" directory
...
> and compile and install xdebug

Sorry @derick I'm not set up with a compiler on that box.
I will wait for the next Centos Yum version and report back then. But it sounds like you have done it.

Otomatic

2020-03-23 08:05

reporter   ~0005329

> @Otomatic: Download https://ci.appveyor.com/api/buildjobs/n1iwi5emjjrs1r4v/artifacts/php_xdebug-c9c23258-7.4-vc15-x86_64.zip
> and use the contents to replace E:/wamp64/bin/php/php7.4.4/zend_ext/php_xdebug-2.9.3-7.4-vc15-x86_64.dll
That solved the problem.
- Apache does not restart when a local site launches.
- I conducted the tests at six local sites...
- I've created intentional PHP errors on the various local sites and it works fine.

Thanks

derick

2020-03-23 11:17

administrator   ~0005331

Thanks for testing. I'll go and release 2.9.4 now with that fix.

mlocati

2020-03-23 15:07

reporter   ~0005335

Any reason why the Windows DLLs for 2.9.4 are not available on the PECL website? See https://windows.php.net/downloads/pecl/releases/xdebug and https://pecl.php.net/package/xdebug/2.9.4/windows

jjo5555

2020-03-24 18:20

reporter   ~0005344

Just to confirm that 2.9.4 fixes this bug for my on the Centos environment too.

Issue History

Date Modified Username Field Change
2020-03-15 16:47 JeremyDunn New Issue
2020-03-15 16:51 JeremyDunn Note Added: 0005298
2020-03-17 15:51 mlocati Note Added: 0005299
2020-03-18 16:56 Otomatic Note Added: 0005300
2020-03-18 20:49 derick Relationship added has duplicate 0001765
2020-03-21 11:09 derick Relationship added has duplicate 0001767
2020-03-21 11:21 derick Assigned To => derick
2020-03-21 11:21 derick Status new => feedback
2020-03-21 11:21 derick Note Added: 0005304
2020-03-21 11:27 jjo5555 Note Added: 0005305
2020-03-21 11:28 jjo5555 Note Added: 0005306
2020-03-21 11:47 derick Note Added: 0005307
2020-03-21 13:21 JeremyDunn File Added: Report.wer
2020-03-21 13:21 JeremyDunn Note Added: 0005308
2020-03-21 13:21 JeremyDunn Status feedback => assigned
2020-03-21 13:34 JeremyDunn Note Added: 0005309
2020-03-21 15:51 Otomatic Note Added: 0005310
2020-03-21 16:40 derick Note Added: 0005311
2020-03-21 16:51 JeremyDunn Note Added: 0005312
2020-03-21 19:48 jjo5555 Note Added: 0005313
2020-03-21 19:52 jjo5555 Note Added: 0005314
2020-03-21 20:15 derick Note Added: 0005316
2020-03-21 20:26 jjo5555 Note Added: 0005317
2020-03-21 21:35 jjo5555 Note Added: 0005318
2020-03-22 11:12 derick Status assigned => confirmed
2020-03-22 11:12 derick Note Added: 0005319
2020-03-22 12:45 xeuron Note Added: 0005320
2020-03-22 18:03 derick Summary apache 2.4.41 crashes with PHP 7.3.15 and xdebug 2.9.3 => Crash while setting opcode overrides in ZTS mode
2020-03-22 18:24 derick Status confirmed => feedback
2020-03-22 18:24 derick Note Added: 0005321
2020-03-22 19:46 JeremyDunn Note Added: 0005323
2020-03-22 19:46 JeremyDunn Status feedback => assigned
2020-03-22 19:55 jjo5555 Note Added: 0005324
2020-03-23 08:05 Otomatic Note Added: 0005329
2020-03-23 11:17 derick Status assigned => closed
2020-03-23 11:17 derick Resolution open => fixed
2020-03-23 11:17 derick Fixed in Version => 2.9.4
2020-03-23 11:17 derick Note Added: 0005331
2020-03-23 11:17 derick Category Installation => Code Coverage
2020-03-23 15:07 mlocati Note Added: 0005335
2020-03-24 18:20 jjo5555 Note Added: 0005344