php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #77465 Segfault with PHP built-in server
Submitted: 2019-01-16 05:59 UTC Modified: 2019-02-21 16:12 UTC
Votes:1
Avg. Score:3.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:0 (0.0%)
Same OS:0 (0.0%)
From: girgias@php.net Assigned: nikic (profile)
Status: Closed Package: Built-in web server
PHP Version: 7.3.1 OS: WSL with Ubuntu 18.04
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: girgias@php.net
New email:
PHP Version: OS:

 

 [2019-01-16 05:59 UTC] girgias@php.net 
Description:
------------
It seems like PHP's built-in web server segfaults immediately when trying to access any web page.

This issue seems to present from PHP 7.3.0 

This may be related to Bug #77430

Tried to produce a gdb backtrace but didn't manage so I can try to produce one again with some instructions.

I don't think that any extensions have an impact on this but can always provide the extension list.

Actual result:
--------------
php -S localhost:8000 -t public/ -d display_errors=1
PHP 7.3.1-1+ubuntu18.04.1+deb.sury.org+1 Development Server started at Wed Jan 16 06:50:35 2019
Listening on http://localhost:8000
Document root is /mnt/c/Dev/Sites/personal/public
Press Ctrl-C to quit.
Segmentation fault (core dumped)

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2019-01-16 06:09 UTC] girgias@php.net 
Also seems like this issue on Zend framework is related to this.
https://github.com/zendframework/zend-diactoros/issues/343

And for a gdb backtrace seems like it's impossible with WSL (c.f. https://github.com/Microsoft/WSL/issues/1262 ).
 [2019-01-16 08:07 UTC] nikic@php.net 
When you say "any web page" is that really *any* (e.g. an empty php file)?

Is it possible to get a backtrace by directly running under gdb? (gdb --args php -S localhost:8000 -t public/ -d display_errors=1 and then "r")
 [2019-01-16 10:25 UTC] girgias@php.net 
I just run the command by running it directly under gdb and got this output:

gdb --args php -S localhost:8000 -t public/ -d display_errors=1
GNU gdb (Ubuntu 8.1-0ubuntu3) 8.1.0.20180409-git
Copyright (C) 2018 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"...
Reading symbols from php...(no debugging symbols found)...done.
(gdb) r
Starting program: /usr/bin/php -S localhost:8000 -t public/ -d display_errors=1
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
PHP 7.3.1-1+ubuntu18.04.1+deb.sury.org+1 Development Server started at Wed Jan 16 11:22:50 2019
Listening on http://localhost:8000
Document root is /mnt/c/Dev/Sites/personal/public
Press Ctrl-C to quit.

Program received signal SIGSEGV, Segmentation fault.
0x000000000831c508 in ?? ()



I will try if this applies even to an empty PHP file.
 [2019-01-16 11:01 UTC] girgias@php.net 
So it does not crash on *any* file, an empty file and a simple echo "Hello World"; work just fine.

Will dig deeper and see if it's related to the fact that I'm using http-interop Http\Response\send function with a PSR-7 object instead of a simple echo to display output.
 [2019-01-16 11:23 UTC] girgias@php.net 
Okay, I think I have narrowed down from where the problem comes.

Or it comes from Guzzle ("guzzlehttp/psr7": "^1.5")
Or it comes from first instantiating an object.

gdb backtrace for the following code example:
<?php

require '../vendor/autoload.php';

$response = new GuzzleHttp\Psr7\Response(200, [], 'Hello World');


gdb output:
gdb --args php -S localhost:8000 -t public/ -d display_errors=1
GNU gdb (Ubuntu 8.1-0ubuntu3) 8.1.0.20180409-git
Copyright (C) 2018 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"...
Reading symbols from php...(no debugging symbols found)...done.
(gdb) r
Starting program: /usr/bin/php -S localhost:8000 -t public/ -d display_errors=1
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
PHP 7.3.1-1+ubuntu18.04.1+deb.sury.org+1 Development Server started at Wed Jan 16 12:19:29 2019
Listening on http://localhost:8000
Document root is /mnt/c/Dev/Sites/test-bug/public
Press Ctrl-C to quit.
[Wed Jan 16 12:19:30 2019] 127.0.0.1:56899 [200]: /
[Wed Jan 16 12:19:30 2019] 127.0.0.1:56900 [404]: /favicon.ico - No such file or directory

Program received signal SIGPIPE, Broken pipe.
0x00007ffffd2f2c4d in __libc_send (fd=5, buf=0x8a1aaf8, len=55, flags=0) at ../sysdeps/unix/sysv/linux/send.c:28
28      ../sysdeps/unix/sysv/linux/send.c: No such file or directory.



