View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0002329XdebugStep Debuggingpublic2025-03-13 04:312025-05-02 11:52
Reporterazhrei Assigned Toderick  
PriorityhighSeverityblockReproducibilityalways
Status resolvedResolutionunable to reproduce 
PlatformApple M3 MaxOSmacOS SequoiaOS Version15.3.1
Product Version3.4.2 
Summary0002329: Xdebug causes crash with SIGSEGV
Description

I've tracked the problem down to an incompletely initialized context object passed into xdebug_dbgp_init().
lldb reports that the problem is EXC_BAD_ACCESS, but it's clearly a NULL pointer problem since the assembly language shows a register being offset by 0000010 to obtain an address, and reading that address is what causes the crash.

I specified the category as Step Debugging because that's what I'm after, but after looking at the rest of the report, you may decide it should be one of the DBGp types or even something else.

Steps To Reproduce

I enable Xdebug and the next time PHP is executed, it crashes.

Additional Information

I ran Apache in lldb and waited for xdebug to crash. When I found the instruction was "register+offset", I figured it was a structure member reference, and sure enough, the relevant line contained such a reference. I verified that it was the "program_name" field inside xdebug_con and then decided to file this bug report.

Here's the area around the crash as reported by lldb (with symbol table source information).

frame #0: 0x0000000102a193cc xdebug.so`xdebug_dbgp_init [inlined] zend_string_equals_cstr(s1=0x0000000000000000, s2=<unavailable>, s2_length=1) at zend_string.h:368:9 [opt]
365
366 static zend_always_inline bool zend_string_equals_cstr(const zend_string s1, const char s2, size_t s2_length)
367 {
-> 368 return ZSTR_LEN(s1) == s2_length && !memcmp(ZSTR_VAL(s1), s2, s2_length);
369 }
370
371 #if defined(GNUC) && (defined(i386) || (defined(__x86_64) && !defined(ILP32__)))

When I go up one stack frame, I find out where it was called from:

