4

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!

Avi
  • 129
  • 2
  • 8
  • 2
    `SIGSEGV` is a segment violation, aka the FPM thread crashed due to an invalid memory access. This is probably a deeper going problem and not neccessarily located in your PHP script. – Honk der Hase Aug 16 '22 at 11:38

2 Answers2

3

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.

EDIT:

As of 01 Feb 2023 this issue still persists. Meanwhile some good folks at Github who experienced similar problem, not only confirmed my findings that this issue stems from the ionCube Loader, but also found a band-aid solution which might help in some cases, so I shall leave it here:

In your config/prod/doctrine.yaml (file naming/location in your app/build may vary) change the adapter value of doctrine.system_cache_pool from cache.system to cache.adapter.filesystem so it looks like this:

framework:
    cache:
        pools:
            doctrine.result_cache_pool:
                adapter: cache.app
            doctrine.system_cache_pool:
                adapter: cache.adapter.filesystem

Full discussion here: https://github.com/symfony/symfony/discussions/44270

Avi
  • 129
  • 2
  • 8
  • Hi @Avi, have you received any update from Ioncube on this? We have seen this issue on 12.0.2 as well. Thanks. – user40974 Nov 04 '22 at 17:37
  • @user40974 No. I pushed the report to their helpdesk but there was no feedback. Since we don't really need/use ionCube Loader, I kind of forgot about this issue and let it slide for the time being. If you use ionCube and suspect that you may be dealing with the same problem, you will have to poke at them more persistently by yourself. – Avi Nov 07 '22 at 03:30
  • 1
    Big Thanks @Avi for sharing this, this helped a lot, we had the same issue with a Sylius/Symfony app handled here: https://forum.sylius.com/t/503-service-unavailable-error-after-login-twice – olibur Nov 28 '22 at 09:42
  • @olibur I did some tests recently ago and it seems that this issue still persists. One thing that I wonder about now is that perhaps ionCube might be a red herring and the bug is somewhere in PHP 8.1 itself which just ionCube happens to trigger. In any case, downgrading to PHP 8.0 also seems to work, I can confirm that. – Avi Nov 29 '22 at 07:31
-1

I've just encountered this exact same issue.

PHP Version: 8.1.10 Symfony: 6.0.8 doctrine/dbal (from composer lock): 3.3.6 ionCube Loader: 12.0.1

I'm experiencing the same results. If I change it from "ASC" to "DESC" it works just fine. The issue is specifically happening when ordering by "ASC". In my case I'm using the "addOrderBy" method.

Michael
  • 103
  • 8