Framework: Laravel on PHP 7.3.0 with xdebug + OPCache enabled: Segmentation fault (core dumped) / "Unsupported operand types"

[fititnt]

_Who debugs the debugger?_ Help need at xdebug bug tracker

TL;DR: Laravel works with PHP 7.3. This is a more specific scenario with xdebug enabled, and this need help to understand the issue. Also people who know a bit more about GDB to help me and others.

---

• Laravel Version: 5.7.19 (possible older versions too)
• PHP Version: PHP 7.3.0 stable with Xdebug 2.7.0beta1 and OPCache not disabled
• Database Driver & Version: (non relevant)

Description:

In short, we could consider this not as a bug from laravel framework, but attention is need to at have sufficient people here give relevant feedback for xdebug. Someone already started one issue at https://bugs.xdebug.org/view.php?id=1600, link that I discovered after trying do generate more useful debug info here https://github.com/laravel/framework/pull/26125#issuecomment-450765213.

So, in short: some extra help will need to

1. Extract some more usefull information to allow xdebug module release as soon as possible one bugfix (note: releases with fixes of xdebug, a PHP module written in C, are not as fast as Laravel, so it could take like 4 months or more; )
2. Maybe document this issue with PHP 7.3, as more and more people will get this issue, and xdebug is relatively common on testing enviroments

See also Related PRs and issues:

• https://github.com/laravel/framework/issues/26204
• https://github.com/laravel/framework/pull/26125

Steps To Reproduce:

• PHP version must be 7.3.0 and (this is very important) have module xdebug enabled.
• Install a new laravel instance (or use a existent one)
• Add \Illuminate\Support\Arr::flatten([[]]);
• Run Laravel via Apache or NGinx; or via php artisan serve

Tip: See this comment: https://github.com/laravel/framework/issues/26204#issuecomment-448084765 or this one https://github.com/laravel/framework/pull/26125#issuecomment-450765213.

Tip: if using https://github.com/laravel/telescope, the AJAX funcions that reload the data can also stop to work

Syntoms

• "Arr::flatten produces error "Unsupported operand types" (As listed on #26204)
• On NGinx, error logs show "recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 127.0.0.1,..."
  "Segmentation fault (core dumped)" if use php artisan serve
• Not tested, but very likely "white screen of death" (no useful messages on screen)

Temporary workarounds

Use one of the workarounds to make it work at this moment:

• Disable php-xdebug on PHP 7.3.0 *
• Disable OPCache (opcache.enable=0 on php.ini, then restart PHP services) *
• Set opcache.optimization_level=0x7FFFBBFF (thanks, @vintagesucks, via https://github.com/laravel/framework/issues/27030#issuecomment-455033884)
• _Question: did someone know what we could hot patch Arr::flatten to make it work without push this chance to the laravel framework?_

_[*]: one temporary strategy here could be choose use xdebug on your local development but OPCache disabled but, on production, mantain the OPCache enabled and just do not install xdebug enabled (protip: xdebug slow down performance, so it's a good thing not be enabled on production)_

Solution

• Update to PHP 7.3.1+ (no need to use xdebug master or chance default PHP configs!)

---

Edit 1:

• Added OPCache with default configurations (e.g it is enabled by default) is required to trigger this issue and "disable OPCache" as extra temporary workaround (thanks, @ethali, to report this!)

Edit 2:

• Renamed issue from "Laravel on PHP 7.3..." to "Laravel on PHP 7.3.0..." to make it explicit the exact version
• Added @vintagesucks workaround
• "Update to PHP 7.3.1+" as solution

[driesvints]

As Taylor explained on the other issue, since this randomly breaks on a new minor PHP version this probably isn't a framework bug. We'll have to wait until a new PHP 7.3 patch release or a fix in xdebug itself.

Please only use this issue tracker to report bugs with the framework itself.

[fititnt]

Look, this is the feedback of the one of core devs from xdebug to someone else trying to report to xdebug itself:

(was is response to vmorozov, not me, but could be anyone here trying to report the issue)

Can this issue be open at least a few days or untill more people at least open a report there with useful information, since we are talking about the most used PHP module for debug be able to be used with any version of Laravel?

As relevant reference: at least Laravel Telescope ("_elegant debug assistant for the Laravel framework_") also does not work and does not show error messages on the screen (it break the AJAX loading with the combo PHP 7.3.0 stable + php-xdebug.)

But I'm ok with this issue closed and wait for the lastest stable version of PHP/xdebug solve this issue possibly without be aware. Too much effort to dig deeper alone here.

[driesvints]

@fititnt I think at this point with all the PHP 7.3 problems we're facing it's best to wait for at least the first patch release.

[mfn]

Look, this is the feedback of the one of core devs from xdebug to someone else trying to report to xdebug itself:

The "easiest" would be somehow testing this on Linux then, I guess. Could also be a simple VM on OSX.

[ethali]

Hi and have a good year everyone!

Just in case... I can make XDebug work with PHP 7.3 (php-fpm in docker) without having this issue nor #26204 one. To do so I have to disable opcache.

[fititnt]

Wow, thanks, @ethali to report that! I just made an update to the issue to make it clear.

I tested on a Ubuntu 16 LTS and I can confirm that is possible to maintain PHP 7.3.0 stable with Xdebug 2.7.0beta1 if the Opcache is disabled.

To disable OPCache (using as reference Ubuntu 16.04, or other distros that use the ppa:ondrej/php)

Edit /etc/php/7.3/fpm/php.ini and add at the end opcache.enable=0 and then restart sudo systemctl restart php7.3-fpm

Or, if running with php artisan serve, the file is /etc/php/7.3/cli/php.ini, and then start the php artisan serve again

[GrahamCampbell]

The master version of xdebug DOES work with opcache on and php 7.3.

[GrahamCampbell]

Versions you will need are:

PHP 7.3.1RC1 or later + xdebug master (23rd December or later).

[GrahamCampbell]

I've documented the required versions at https://github.com/laravel/framework/issues/27052.

[fititnt]

So I'm going to make a constructive criticism here, both because of this issue I opened (and very shortly was closed) and also because of #26204.

Laravel runs on a language called PHP. Laravel needs PHP. In special on new releases of PHP, at least for Release Candidate versions, is expected that users report issues to PHP developers, so even if who report do not know C, we would be contributing to great stable versions.

With this baseline in mind, the obvious implication is that topics related to problems in PHP can not be treated as if PHP is just another compose package: if the next version of PHP will not work, Laravel will not work. So, obviously, I agree this is not a (laravel) framework bug (as Taylor said https://github.com/laravel/framework/issues/26204#issuecomment-449121068 and Dries replied to me), but does it means that issues should be closed before at least report back to PHP issues tracker?

So, my strong suggestion here is that, at least for issues that could break laravel on next versions of PHP, even if are minor versions, at least give some time for users confirm or get more data from others users to potentially allow PHP devs fix compatibility issues before they happen. And I believe that suggestion is quite reasonable and a win-win.

A practical example of why this approach could be better: this issue was started as suggestion by Markus https://github.com/laravel/framework/pull/26125#issuecomment-450755326 and because the issue who already discovered on 2018-09-21, PHP 7.3.0RC3, #26204, still exist before the PHP 7.3.0 stable, but very likely was not reported. If on that moment, since was about a next release of PHP, people where encouraged to test more and nudged to even report back to PHP devs, the fix PHP 7.3.0 stable could already work nice with Laravel. Other user recently reported on xdebug, but was missing more details, and this issue started because I would willing to try help on that, but I would need a bit of feedback than continue discuting on a closed PR. I'll try not be blunt here: but as it is now, it might discourage people from take their time to solve problems before they occur, and in general who is testing on next versions tend to already be willing to go way deeper to improve the full ecosystem. Close issues too soon (in this case, was not even about a RC version, was for a stable version of PHP) is something that could be improved.

[vintagesucks]

Just in case... I can make XDebug work with PHP 7.3 (php-fpm in docker) without having this issue nor #26204 one. To do so I have to disable opcache.

Another workaround without disabling OPcache completely or updating Xdebug to master branch is to set opcache.optimization_level=0x7FFFBBFF.

[PadawanTony]

On February 1, Xdebug 2.7.0rc1 was released. This release supposedly fixes the bug.

@vintagesucks how can we update XDebug to master branch?

[crishoj]

For me, the rc2 release of Xdebug (Xdebug 2.7.0rc2) seems to have fixed the issue.

[driesvints]

Going to lock this one as well like the other issues. Please use https://github.com/laravel/framework/issues/27052 as a reference.