FreeBSD 15 and PHP 8.3 CLI generates "exited on signal 11 (core dumped)"

Aknot

Aknot

We jumped from FreeBSD 13 to FreeBSD 15 last night, and everything seems to be working just fine.

Except this, when we run PHP 8.3.30 in CLI only, we always get exited on signal 11 (core dumped) - even if the script was ran successfully.
NOTE: I'm not sure if this is related to FreeBSD 15 or not (these script worked in FreeBSD 13 with PHP 8.3.30, using the same inis and confs).

This excerpt is a PHP script cron job running each minute:

Code: 
Mar 31 06:57:05 srv07 kernel: pid 23843 (php), jid 0, uid 0: exited on signal 11 (core dumped)
Mar 31 06:58:13 srv07 kernel: pid 23871 (php), jid 0, uid 0: exited on signal 11 (core dumped)
Mar 31 06:59:04 srv07 kernel: pid 23900 (php), jid 0, uid 0: exited on signal 11 (core dumped)
Mar 31 07:00:05 srv07 kernel: pid 23929 (php), jid 0, uid 0: exited on signal 11 (core dumped)
Mar 31 07:01:02 srv07 kernel: pid 24022 (php), jid 0, uid 0: exited on signal 11 (core dumped)

Apache and PHP-FPM isn't affected.

Thanks,
 
Alain De Vos said:
This is the default version on quarterly,
php --version
PHP 8.4.16 (cli) (built: Jan 26 2026 01:44:47) (NTS)

In your script can be "anything :)"
Click to expand...
Hi Alain De Vos
I need to stay on 8.3.x for compatibility reasons for a couple of months more.
The scripts aren't changed (Mostly Magento), and worked in CLI-mode on FreeBSD 13.5 with PHP 8.3.30.

I'm lost! :p
 
did you fully finish the upgrade and also upgraded all packages? (i.e. freebsd-update install, reboot, freebsd-update install, pkg upgrade -f, freebsd-update install)
please show the outputs of freebsd-version -kru and pkg info php83
 
sko said:
did you fully finish the upgrade and also upgraded all packages? (i.e. freebsd-update install, reboot, freebsd-update install, pkg upgrade -f, freebsd-update install)
please show the outputs of freebsd-version -kru and pkg info php83
Click to expand...
Hi sko ,

This is a new fresh install, not an upgrade.

# freebsd-version -kru

Code: 
15.0-RELEASE-p5
15.0-RELEASE-p5
15.0-RELEASE-p5

# pkg info php83

Code: 
php83-8.3.30
Name           : php83
Version        : 8.3.30
Installed on   : Tue Mar 31 03:30:46 2026 CEST
Origin         : lang/php83
Architecture   : FreeBSD:15:amd64
Prefix         : /usr/local
Categories     : devel lang www
Licenses       : PHP301
Maintainer     : bofh@FreeBSD.org
WWW            : https://www.php.net/
Comment        : PHP Scripting Language (8.3.X branch)
Options        :
        CGI            : on
        CLI            : on
        DEBUG          : off
        DTRACE         : on
        EMBED          : on
        FPM            : on
        IPV6           : off
        LINKTHR        : on
        MYSQLND        : on
        NOASLR         : off
        PCRE           : on
        PHPDBG         : off
        ZTS            : off
Shared Libs required:
        libargon2.so.0
        libc.so.7
        libcrypt.so.5
        libcrypto.so.35
        libelf.so.2
        libm.so.5
        libpcre2-8.so.0
        librt.so.1
        libssl.so.35
        libthr.so.3
        libutil.so.10
        libxml2.so.16
        libz.so.6
Shared Libs provided:
        libphp.so
Annotations    :
        FreeBSD_version: 1500068
        cpe            : cpe:2.3:a:php:php:8.3.30:::::freebsd15:x64
Flat size      : 25.6MiB
 
I interpreted "jumped from" as a forklift upgrade and suspected some dangling library dependencies; but in this case you should be fine.

Any chance the script is using openssl in some way and in particular something specific to 1.1.1 which is no longer available with 3.x?
Not sure if php is using OpenSSL from ports or base (there is no option for the port); but I remember seeing all kind of weird breakage with older php code after/during the transition from OpenSSL 1.1.1 to 3.0 in base.
 
sko said:
I interpreted "jumped from" as a forklift upgrade and suspected some dangling library dependencies; but in this case you should be fine.