I will try to figure out if it's only related to Guzzle or if it's a general problem.
 [2019-01-16 11:30 UTC] girgias@php.net 
So this is not related to Guzzle, it segfault during an instantiation of an object.

This example code:
<?php

$object = new stdClass();


Will output the following gdb trace:

gdb --args php -S localhost:8000 -t public/ -d display_errors=1
GNU gdb (Ubuntu 8.1-0ubuntu3) 8.1.0.20180409-git
Copyright (C) 2018 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"...
Reading symbols from php...(no debugging symbols found)...done.
(gdb) r
Starting program: /usr/bin/php -S localhost:8000 -t public/ -d display_errors=1
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
PHP 7.3.1-1+ubuntu18.04.1+deb.sury.org+1 Development Server started at Wed Jan 16 12:29:10 2019
Listening on http://localhost:8000
Document root is /mnt/c/Dev/Sites/test-bug/public
Press Ctrl-C to quit.
[Wed Jan 16 12:29:15 2019] 127.0.0.1:57012 [200]: /
[Wed Jan 16 12:29:16 2019] 127.0.0.1:57013 [404]: /favicon.ico - No such file or directory

Program received signal SIGPIPE, Broken pipe.
0x00007ffffd2f2c4d in __libc_send (fd=5, buf=0x8ace8f8, len=55, flags=0) at ../sysdeps/unix/sysv/linux/send.c:28
28      ../sysdeps/unix/sysv/linux/send.c: No such file or directory.
(gdb)
 [2019-01-16 13:07 UTC] cmb@php.net 
I see memory leaks, but no segfault (current master; debug build):

[Wed Jan 16 14:00:14 2019] 127.0.0.1:64505 Accepted
[Wed Jan 16 14:00:14 2019] 127.0.0.1:64506 Accepted
[Wed Jan 16 14:00:14 2019] 127.0.0.1:64505 [200]: /77465.php
[Wed Jan 16 14:00:14 2019]  Script:  '/mnt/c/Users/cmb/php-dev/77465.php'
/mnt/c/Users/cmb/php-dev/php-src/Zend/zend_string.h(132) :  Freeing 0x00007fd2b20640c0 (32 bytes), script=/mnt/c/Users/cmb/php-dev/77465.php
[Wed Jan 16 14:00:14 2019]  Script:  '/mnt/c/Users/cmb/php-dev/77465.php'
/mnt/c/Users/cmb/php-dev/php-src/ext/date/php_date.c(945) :  Freeing 0x00007fd2b2065240 (56 bytes), script=/mnt/c/Users/cmb/php-dev/77465.php
[Wed Jan 16 14:00:14 2019]  Script:  '/mnt/c/Users/cmb/php-dev/77465.php'
/mnt/c/Users/cmb/php-dev/php-src/Zend/zend_hash.c(144) :  Freeing 0x00007fd2b2069480 (320 bytes), script=/mnt/c/Users/cmb/php-dev/77465.php
[Wed Jan 16 14:00:14 2019]  Script:  '/mnt/c/Users/cmb/php-dev/77465.php'
/mnt/c/Users/cmb/php-dev/php-src/ext/date/lib/parse_tz.c(244) :  Freeing 0x00007fd2b206c000 (4 bytes), script=/mnt/c/Users/cmb/php-dev/77465.php
[Wed Jan 16 14:00:14 2019]  Script:  '/mnt/c/Users/cmb/php-dev/77465.php'
/mnt/c/Users/cmb/php-dev/php-src/ext/date/lib/parse_tz.c(488) :  Freeing 0x00007fd2b206c028 (4 bytes), script=/mnt/c/Users/cmb/php-dev/77465.php
[Wed Jan 16 14:00:14 2019]  Script:  '/mnt/c/Users/cmb/php-dev/77465.php'
/mnt/c/Users/cmb/php-dev/php-src/ext/date/lib/parse_tz.c(354) :  Freeing 0x00007fd2b206c050 (1 bytes), script=/mnt/c/Users/cmb/php-dev/77465.php
[Wed Jan 16 14:00:14 2019]  Script:  '/mnt/c/Users/cmb/php-dev/77465.php'
/mnt/c/Users/cmb/php-dev/php-src/ext/date/lib/parse_tz.c(228) :  Freeing 0x00007fd2b206e000 (20 bytes), script=/mnt/c/Users/cmb/php-dev/77465.php
[Wed Jan 16 14:00:14 2019]  Script:  '/mnt/c/Users/cmb/php-dev/77465.php'
/mnt/c/Users/cmb/php-dev/php-src/ext/date/lib/parse_tz.c(487) :  Freeing 0x00007fd2b2074000 (160 bytes), script=/mnt/c/Users/cmb/php-dev/77465.php
/mnt/c/Users/cmb/php-dev/php-src/Zend/zend_alloc.c(2605) : Actual location (location was relayed)
=== Total 8 memory leaks detected ===
[Wed Jan 16 14:00:14 2019] 127.0.0.1:64505 Closing
[Wed Jan 16 14:00:14 2019] 127.0.0.1:64508 Accepted
[Wed Jan 16 14:00:15 2019] 127.0.0.1:64508 Closed without sending a request; it was probably just an unused speculative preconnection
[Wed Jan 16 14:00:15 2019] 127.0.0.1:64508 Closing
[Wed Jan 16 14:00:15 2019] 127.0.0.1:64506 Closed without sending a request; it was probably just an unused speculative preconnection
[Wed Jan 16 14:00:15 2019] 127.0.0.1:64506 Closing
 [2019-01-16 13:29 UTC] girgias@php.net 
