View Issue Details

IDProjectCategoryView StatusLast Update
0002244XdebugUncategorizedpublic2024-04-15 13:45
Reporterasifnawaz Assigned Toderick  
PrioritynormalSeveritycrashReproducibilityalways
Status resolvedResolutionwon't fix 
PlatformWSL2 and DockerOSUbuntuOS Version22.04
Product Version3.3.1 
Summary0002244: xDebug 3.3.x crashes Apache on Ubuntu 22.04 via WSL2; PHP 8.1, seeking resolution.
Description

Hello xDebug Team,

We've encountered recent issues with version 3.3.x. When enabling the PHP debug extension via the ini file, our PHP crashes (our custom hostname becomes inaccessible, though localhost remains accessible) with Apache, despite the CLI version working fine. Versions equal to or before 3.2.x function without any problems; it's only the latest xDebug version causing issues.

Though we don't have extensive logs, one of our developers encountered segfault errors when enabling the latest xDebug version.

Our development environment consists of:

Platform: Windows Subsystem for Linux (WSL2)
OS: Ubuntu 22.04
Web Server: Apache (using supervisor to run apache and mysql services)
PHP Version: 8.1
Other enabled PHP extensions on our server include:

ionCube PHP Loader v13.0.2
Zend OPcache v8.1.27
We'd appreciate any assistance you can provide in resolving this matter.

TagsNo tags attached.
Attached Files
xdebug-3.3.1.png (235,146 bytes)   
xdebug-3.3.1.png (235,146 bytes)   
works fine in xdebug-3.2.2.png (108,296 bytes)   
works fine in xdebug-3.2.2.png (108,296 bytes)   
Operating SystemUbuntu 22.04
PHP Version8.1.0-8.1.4

Activities

asifnawaz

2024-02-08 11:16

reporter   ~0006837

Hi,

I can confirm that I am also seeing segmentation fault error and I have attached the logs.

valgrind output.txt (2,842 bytes)   
==36961== Memcheck, a memory error detector
==36961== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==36961== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info
==36961== Command: php index.php
==36961== 
==36961== Invalid read of size 1
==36961==    at 0x7B6CF40: zend_string_copy (zend_string.h:194)
==36961==    by 0x7B6CF40: xdebug_debugger_set_program_name (debugger.c:104)
==36961==    by 0x7B558EB: xdebug_execute_user_code_begin (base.c:731)
==36961==    by 0x488A58: ??? (in /usr/bin/php8.1)
==36961==    by 0x460CFF: zend_execute (in /usr/bin/php8.1)
==36961==    by 0x3F0D1F: zend_execute_scripts (in /usr/bin/php8.1)
==36961==    by 0x38B9E9: php_execute_script (in /usr/bin/php8.1)
==36961==    by 0x4D9E5D: ??? (in /usr/bin/php8.1)
==36961==    by 0x230096: ??? (in /usr/bin/php8.1)
==36961==    by 0x5157D8F: (below main) (libc_start_call_main.h:58)
==36961==  Address 0x4 is not stack'd, malloc'd or (recently) free'd
==36961== 
==36961== 
==36961== Process terminating with default action of signal 11 (SIGSEGV)
==36961==  Access not within mapped region at address 0x4
==36961==    at 0x7B6CF40: zend_string_copy (zend_string.h:194)
==36961==    by 0x7B6CF40: xdebug_debugger_set_program_name (debugger.c:104)
==36961==    by 0x7B558EB: xdebug_execute_user_code_begin (base.c:731)
==36961==    by 0x488A58: ??? (in /usr/bin/php8.1)
==36961==    by 0x460CFF: zend_execute (in /usr/bin/php8.1)
==36961==    by 0x3F0D1F: zend_execute_scripts (in /usr/bin/php8.1)
==36961==    by 0x38B9E9: php_execute_script (in /usr/bin/php8.1)
==36961==    by 0x4D9E5D: ??? (in /usr/bin/php8.1)
==36961==    by 0x230096: ??? (in /usr/bin/php8.1)
==36961==    by 0x5157D8F: (below main) (libc_start_call_main.h:58)
==36961==  If you believe this happened as a result of a stack
==36961==  overflow in your program's main thread (unlikely but
==36961==  possible), you can try to increase the size of the
==36961==  main thread stack using the --main-stacksize= flag.
==36961==  The main thread stack size used in this run was 8388608.
==36961== 
==36961== HEAP SUMMARY:
==36961==     in use at exit: 4,562,583 bytes in 30,685 blocks
==36961==   total heap usage: 37,656 allocs, 6,971 frees, 6,036,168 bytes allocated
==36961== 
==36961== LEAK SUMMARY:
==36961==    definitely lost: 27,809 bytes in 867 blocks
==36961==    indirectly lost: 40 bytes in 1 blocks
==36961==      possibly lost: 2,970,746 bytes in 22,018 blocks
==36961==    still reachable: 1,563,988 bytes in 7,799 blocks
==36961==         suppressed: 0 bytes in 0 blocks
==36961== Rerun with --leak-check=full to see details of leaked memory
==36961== 
==36961== For lists of detected and suppressed errors, rerun with: -s
==36961== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
valgrind output.txt (2,842 bytes)   
xdebug dbg log.txt (2,210 bytes)   
(gdb) run
Starting program: /usr/bin/php index.php
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
xdebug_debugger_set_program_name (filename=0x0) at /tmp/pear/temp/xdebug/src/debugger/debugger.c:104
104                     XG_DBG(context).program_name = zend_string_copy(filename);
(gdb) bt full
#0  xdebug_debugger_set_program_name (filename=0x0) at /tmp/pear/temp/xdebug/src/debugger/debugger.c:104
No locals.
#1  0x00007ffff508f8ec in xdebug_execute_user_code_begin (execute_data=<optimized out>) at /tmp/pear/temp/xdebug/src/base/base.c:731
        op_array = 0x555555dd7d60
        edata = 0x0
        fse = <optimized out>
