View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002292 | Xdebug | Uncategorized | public | 2024-10-04 20:33 | 2025-06-27 00:16 |
| Reporter | GaryAllan | Assigned To | |||
| Priority | normal | Severity | crash | Reproducibility | always |
| Status | resolved | Resolution | unable to reproduce | ||
| Product Version | 3.3.2 | ||||
| Summary | 0002292: Apache2 mod_php exit signal Segmentation fault (11) with Xdebug enabled | ||||
| Description | Hello, I'm a developer on the phpIPAM project and have encountered a bug using xdebug to test and develop the code. I am experiencing Segmentation faults with the Xdebug module enabled. I'm aware you would prefer a minimal php script to reproduce but the process to reproduce is complex. The code spawns a number of threads to ping the subnet, sends the data to the main process via IPC and then iterates over the results using NET/DNS2 to resolve DNS names of discovered hosts. Is there a way of obtaining additional debugging info from this Apache2 environment? | ||||
| Steps To Reproduce | Install phpIPAM on Debian 12 AMD64, Apache 2 mod_php. Install php8.3 project dependencies from deb [signed-by=/usr/share/keyrings/deb.sury.org-php.gpg] https://packages.sury.org/php/ bookworm mai Enable Xdebug Use the web application to scan a subnet. Scan will fail to complete. FireFox developer tools will report that the XHR request for subnet-scan-execute.php fails with error NS_ERROR_NET_RESET and /var/log/apache2/error.log will contain the line "child pid 101462 exit signal Segmentation fault (11)" Disabling the xdebug module results in the scan succeeding with no "exit signal Segmentation fault (11)"" errors logged. The crash is 100% reproducible. I've stepped through the code in VSCode using Xdebug. It segfaults with 100% repeatability as NET/DNS2 throws a Net_DNS2_Exception error. This is not caught by a wrapping try catch block. The code behaves as expected with Xdebug 3.3.2 disabled on this system (php 8.3.12) The code behaves as expected on another VM running PHP 7.2.24 and Xdebug 3.1.6 enabled. The code crashes under php8.3.12 with Xdebug 3.3.2 enabled. | ||||
| Additional Information | php83:/var/log/apache2# php -v root@php83:/var/log/apache2# cat error.log | grep Seg oot@php83:/var/log/apache2# dpkg -l | grep php root@php83:/var/log/apache2# cat /etc/php/8.3/apache2/conf.d/20-xdebug.ini xdebug.mode=develop,debug xdebug.start_with_request=yes The code works as expected on another VM running php7.2.24 and Xdebug 3.1.6 root@php72 ~]# php -v | ||||
| Tags | 3.3.2, php8.3 | ||||
| Operating System | Debian 12, AMD64 | ||||
| PHP Version | 8.3.10-8.3.19 | ||||
|
|
I've attached gdb output (gdb) c Program received signal SIGSEGV, Segmentation fault. (gdb) bt 15 |
|
|
Additional information attached. I've discovered that the first request after restarting Apache does not crash but all subsequent identical requests do. This lead me to look at OPcache. OPcache module enabled, xdebug module disabled = no crash I'm no longer sure if this a Xdebug, OPcache or PHP Zend Alloc issue. Valgrind trace collected with: USE_ZEND_ALLOC=1 ZEND_DONT_UNLOAD_MODULES=1 APACHE_RUN_USER=www-data APACHE_RUN_GROUP=www-data APACHE_PID_FILE=/var/run/apache2/apache2.pid APACHE_RUN_DIR=/var/run/apache2 APACHE_LOCK_DIR=/var/lock/apache2 APACHE_LOG_DIR=/var/log/apache2 valgrind --leak-check=full --show-reachable=yes --tool=memcheck --error-limit=no --log-file=val.log /usr/sbin/apache2 -DFOREGROUND |
|
|
I think the culprit in the valgrind output is:
Which I am going to guess is caused by https://github.com/php/php-src/commit/e715dd0afb1babc122efd4142c95623a12e14cfd, which should be fixed in the PHP releases going to be released on Thursday (the 17th of October). |
|
|
Issue is still present on php8.3.13 when Opcache and Xdebug modules are both enabled. root@php83:~# php -v root@php83:~# cat /var/log/apache2/error.log |
|
|
There are quite a lot of steps in the "Steps to Reproduce" section. Could you perhaps provide a Docker file that has all these steps, and hence shows this crash? |
|
|
I can still trigger this with 8.3.14 Now i know it needs opcache and xdebug to be enabled I'll work on a cut down test case. If not I'll add instructions on how to recreate with https://hub.docker.com/r/phpipam/phpipam-www root@php83:~# php -v root@php83:~# cat /var/log/apache2/error.log |
|
|
Thanks for checking in. I'll leave this as "Feedback Requested" for now. |
|
|
Did you find time to look at this? |
|
|
Could you please provide the requested feedback? |
|
|
I can't find enough information to reproduce this, and no requested information has been submitted. I'm therefore closing this out. If you can reproduce this with the latest (3.3.4) version, and can provide enough information for me to reproduce this, please open a new ticket. |