Very strange behavior (error 503) with PHP-FPM, MariaDB and Symfony Form Doctrine Query builder-CodePudding

I apologize in advance that I can't categorize this issue any better but the behavior is puzzling to such an extent that I have no clue where the issue might originate from. Together with another dev we tried to bugfix this since several hours, but without luck. We have no idea if issue might stem from the database or PHP (clearly something goes wrong when those two try to communicate). We hope that perhaps someone had similar experiences and could at least point us into some direction.

It seems to be more of an infrastructure issue and not a code-related one, but who knows.

System: ‎CentOS 7 VPS, PHP-FPM 8.1, Symfony 6.0.11, MariaDB 10.2.38

Important: Everything works fine when Symfony is set to dev environment. Issue only present when switched to prod.

Offending code inside Symfony's FormType (other code in the Request life-cycle seems to be irrelevant, removing the code below removes the issue entirely, communication between PHP and MariaDB seems to be working fine with all other queries).

$builder
->add('type', EntityType::class, [
    'class' => Property::class,
    'choice_label' => 'name',
    'query_builder' => function (EntityRepository $er) {
        return $er->createQueryBuilder('p')
            ->orderBy('p.name', 'ASC');
    }
])

;

Browser output:
503 Service Unavailable
The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.

Server log:
AH01067: Failed to read FastCGI header
(104)Connection reset by peer: [client REDACTED-IP:53320] AH01075: Error dispatching request to :

PHP log:
WARNING: [pool admin] child 1770 exited on signal 11 (SIGSEGV) after 1.360270 seconds from start

Database log:
[Warning] Aborted connection 2787505 to db: 'REDACTED' user: 'REDACTED' host: 'localhost' (Got an error reading communication packets)

Just to be sure, we also tried:

restarting the entire VPS
hard removal of Symfony cache by rm -r var/cache
disabling OPcache (some Googling hinted to that relationship)

The part which makes me question my sanity: When I remove the entire orderBy clause from the above code, it starts to work. What is more dumbfounding, when I change orderBy('p.name', 'ASC') to orderBy('p.name', 'DESC') it starts to work as well (sic!). When I change p.name to some other valid property but still use the ASC sorting, it does not work. When in such case I change ASC to DESC it works!

CodePudding user response：

After creating some mock-up test procedures and further analysis of core dump files produced by those, we stumbled upon something like this

Program terminated with signal 11, Segmentation fault.
#0 0x00007f9a3954b0d0 in ?? () from /usr/local/lib/ioncube/ioncube_loader_lin_8.1.so

Newest version of ionCube Loader was released on 12 August: https://www.ioncube.com/loaders.php and it seems it was auto-deployed on our VPS on 14 August, which is precisely when those strange errors started to pop. So we disabled the ionCube Loader extension and all our PHP script are working fine again.

While this does not precisely pinpoint the exact line of code which makes PHP die with the segmentation fault, it at least points to the fact, that ionCube Loader 12.0.1 in conjunction with PHP 8.1 may potentially cause SIGSEGV errors. No idea what happens deeper in the code, as most of the scripts work fine and only some of them die under very strange conditions (as described by my original post). But in all those situations the hard crash is triggered by the presence of ionCube Loader 12.0.1 and its devs should be those who look deeper into the issue (I'll make sure to submit proper crash reports).

Leaving this answer here in case someone will encounter similar issues.