#2  0x00005555558d4a59 in ?? ()
No symbol table info available.
#3  0x00005555558acd00 in zend_execute ()
No symbol table info available.
#4  0x000055555583cd20 in zend_execute_scripts ()
--Type <RET> for more, q to quit, c to continue without paging--<RET>
No symbol table info available.
#5  0x00005555557d79ea in php_execute_script ()
No symbol table info available.
#6  0x0000555555925e5e in ?? ()
No symbol table info available.
#7  0x000055555567c097 in ?? ()
No symbol table info available.
#8  0x00007ffff74e8d90 in __libc_start_call_main (main=main@entry=0x55555567bcc0, argc=argc@entry=2, argv=argv@entry=0x7fffffffe058) at ../sysdeps/nptl/libc_start_call_main.h:58
        self = <optimized out>
        result = <optimized out>
        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {0, 4536979451957479101, 140737488347224, 93824993443008, 93824997203416, 140737354125376, -4536979453019420995, -4536962817066006851}, 
              mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x7fffffffe058, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = -8104}}}
        not_first_call = <optimized out>
#9  0x00007ffff74e8e40 in __libc_start_main_impl (main=0x55555567bcc0, argc=2, argv=0x7fffffffe058, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffe048)
    at ../csu/libc-start.c:392
No locals.
#10 0x000055555567d1f5 in _start ()
No symbol table info available.
xdebug dbg log.txt (2,210 bytes)   

derick

2024-02-08 14:28

administrator   ~0006840

Your valgrind.txt file is made through php index.php — is that right? I thought you said that it worked on the CLI?

Beyond that, I need a way to reproduce this, and your issues doesn't tell me how.

I think this could be the same issue as 0002235.

asifnawaz

2024-02-09 17:27

reporter   ~0006845

Apologies for the confusion. I had initially thought the extension was functioning properly as it was loaded on CLI. However, upon executing the index.php file, I observed errors. We are using the WHMCS software within a Docker container, and the files are encrypted with Ioncube.

derick

2024-04-15 13:45

administrator   ~0006908

Xdebug does not support being loaded at the same time as ionCube: https://xdebug.org/docs/compat#compat

Issue History

Date Modified Username Field Change
2024-02-08 09:39 asifnawaz New Issue
2024-02-08 09:39 asifnawaz File Added: xdebug-3.3.1.png
2024-02-08 09:39 asifnawaz File Added: hostname unaccessible xdebug-3.3.1.png
2024-02-08 09:39 asifnawaz File Added: works fine in xdebug-3.2.2.png
2024-02-08 11:16 asifnawaz Note Added: 0006837
2024-02-08 11:16 asifnawaz File Added: valgrind output.txt
2024-02-08 11:16 asifnawaz File Added: xdebug dbg log.txt
2024-02-08 14:28 derick Assigned To => derick
2024-02-08 14:28 derick Status new => feedback
2024-02-08 14:28 derick Note Added: 0006840
2024-02-09 17:27 asifnawaz Note Added: 0006845
2024-02-09 17:27 asifnawaz Status feedback => assigned
2024-04-15 13:45 derick Status assigned => resolved
2024-04-15 13:45 derick Resolution open => won't fix
2024-04-15 13:45 derick Note Added: 0006908