Any chance the script is using openssl in some way and in particular something specific to 1.1.1 which is no longer available with 3.x?
Not sure if php is using OpenSSL from ports or base (there is no option for the port); but I remember seeing all kind of weird breakage with older php code after/during the transition from OpenSSL 1.1.1 to 3.0 in base.
Click to expand...
I have read that PHP 7.x had a lot of these kind of problems with SSL.

As this seems to be related to CLI only, I'm thinking there might a need to tune something in FreeBSD, maybe a kern settings? Ulimit/Open files etc?!
 
Now that you mention it: 'uid: 0' in the error messages suggests you are trying to run it as root?
I'm not sure if this will work out of the box as this is usually a very bad idea. If you *really, really* need to do that, there might be some adjustments (PATH) needed to make this work, especially from cron. But again: running php scripts as root is usually just wrong.
 
Aknot said:
We jumped from FreeBSD 13 to FreeBSD 15 last night, and everything seems to be working just fine.

Except this, when we run PHP 8.3.30 in CLI only, we always get exited on signal 11 (core dumped) - even if the script was ran successfully.
NOTE: I'm not sure if this is related to FreeBSD 15 or not (these script worked in FreeBSD 13 with PHP 8.3.30, using the same inis and confs).

This excerpt is a PHP script cron job running each minute:

Code: 
Mar 31 06:57:05 srv07 kernel: pid 23843 (php), jid 0, uid 0: exited on signal 11 (core dumped)
Mar 31 06:58:13 srv07 kernel: pid 23871 (php), jid 0, uid 0: exited on signal 11 (core dumped)
Mar 31 06:59:04 srv07 kernel: pid 23900 (php), jid 0, uid 0: exited on signal 11 (core dumped)
Mar 31 07:00:05 srv07 kernel: pid 23929 (php), jid 0, uid 0: exited on signal 11 (core dumped)
Mar 31 07:01:02 srv07 kernel: pid 24022 (php), jid 0, uid 0: exited on signal 11 (core dumped)

Apache and PHP-FPM isn't affected.

Thanks,
Click to expand...

You should try to get a backtrace from one of the core files:
Code: 
$ gdb - foo.core
> bt

(you type "bt" into the debugger)
 
cracauer@ said:
You should try to get a backtrace from one of the core files:
Code: 
$ gdb - foo.core
> bt

(you type "bt" into the debugger)
Click to expand...
Thanks for your input cracauer@

This is what I'm getting:

Code: 
Reading symbols from /usr/local/bin/php...
(No debugging symbols found in /usr/local/bin/php)
[New LWP 100537]
Core was generated by `php: /usr/local/bin/php /usr/local/www/webroot/bin/magento c'.
Program terminated with signal SIGSEGV, Segmentation fault.
Address not mapped to object.
#0  0x000000082759a8fd in ?? () from /lib/libc.so.7
(gdb) bt
#0  0x000000082759a8fd in ?? () from /lib/libc.so.7
#1  0x000000082759196d in ?? () from /lib/libc.so.7
#2  0x0000000825e24cd8 in xmlHashFree () from /usr/local/lib/libxml2.so.16
#3  0x000000085d1eae0e in xsltCleanupGlobals () from /usr/local/lib/libxslt.so.1
#4  0x000000085bac5549 in zm_shutdown_xsl () from /usr/local/lib/php/20230831/xsl.so
#5  0x00000000005ddeda in ?? ()
#6  0x00000000005eac45 in zend_hash_graceful_reverse_destroy ()
#7  0x00000000005d2b18 in ?? ()
#8  0x00000000005619d9 in php_module_shutdown ()
#9  0x00000000006c18fa in ?? ()
#10 0x000000082749f37f in __libc_start1 () from /lib/libc.so.7
#11 0x00000000003f08c4 in _start ()
(gdb)

Does this say anything?
Do I need to build PHP83 with some new options?

This is what I have right now:

83.jpg


Thanks,
 
It seems to bomb in some kind of shutdown. Is it coredumping when you are trying to quit it?

There is XML and XSLT in there but none of the options look like they would build without XML support.
 
cracauer@ said:
It seems to bomb in some kind of shutdown. Is it coredumping when you are trying to quit it?

There is XML and XSLT in there but none of the options look like they would build without XML support.
Click to expand...
Yes exactly, always at the end, when the script is done running.
So I don't need to try quit the script, it doesn't hang, it runs successfully before it segfaults.

833.jpg


Code: 
# php bin/magento cache:flush
Flushed cache types:
config
layout
block_html
collections
reflection
db_ddl
compiled_config
eav
customer_notification
config_integration
config_integration_api
graphql_query_resolver_result
full_page
config_webservice
translate
Segmentation fault <----------------------------------------------------<<<
root@srv07:/usr/local/www/ #
 
Is bin/magento a PHP script?

Can you make your own copy e.g. bin/magento_debug and put some echo commands in there until you can find the area/lines that are crashing by running your script?

Moving from FreeBSD 13.x to 15.x will have taken you from OpenSSL 1.1.1 in base to OpenSSL 3.5 so quite a leap (IF OpenSSL is where the issue is happening).

Assuming you built everything again (if you are building from ports) after the OS upgrade? Think you'd have more obvious problems than this if you had not rebuilt ports.

If building from ports, do you build against the ports OpenSSL version (which one?) or the base OpenSSL?
 
richardtoohey2 said:
Is bin/magento a PHP script?

Can you make your own copy e.g. bin/magento_debug and put some echo commands in there until you can find the area/lines that are crashing by running your script?

Moving from FreeBSD 13.x to 15.x will have taken you from OpenSSL 1.1.1 in base to OpenSSL 3.5 so quite a leap (IF OpenSSL is where the issue is happening).

Assuming you built everything again (if you are building from ports) after the OS upgrade? Think you'd have more obvious problems than this if you had not rebuilt ports.

If building from ports, do you build against the ports OpenSSL version (which one?) or the base OpenSSL?
Click to expand...

Yes, but depending on flag used, it calls other scripts.
The server is a new and fresh install, not an upgrade, and our old setup is moved over to this new one.

There are 3 main differences:

1. 15.0-RELEASE-p5 (Technology Preview) instead of FreeBSD 13.5-RELEASE.
2. ZFS instead of UFS.
3. OpenSSL 3.5.4 30 Sep 2025 (Library: OpenSSL 3.5.4 30 Sep 2025) instead of OpenSSL 1.1.1.

I have always used OpenSSL from base, no ports or packages.
 
Alain De Vos said:
Note, All your installed packages will be linked to "openssl base."
Me running no server i recompiled every package with:
Code: 
DEFAULT_VERSIONS+=ssl=openssl35
Click to expand...

This is invoking
Code: 
openssl35-3.5.5_1
install (make config) from ports.
Do you think I should reinstall PHP with OpenSSL from ports instead of using the one in base?
 
FreeBSD 15 have the following version of OpenSSL in the base:

Code: 
OpenSSL 3.5.4 30 Sep 2025 (Library: OpenSSL 3.5.4 30 Sep 2025)
 
Aknot said:
Yes, but depending on flag used, it calls other scripts.
Click to expand...
That makes it a bit more difficult.

Might have to set up a separate test system and see if you can reproduce the issue there and then starting adding debug statements until you can track down what line(s) cause the issue.

Or if it is getting to that translate stage, how much code is after that? You've said it's near the shutdown stage.

OpenSSL seems very likely because that's the biggest change here, but that's just a guess.

But as cracauer@ said, the back trace shows XML libraries in play, so maybe there is something there?

Need to find what is actually falling over.
 
I think that those look like they are also crashing under uid 80 - the www user, so not what you are seeing where the behaviour is just under the CLI.

But does give you another couple of things to try as workarounds - 14.4 or PHP 8.2 (but that's EOL 31st December 2026.).

The latter is probably easier/quicker - just at least to figure out if it is PHP 8.3 on FreeBSD 15 that is the issue.

Apache & PHP 8.4 on FreeBSD 14.4 working fine for me (both UFS and ZFS) but I've moved to binary packages. Apache & PHP 8.4 on FreeBSD 15 on ZFS also working. But I don't use OwnCloud or Magento.
 
I appreciate you help!

Yes our problem seems to be under CLI only, what we can see right now.

We should have moved away from 13.x way sooner, but we have had a couple of hectic last 3 years.
A few problems with CURL dropping support for OpenSSL below version 3, made us decide to quickly setup a new VPS instead.
We choose to move to 15.0, but we usually wait until xx.1 or xx.2 and not xx.0.

This is the reason for the big jump 🙃

I need to stay on the ports tree and make all ports, to be able to move between versions (required by Magento etc.).
I'm not sure if that's possible with binary?
 
You must log in or register to reply here.
Back
Top