View Issue Details

IDProjectCategoryView StatusLast Update
0002271XdebugUncategorizedpublic2024-07-18 13:36
Reporterjfox97 Assigned Toderick  
Status resolvedResolutionunable to reproduce 
PlatformDocker - arm64v8/ubuntuOSmacOSOS VersionVentura 13.6.7
Product Version3.3.2 
Summary0002271: Segmentation fault whenever php8.1-xdebug extension is enabled

We're getting segmentation faults from php-fpm whenever the php8.1-xdebug extension is enabled. This issue occurs consistently within our docker container built on the arm64v8/ubuntu base image. The docker engine is running on a macOS Ventura host. We get the following stack trace from the core dump:

Reading symbols from /usr/sbin/php-fpm8.1...
(No debugging symbols found in /usr/sbin/php-fpm8.1)
[New LWP 781]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/aarch64-linux-gnu/".
Core was generated by `php-fpm: pool www '.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0000ffffa84f9190 in zend_string_equal_content (s2=0x6c70736964207463, s1=0xffffa8257de0) at /usr/include/php/20210902/Zend/zend_string.h:357

warning: Source file is more recent than executable.
357 return ZSTR_LEN(s1) == ZSTR_LEN(s2) && zend_string_equal_val(s1, s2);

(gdb) bt
#0 0x0000ffffa84f9190 in zend_string_equal_content (s2=0x6c70736964207463, s1=0xffffa8257de0) at /usr/include/php/20210902/Zend/zend_string.h:357
#1 zend_string_equals (s2=0x6c70736964207463, s1=0xffffa8257de0) at /usr/include/php/20210902/Zend/zend_string.h:362
0000002 mark_fse_as_having_line_breakpoints (fse=0xaaaab8d88e70) at ./build-8.1/src/debugger/debugger.c:573
0000003 handle_breakpoints (return_value=0xffffe10e1c08, breakpoint_type=8, fse=0xaaaab8d88e70) at ./build-8.1/src/debugger/debugger.c:591
0000004 xdebug_debugger_handle_breakpoints (fse=fse@entry=0xaaaab8d88e70, breakpoint_type=breakpoint_type@entry=8, return_value=return_value@entry=0xffffe10e1c08) at ./build-8.1/src/debugger/debugger.c:623
0000005 0x0000ffffa84e1e38 in xdebug_execute_internal_end (current_execute_data=<optimized out>, return_value=0xffffe10e1c08) at ./build-8.1/src/base/base.c:1004
0000006 xdebug_execute_internal (current_execute_data=<optimized out>, return_value=0xffffe10e1c08) at ./build-8.1/src/base/base.c:1028
0000007 0x0000aaaaaeab38e8 in ?? ()
0000008 0x0000aaaaaecfaa68 in execute_ex ()

Additional Information

The issue does not occur on php 8.3 with the php8.3-xdebug extension. We have not tested on php 8.2.

I have the full core dump file, but am unable to attach it to the bug report due to its size.

TagsNo tags attached.
Operating System
PHP Version8.1.10-8.1.19



2024-06-17 23:32

administrator   ~0006979

How can I reproduce this?

Your ticket does not mention anything about this.


2024-07-10 16:04

administrator   ~0006988

Can you provide the requested feedback?


2024-07-10 21:56

reporter   ~0006992

It reproduces consistently in our environment, but we don't know specifically what about our environment is causing this for you to be able to reproduce it. The lowest level of the core dump we have symbols for is that xdebug_execute_internal method. Sorry, I know that's not helpful.

I still have the core dump I can send you if there's a way to send you files larger than 5 MB. With the right debugging symbols, that'll likely give the context needed to be able to reproduce.


2024-07-10 21:58

reporter   ~0006993

I should add, it reproduces consistently in our environment whenever xdebug is enabled, a break point is set, and we execute a specific operation in our app. We don't know what's unique about the operation that seems to be triggering this.


2024-07-18 13:36

administrator   ~0007013

I do not yet have a way on how to reproduce this problem.

There are currently several reported crash bugs where more than one person added information, but often with a different cause. This makes researching this challenging, especially because I still do not have a reproducible case.

I am going to close this ticket (and the others), and will only accept issues related to crashes when there is a full reproducible case — the exact steps on how I could potentially try to have the same issue.

Issue History

Date Modified Username Field Change
2024-06-11 21:34 jfox97 New Issue
2024-06-17 23:32 derick Assigned To => derick
2024-06-17 23:32 derick Status new => feedback
2024-06-17 23:32 derick Note Added: 0006979
2024-07-10 16:04 derick Note Added: 0006988
2024-07-10 21:56 jfox97 Note Added: 0006992
2024-07-10 21:56 jfox97 Status feedback => assigned
2024-07-10 21:58 jfox97 Note Added: 0006993
2024-07-18 13:36 derick Status assigned => resolved
2024-07-18 13:36 derick Resolution open => unable to reproduce
2024-07-18 13:36 derick Note Added: 0007013