Just checked again and seems like my test script only works after it segfaults once. (Which I find confusing but whatever).

Will try to dig up the original issue once again.

However, the original segfault error I got is still:
Program received signal SIGSEGV, Segmentation fault.
0x00000000080eb66f in ?? ()

But not sure that provides any help because the error message is less than ideal.
 [2019-01-16 13:33 UTC] nikic@php.net 
After you see the SIGSEGV, can you please run "bt" in gdb to show the rest of the backtrace?
 [2019-01-16 13:45 UTC] girgias@php.net 
Run the bt command after the SIGSEGV and got this output:

Starting program: /usr/bin/php -S localhost:8000 -t public/ -d display_errors=1
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
PHP 7.3.1-1+ubuntu18.04.1+deb.sury.org+1 Development Server started at Wed Jan 16 14:43:38 2019
Listening on http://localhost:8000
Document root is /mnt/c/Dev/Sites/personal/public
Press Ctrl-C to quit.

Program received signal SIGSEGV, Segmentation fault.
0x00000000080eb66f in ?? ()
(gdb) bt
#0  0x00000000080eb66f in ?? ()
#1  0x000000000831fc68 in execute_ex ()
#2  0x00007ffffa12f335 in xdebug_execute_ex (execute_data=0x7ffffa61f240) at ./build-7.3/xdebug.c:1868
#3  0x00000000080e7db3 in ?? ()
#4  0x000000000831fc68 in execute_ex ()
#5  0x00007ffffa12f335 in xdebug_execute_ex (execute_data=0x7ffffa61f1f0) at ./build-7.3/xdebug.c:1868
#6  0x00000000080e7db3 in ?? ()
#7  0x000000000831fc68 in execute_ex ()
#8  0x00007ffffa12f335 in xdebug_execute_ex (execute_data=0x7ffffa61f0f0) at ./build-7.3/xdebug.c:1868
#9  0x00000000080e7db3 in ?? ()
#10 0x000000000831fc68 in execute_ex ()
#11 0x00007ffffa12f335 in xdebug_execute_ex (execute_data=0x7ffffa61f030) at ./build-7.3/xdebug.c:1868
#12 0x0000000008326393 in zend_execute ()
#13 0x0000000008297a52 in zend_execute_scripts ()
#14 0x0000000008237d60 in php_execute_script ()
#15 0x000000000832ece2 in ?? ()
#16 0x000000000832fc04 in ?? ()
#17 0x000000000833015c in ?? ()
#18 0x0000000008330cce in ?? ()
#19 0x00000000080f0752 in ?? ()
#20 0x00007ffffd1f1b97 in __libc_start_main (main=0x80f0420, argc=7, argv=0x7ffffffee3b8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffffffee3a8) at ../csu/libc-start.c:310
#21 0x00000000080f09da in _start ()
(gdb)

Hope this helps
 [2019-01-16 14:33 UTC] nikic@php.net 
Just to exclude the obvious, could you check whether disabling (i.e. removing the extension from php.ini) xdebug helps? XDebug has some known issues with PHP 7.3, so it would be good to exclude it as a possible cause.
 [2019-01-16 15:23 UTC] girgias@php.net 
Seems like disabling xDebug allowed me to at least start the server and get one page to respond

New output (yes the root of the website has a 301 redirection loop which I need to fix):

(gdb) r
Starting program: /usr/bin/php -S localhost:8000 -t public/ -d display_errors=1
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
PHP 7.3.1-1+ubuntu18.04.1+deb.sury.org+1 Development Server started at Wed Jan 16 16:20:31 2019
Listening on http://localhost:8000
Document root is /mnt/c/Dev/Sites/personal/public
Press Ctrl-C to quit.
[Wed Jan 16 16:20:38 2019] 127.0.0.1:58286 [301]: /
[Wed Jan 16 16:20:38 2019] 127.0.0.1:58287 [301]: /
[Wed Jan 16 16:20:38 2019] 127.0.0.1:58288 [301]: /
[Wed Jan 16 16:20:38 2019] 127.0.0.1:58289 [301]: /
[Wed Jan 16 16:20:38 2019] 127.0.0.1:58290 [301]: /
[Wed Jan 16 16:20:38 2019] 127.0.0.1:58291 [301]: /
[Wed Jan 16 16:20:38 2019] 127.0.0.1:58292 [301]: /
[Wed Jan 16 16:20:38 2019] 127.0.0.1:58293 [301]: /
[Wed Jan 16 16:20:38 2019] 127.0.0.1:58294 [301]: /
[Wed Jan 16 16:20:38 2019] 127.0.0.1:58295 [301]: /
[Wed Jan 16 16:20:38 2019] 127.0.0.1:58296 [301]: /
[Wed Jan 16 16:20:38 2019] 127.0.0.1:58297 [301]: /
[Wed Jan 16 16:20:38 2019] 127.0.0.1:58298 [301]: /
[Wed Jan 16 16:20:38 2019] 127.0.0.1:58299 [301]: /
[Wed Jan 16 16:20:38 2019] 127.0.0.1:58300 [301]: /
[Wed Jan 16 16:20:38 2019] 127.0.0.1:58301 [301]: /
[Wed Jan 16 16:20:38 2019] 127.0.0.1:58302 [301]: /
[Wed Jan 16 16:20:39 2019] 127.0.0.1:58303 [301]: /
[Wed Jan 16 16:20:39 2019] 127.0.0.1:58304 [301]: /
[Wed Jan 16 16:20:39 2019] 127.0.0.1:58305 [301]: /
[Wed Jan 16 16:20:39 2019] 127.0.0.1:58306 [301]: /
[Wed Jan 16 16:20:52 2019] 127.0.0.1:58307 [200]: /blog
[Wed Jan 16 16:20:52 2019] 127.0.0.1:58308 [404]: /favicon.ico - No such file or directory

Program received signal SIGPIPE, Broken pipe.
0x00007ffffd2f2c4d in __libc_send (fd=5, buf=0x83919f0, len=13, flags=0) at ../sysdeps/unix/sysv/linux/send.c:28
28      ../sysdeps/unix/sysv/linux/send.c: No such file or directory.
(gdb) bt
#0  0x00007ffffd2f2c4d in __libc_send (fd=5, buf=0x83919f0, len=13, flags=0) at ../sysdeps/unix/sysv/linux/send.c:28
#1  0x000000000832df17 in ?? ()
#2  0x000000000832ff2f in ?? ()
#3  0x0000000008330d48 in ?? ()
#4  0x00000000080f0752 in ?? ()
#5  0x00007ffffd1f1b97 in __libc_start_main (main=0x80f0420, argc=7, argv=0x7ffffffee3b8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffffffee3a8) at ../csu/libc-start.c:310
#6  0x00000000080f09da in _start ()
(gdb)
 [2019-01-16 15:36 UTC] nikic@php.net 
The SIGPIPE you're seeing is likely harmless and only shows up because you're running under gdb. You can skip it using "c" (maybe multiple times) or instruct gdb to not stop on it ("handle SIGPIPE nostop"). Or try running without gdb and see if it runs through clearly.

It seems to me that xdebug is the culprit though. Quite a few people are hitting bug #77287.
 [2019-01-16 15:43 UTC] girgias@php.net 
Yeah, works just fine without xDebug,

Is there a PR or thread somewhere where I can attach this bug report?
I suppose the xDebug creators are aware of the issue.

Oh and thanks for your time.
 [2019-02-21 16:12 UTC] nikic@php.net
-Status: Open +Status: Closed -Assigned To: +Assigned To: nikic
 [2019-02-21 16:12 UTC] nikic@php.net 
Closing this, as the xdebug issue in bug #77287 has been resolved in the meantime.
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Tue Dec 02 18:00:01 2025 UTC