frame #1: 0x0000000102a193cc xdebug.so`xdebug_dbgp_init(context=0x0000000102a3da30, mode=<unavailable>) at handler_dbgp.c:2379:6 [opt]
2376 xdebug_xml_add_text(child, xdstrdup(XDEBUG_COPYRIGHT));
2377 xdebug_xml_add_child(response, child);
2378
-> 2379 if (zend_string_equals_literal(context->program_name, "-") || zend_string_equals_literal(context->program_name, "Command line code")) {
2380 xdebug_xml_add_attribute_ex(response, "fileuri", xdstrdup("dbgp://stdin"), 0, 1);
2381 } else {
2382 xdebug_xml_add_attribute_ex(response, "fileuri", xdebug_path_to_url(context->program_name), 0, 1);

In frame #1, immediately above, lldb has highlighted the first occurrence of "zend_string..." on line 2379 (it just doesn't show here).

I'm going to try adding a not-NULL check for context->program_name to see if that solves the immediate issue, but that's likely not the correct the fix — the correct fix is to determine why it's not initialized as it should be.

Tagscrash, SIGSEGV
Operating SystemmacOS
PHP Version8.3.10-8.3.19

Activities

azhrei

2025-03-13 04:39

reporter   ~0007212

As expected, adding the "context->program_name" check in the IF stmt simply pushed the error into xdebug_path_to_url() because the fileurl variable is NULL.

While I've done a lot of C programming over the years, I'm not familiar with xdebug or php internals, so I'm done for now. But if you need any additional information, don't hesitate to ask — I'm motivated to get this working!

azhrei

2025-03-14 00:32

reporter   ~0007215

Hm. Now I'm not having a problem — no crash. :( I scrolled back a few thousand lines in my terminal history (!) and found the full stack trace, since that might be useful:

(lldb) bt

  • thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x10)
    • frame #0: 0x0000000102a193cc xdebug.soxdebug_dbgp_init [inlined] zend_string_equals_cstr(s1=0x0000000000000000, s2=<unavailable>, s2_length=1) at zend_string.h:368:9 [opt] frame #1: 0x0000000102a193cc xdebug.soxdebug_dbgp_init(context=0x0000000102a3da30, mode=<unavailable>) at handler_dbgp.c:2379:6 [opt]
      frame 0000002: 0x0000000102a16fe0 xdebug.soxdebug_init_debugger at com.c:604:8 [opt] frame #3: 0x0000000102a16884 xdebug.soxdebug_debug_init_if_requested_on_error at com.c:702:3 [opt] [artificial]
      frame 0000004: 0x0000000102a1807c xdebug.soxdebug_debugger_error_cb(error_filename=0x0000000103682300, error_lineno=2, type=64, error_type_str="Fatal error", buffer="strict_types declaration must be the very first statement in the script") at debugger.c:432:2 [opt] frame #5: 0x0000000102a01f18 xdebug.soxdebug_error_cb(orig_type=64, error_filename=0x0000000103682300, error_lineno=2, message=0x0000000103682b40) at base.c:1475:3 [opt]
      frame 0000006: 0x000000010177fa94 libphp.sozend_error_zstr_at + 412 frame #7: 0x000000010177ff54 libphp.sozend_error_va_list + 68
      frame 0000008: 0x00000001017800ec libphp.sozend_error_noreturn + 68 frame #9: 0x0000000101761c74 libphp.sozend_compile_stmt + 9928
      frame 0000010: 0x000000010175d7a8 libphp.sozend_compile_top_stmt + 176 frame #11: 0x000000010175d744 libphp.sozend_compile_top_stmt + 76
      frame 0000012: 0x0000000101740b60 libphp.sozend_compile + 184 frame #13: 0x0000000101740a4c libphp.socompile_file + 60
      frame 0000014: 0x00000001015d7234 libphp.sophar_compile_file + 216 frame #15: 0x0000000103803fb4 opcache.soopcache_compile_file + 564
      frame 0000016: 0x00000001038048ec opcache.sopersistent_compile_file + 1840 frame #17: 0x0000000102a02290 xdebug.soxdebug_compile_file(file_handle=<unavailable>, type=<unavailable>) at base.c:94:13 [opt]
      frame 0000018: 0x0000000101780710 libphp.sozend_execute_scripts + 120 frame #19: 0x000000010171fd48 libphp.sophp_execute_script + 452
      frame 0000020: 0x00000001018699ec libphp.sophp_handler + 1024 frame #21: 0x0000000100006314 httpdap_run_handler + 64
      frame 0000022: 0x00000001000069d0 httpdap_invoke_handler + 272 frame #23: 0x000000010003df00 httpdap_process_async_request + 792
      frame 0000024: 0x000000010003dfb0 httpdap_process_request + 24 frame #25: 0x000000010003adbc httpdap_process_http_connection + 344
      frame 0000026: 0x000000010001785c httpdap_run_process_connection + 64 frame #27: 0x00000001002b63dc mod_mpm_prefork.sochild_main + 1092
      frame 0000028: 0x00000001002b5df4 mod_mpm_prefork.somake_child + 328 frame #29: 0x00000001002b5bc8 mod_mpm_prefork.soprefork_run + 2876
      frame 0000030: 0x0000000100019fd8 httpdap_run_mpm + 84 frame #31: 0x000000010000d4c0 httpdmain + 2260
      frame 0000032: 0x000000018aef0274 dyld`start + 2840

derick

2025-04-08 12:57

administrator   ~0007242

I have seen other rumours that looked the same, but I have never managed to be able to replicate this issue.

If you can do this reliably, can you provide more information?

derick

2025-04-24 16:33

administrator   ~0007257

Could you please provide the requested feedback?

azhrei

2025-04-25 05:31

reporter   ~0007261

I have attempted to retrieve all commits to my project around the timeframe of the original report (Mar 9th through Mar 14th) and have been unable to recreate the issue. This is running PHP 8.3.19; it's possible that I was running a slightly earlier version of PHP at the time of this report.

I do remember that it was at the very beginning of the debug session, because it would crash while processing the <?php line (or maybe the line directly below, the declare(strict_types=1) line). I struggled with making changes to that first line, checking the character encoding, and all kinds of things, only to find out it was xdebug crashing.

Since I can't replicate it, I suppose this should be closed. I will repost if/when I'm able to create it again.

derick

2025-05-02 11:52

administrator   ~0007277

OK — thanks for letting me know. And please do create a new issue if you run into this again.

Issue History

Date Modified Username Field Change
2025-03-13 04:31 azhrei New Issue
2025-03-13 04:31 azhrei Tag Attached: crash
2025-03-13 04:31 azhrei Tag Attached: SIGSEGV
2025-03-13 04:39 azhrei Note Added: 0007212
2025-03-14 00:32 azhrei Note Added: 0007215
2025-04-08 12:57 derick Assigned To => derick
2025-04-08 12:57 derick Status new => feedback
2025-04-08 12:57 derick Note Added: 0007242
2025-04-24 16:33 derick Note Added: 0007257
2025-04-25 05:31 azhrei Note Added: 0007261
2025-04-25 05:31 azhrei Status feedback => assigned
2025-05-02 11:52 derick Status assigned => resolved
2025-05-02 11:52 derick Resolution open => unable to reproduce
2025-05-02 11:52 derick Note Added: 0007277