Hi,

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

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.

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.

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

Hi,
Error is still persisting the Versions equal to or before 3.2.x function without any problems; it's only the latest xDebug version causing issues.

Xdebug is still not compatible with ionCube.

If there is a new incompatibility, please reach out to the ionCube support team. As they are a paid-for-proprietary project without source code available, I can do nothing on my side to investigate. If they find a problem, I am more than happy to look at a patch if they want to provide it.

Hi there,

First of all, thank you derick for this awesome tool!

I've the same issue of asifnawaz with a similar stack:

• xDebug 3.5.1
• PHP 8.3/8.4
• ionCube Loader 15.5.0

I'm using a docker image: php:8.3-fpm-bookworm and php:8.4-fpm-bookworm.

Instead with php:8.1-fpm I've no issue.

I've this stack httpd:alpine (with proxy pass) => php-fpm

I’m attaching a Codex analysis of this segmentation fault, in case it’s of interest to anyone. I’ll also try to contact ionCube support and reference this case.

Native backtrace

Captured with gdb on PHP 8.3:

Program received signal SIGSEGV, Segmentation fault.
xdebug_add_stack_frame (zdata=zdata@entry=0xffff7ba13b80, op_array=op_array@entry=0xffff7bb0fa00, type=type@entry=1) at /tmp/pear/temp/xdebug/src/base/base.c:694
#0 xdebug_add_stack_frame (...) at /tmp/pear/temp/xdebug/src/base/base.c:694
#1 0x0000ffff7b9986e0 in xdebug_execute_user_code_begin (...) at /tmp/pear/temp/xdebug/src/base/base.c:757
0000002 0x0000ffff7b998f38 in xdebug_execute_begin (...) at /tmp/pear/temp/xdebug/src/base/base.c:1036
0000003 0x0000aaaac2a315a4 in ?? ()
0000004 0x0000aaaac29c8448 in ?? ()
0000005 0x0000aaaac29f80fc in execute_ex ()
0000006 0x0000aaaac264e83c in ?? ()
0000007 0x0000aaaac2a037cc in execute_ex ()
0000008 0x0000aaaac264e83c in ?? ()
0000009 0x0000aaaac2a037cc in execute_ex ()
0000010 0x0000ffff7b6e47f4 in ?? () from /usr/local/lib/php/extensions/no-debug-non-zts-20230831/ioncube_loader_lin_8.3.so
0000011 0x0000ffff7ba01050 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

A second run showed:

#0 zend_string_copy (s=0x0) at /usr/local/include/php/Zend/zend_string.h:216
#1 xdebug_add_stack_frame (...) at /tmp/pear/temp/xdebug/src/base/base.c:694

So Xdebug appears to dereference a null string while building the stack frame.

Additional observations

I understand ionCube may be modifying execution metadata in unsupported ways, but from Xdebug’s side this results in a hard segfault inside xdebug_add_stack_frame().

Response from ionCube Support:

Hi,

Thanks for creating a ticket.

This incompatibility is already known and there is no workaround for it.

The only way around this would be for the ionCube Loader to disable the internal Observer API (which Xdebug uses) which would mean that Xdebug would effectively be uninstalled.

Apart from that we would have to completely re-engineer our encoding format since the problem stems from the byte code of encoded functions being in a different format from the "standard" byte code of functions in PHP after compilation.

Kind regards,

--
ionCube Support