[5.7] Start to test against PHP 7.3

[carusogabriel]

No description provided.

[Kyslik]

Perhaps allowed failure?

https://docs.travis-ci.com/user/customizing-the-build/#rows-that-are-allowed-to-fail

[carusogabriel]

@Kyslik I'm not sure. The failure is coming from Guzzle when we use setup=lowest. I'll try to find what version of Guzzle fixed that issue and minimum required that here.

Edit: Proposed it to aws/aws-sdk-php#1647, as we require Guzzle there. I'll come up to this PR ASA they merge it there.

[GrahamCampbell]

Could we fix the failing test and remove php 7.3 from allow failures? Also, perhaps we should test 5.5 and 5.6 on PHP 7.3 too?

[taylorotwell]

I don't totally like allowing failures especially on recent Laravel versions as I would rather just make sure the problems are fixed.

[carusogabriel]

Could we fix the failing test and remove php 7.3 from allow failures?

(At least) Laravel 5.7 is ready for PHP 7.3 Our problem is with a dependency of a dependency: aws/aws-sdk-php#1647. As soon as that PR gets merged, I'll bump our dependency here and we can deliver this PR.

Also, perhaps we should test 5.5 and 5.6 on PHP 7.3 too?

This is up to the maintainers. Let me know what version should I target and prepare the patch :)

[taylorotwell]

I would just target 5.7. So we're still waiting on something upstream?

[carusogabriel]

I would just target 5.7

👍

So we're still waiting on something upstream?

We're just waiting for aws/aws-sdk-php#1647. As soon as that PR gets merged, I'll bump our dependency here and we can deliver this PR.

[laurencei]

Related issue: #26204

[fititnt]

Seems to be not really a bug with laravel, but if using PHP 7.0.0 stable and module Xdebug 2.7.0beta1 (it is the latest as this date) the user can experience:

• "Arr::flatten produces error "Unsupported operand types" (As listed on Arr::flatten exception in PHP 7.3.0RC3 #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

One way to mitigate this issue is temporary uninstall Xdebug instead of downgrade to PHP 7.2. On debian based distros, can try this:

sudo apt remove php-xdebug

[mfn]

"Segmentation fault (core dumped)"

For anyone who can reproduce this and wants to help upstream (xdebug?) and you're on Ubuntu, you can:

• look in /var/crash/ if you've a core dump
• install PHP with debug symbols
• unpack and run gdb with the PHP version against the core file
• get a backtrace
• report it upstream 😄

(it's a bit more involved if you've never done this, but anyone interested can google this together)

[fititnt]

Sounds fun. I'm not 100% sure about if the file at /var/crash are the most recent, so here I'm trying to generate again, so it could be a but more usefull before report to xdebug issue tracker at https://bugs.xdebug.org/my_view_page.php.

Here a step by step of what I'm trying to go a big deeper.

Laravel 5.7.19, added \Illuminate\Support\Arr::flatten([[]]); to routes/web.

PHP 7.3.0 with Xdebug 2.7.0beta1 (and now with php7.3-phpdbg, I'm not sure if this is "PHP with debug symbols")

# fititnt at bravo in ~/tmp/laravel-on-php730-with-xdebug [21:14:15]
$ cat routes/web.php 
<?php

/*
|--------------------------------------------------------------------------
| Web Routes
|--------------------------------------------------------------------------
|
| Here is where you can register web routes for your application. These
| routes are loaded by the RouteServiceProvider within a group which
| contains the "web" middleware group. Now create something great!
|
*/

Route::get('/', function () {
    \Illuminate\Support\Arr::flatten([[]]);
    return view('welcome');
});

# fititnt at bravo in ~/tmp/laravel-on-php730-with-xdebug [21:14:30]
$ php /home/fititnt/tmp/laravel-on-php730-with-xdebug/artisan serve
Laravel development server started: <http://127.0.0.1:8000>
Segmentation fault (core dumped)

# fititnt at bravo in ~/tmp/laravel-on-php730-with-xdebug [21:16:46]
$ echo "seg falult after visit the webpage"
seg falult after visit the webpage

# fititnt at bravo in ~/tmp/laravel-on-php730-with-xdebug [21:17:09]
$ gdb /usr/bin/phpdbg
GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Lendo símbolos de /usr/bin/phpdbg...(no debugging symbols found)...concluído.
(gdb) run /home/fititnt/tmp/laravel-on-php730-with-xdebug/artisan serve
Starting program: /usr/bin/phpdbg /home/fititnt/tmp/laravel-on-php730-with-xdebug/artisan serve
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Welcome to phpdbg, the interactive PHP debugger, v0.5.0]
To get help using phpdbg type "help" and press enter
[Please report bugs to <http://bugs.php.net/report.php>]
[Successful compilation of /home/fititnt/tmp/laravel-on-php730-with-xdebug/artisan]
prompt> quit
[Inferior 1 (process 13170) exited normally]
(gdb) quit

# fititnt at bravo in ~/tmp/laravel-on-php730-with-xdebug [21:18:04]
$ gdb php            
GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Lendo símbolos de php...(no debugging symbols found)...concluído.
(gdb) run /home/fititnt/tmp/laravel-on-php730-with-xdebug/artisan serve
Starting program: /usr/bin/php /home/fititnt/tmp/laravel-on-php730-with-xdebug/artisan serve
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Laravel development server started: <http://127.0.0.1:8000>
Segmentation fault (core dumped)
[Inferior 1 (process 13225) exited with code 0213]
(gdb) quit

# fititnt at bravo in ~/tmp/laravel-on-php730-with-xdebug [21:18:58]

And at /var/crash

# fititnt at bravo in /var/crash [21:19:15]
$ ls -lha
total 145M
drwxrwsrwt  2 root    whoopsie 4,0K Jan  1 14:06 .
drwxr-xr-x 20 root    root     4,0K Fev 14  2018 ..
-rwxrwxrwx  1 root    whoopsie    0 Jan  1 05:09 .lock
-rw-r-----  1 fititnt whoopsie 129M Dez 29 08:50 _usr_bin_nautilus.1000.crash
-rw-r-----  1 root    whoopsie 1,5M Dez 27 07:39 _usr_bin_php5.0.crash
-rw-r-----  1 fititnt whoopsie 6,0M Jan  1 14:06 _usr_bin_php7.3.1000.crash
-rw-r-----  1 root    whoopsie 1,9M Dez 30 05:48 _usr_sbin_apache2.0.crash
-rw-r-----  1 root    whoopsie 5,9M Jan  1 13:22 _usr_sbin_php-fpm7.3.0.crash

What I could do now?

[fititnt]

@mfn Humm, I think I will open a new issue here* just for this, as is more complicated, and someone already opened one issue on https://bugs.xdebug.org/view.php?id=1600, and seems that the devs from xdebug will need more details.

[mfn]

I'm not 100% sure about if the file at /var/crash are the most recent

Note: I'm not an expert, but from my experience: they are not. Once a crash is recorded, the file seems to have some TTL before being (discard|overwritten?).

Segmentation fault (core dumped)

At this point you should be able to get a backtrace with bt and, given you've debug symbols, should see a human readable backtrace.

[fititnt]

@mfn I opened a specific case to discuss this case. From there I think will be easier to go deeper on next days/weeks.