ioncube segfault php-nginx:8.1/php-nginx:8.2

[snatella]

It appears that a build or ioncube loader version update has busted ioncube file loading. Trying to run an ioncube protected file causes an immediate segfault, but a normal PHP file is fine.

application@b66b2a7ed363:~$ php /app/index.php 
Segmentation fault (core dumped)

Executing a plain PHP file is fine.

application@b66b2a7ed363:~$ php test.php 
Hello World

I've tried WHMCS v8.10.1 (whmcs_v8101_full.zip) v8.11.2 (whmcs_v8112_full.zip) v8.8.0 (whmcs_v880_full.zip) on their respective compatible images (v8.8.0 only works on 8.1) and executing any ioncube protected file (I've tried a handful of files) with php results in this trace:

#0  0x000073667f4620a0 in ?? ()
#1  0x0000590d26fc847b in ?? ()
#2  0x0000590d26fa0a13 in zend_execute ()
#3  0x0000590d26f33218 in zend_execute_scripts ()
#4  0x0000590d26ecf7a1 in php_execute_script ()
#5  0x0000590d270179d3 in ?? ()
#6  0x0000590d26c45016 in ?? ()
#7  0x000073668243024a in __libc_start_call_main (main=main@entry=0x590d26c44c60, argc=argc@entry=2, argv=argv@entry=0x7fffb9ba8248) at ../sysdeps/nptl/libc_start_call_main.h:58
#8  0x0000736682430305 in __libc_start_main_impl (main=0x590d26c44c60, argc=2, argv=0x7fffb9ba8248, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffb9ba8238) at ../csu/libc-start.c:360
#9  0x0000590d26c46351 in _start ()

Version info from 8.1 image (8.2 output is the same, minus obvious PHP version differences)

application@b66b2a7ed363:~$ php -v
PHP 8.1.30 (cli) (built: Oct 17 2024 03:58:07) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.1.30, Copyright (c) Zend Technologies
    with the ionCube PHP Loader v14.0.0, Copyright (c) 2002-2024, by ionCube Ltd.
    with Zend OPcache v8.1.30, Copyright (c), by Zend Technologies

My last pull some months back at least the 8.1 image was working fine as I had WHMCS v8.8.0 working just fine.

Any questions please shout.

[marcusball]

The ionCube loader is definitely causing issues in PHP beyond just dealing with ionCube files. I was able to narrow down a segfault I've been getting to calls to ReflectionAttribute::newInstance() on attributes which have a constructor. Somehow, disabling ionCube in this image fixed the segfaults.

Here's a script that works for me to reproduce the issue:

<?php

#[Attribute()]
class Example {
    public function __construct() {
    }
}

class Foo {
    #[Example]
    public int $bar;
}


$foo = new Foo;
$reflection = new ReflectionObject($foo);
$properties = $reflection->getProperties();
foreach ($properties as $property) {
    $attributes = $property->getAttributes();
    foreach ($attributes as $attribute) {
        $attribute->newInstance(); // Segfault here
    }
}
echo 'OK' . PHP_EOL;

The above script will segfault on the call to $attribute->newInstance(); when ionCube is enabled, but will work fine with it disabled via PHP_DISMOD=ioncube.

[jurchiks]

I've just discovered that my problem is also exactly this atttribute reflection problem, but I've never even heard of this ioncube! This is ridiculous, attributes are one of the best features in PHP 8+, and it just looks like the authors of this whole thing have never even tested anything. In fact, it looks like there is only one robot that does everything (non-clickable username).

@marcusball How did you disable ionCube ?
var_dump(ini_get('ic24.enable')); prints bool(false), so it should already be disabled.

Update: I decided that upgrading to 8.3 (where this problem doesn't exist) is going to be the better choice.