You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Typical memory exhaustion errors are causing PHP to segfault, instead of fatal errorring. This kills the worker (and any shared memory it may be storing) and causes un-traceable user errors, significantly complicating debugging.
I also believe that this is the root cause of the problems with load-scripts.php we were seeing which we attributed to the JIT - they are actually out-of-memory issues which then become segfaults due to this bug as well as WordPress/gutenberg#54294
I've traced this down specifically to our use of Excimer, likely in X-Ray.
Minimal reproduction:
Run local server the usual way
Save the following into a PHP file in content/mu-plugins/:
<?php
function foo() {
foo();
}
foo();
View the site in the browser and observe it crashes with a 502 from nginx
Observe composer server logs php contains a segfault
Note, if you save the same file to the root and load it directly, it fatals with the memory exhaustion
To check Excimer:
Use docker exec -it -u root {id} /bin/bash to set up a root shell
apt-get install procps vim - installs ps and vim
vim /usr/local/etc/php/conf.d/docker-php-ext-excimer.ini - comment (#) the line which loads Excimer and save it
ps aux - get the PID of PHP
kill -s USR2 {pid} - reload php-fpm configuration
View the site in the browser and observe it fatal errors, but from PHP rather than nginx
Observe composer server logs php contains the (correct) memory exhaustion error
Acceptance criteria:
...
The text was updated successfully, but these errors were encountered:
@joehoyle If you have the PHP debug symbols handy, can you gdb this to see if you can find the segfault? Assuming you also have the build tools handy for Excimer - I don't have either handy.
Typical memory exhaustion errors are causing PHP to segfault, instead of fatal errorring. This kills the worker (and any shared memory it may be storing) and causes un-traceable user errors, significantly complicating debugging.
I also believe that this is the root cause of the problems with
load-scripts.php
we were seeing which we attributed to the JIT - they are actually out-of-memory issues which then become segfaults due to this bug as well as WordPress/gutenberg#54294I've traced this down specifically to our use of Excimer, likely in X-Ray.
Minimal reproduction:
content/mu-plugins/
:composer server logs php
contains a segfaultNote, if you save the same file to the root and load it directly, it fatals with the memory exhaustion
To check Excimer:
docker exec -it -u root {id} /bin/bash
to set up a root shellapt-get install procps vim
- installsps
andvim
vim /usr/local/etc/php/conf.d/docker-php-ext-excimer.ini
- comment (#
) the line which loads Excimer and save itps aux
- get the PID of PHPkill -s USR2 {pid}
- reload php-fpm configurationcomposer server logs php
contains the (correct) memory exhaustion errorAcceptance criteria:
The text was updated successfully, but these errors were encountered: