Segmentation fault under high loads in openssl_encrypt in ZTS build (FrankenPHP)

Description

Code using openssl_encrpyt() causes segmentation faults under high loads with static ZTS builds of PHP.
For instance, this part of Laravel triggers the bug: https://github.com/laravel/framework/blob/10.x/src/Illuminate/Encryption/Encrypter.php#L102-L105

Here is a backtrace gathered with GDB:

Backtrace

#1  0x0000783330654ec3 in __libc_free (p=0x7832da600cb0) at src/malloc/mallocng/free.c:105
#2  0x000078332fef89f0 in EVP_CIPHER_CTX_reset ()
#3  0x000078332f15bf83 in php_openssl_encrypt (data=0x7832d67946a8 "cdcfc94a44f1372ecc088f6e0abca9d4c1416db0|XFaOVGRiKdwkZpamJ3fb2fXpv4vvguazIfVNxK8R", data_len=81, method=0x7832d7995220 "aes-256-cbc", method_len=11,
    password=0x7832d67acd88 "\036\216/a\363-\257e\332Wu㖂&\033%\341\307\036O\243hOX(\257\204\346j\334\t", password_len=32, options=0, iv=0x7832d6686558 "\\\226\024Y\204:#b\276+1b\332\034%\225", iv_len=16, tag=0x7832d7818a40, tag_len=16,
    aad=0x783330d21ef5 "", aad_len=0) at /go/src/app/dist/static-php-cli/source/php-src/ext/openssl/openssl.c:7700
#4  0x000078332f15c126 in zif_openssl_encrypt (execute_data=0x7832d78189a0, return_value=0x7832d7818970) at /go/src/app/dist/static-php-cli/source/php-src/ext/openssl/openssl.c:7719
#5  0x000078332ef7351f in ZEND_DO_ICALL_SPEC_RETVAL_USED_HANDLER () at /go/src/app/dist/static-php-cli/source/php-src/Zend/zend_vm_execute.h:1337
#6  execute_ex (ex=0x7832d78171d0) at /go/src/app/dist/static-php-cli/source/php-src/Zend/zend_vm_execute.h:57216
#7  0x000078332edcfec2 in zend_call_function (fci=0x7832dafe9720, fci_cache=0x7832dafe96f0) at /go/src/app/dist/static-php-cli/source/php-src/Zend/zend_execute_API.c:957
#8  0x000078332eca9591 in zif_frankenphp_handle_request (execute_data=<optimized out>, return_value=0x7832d7817140) at frankenphp.c:371
#9  0x000078332ef7351f in ZEND_DO_ICALL_SPEC_RETVAL_USED_HANDLER () at /go/src/app/dist/static-php-cli/source/php-src/Zend/zend_vm_execute.h:1337
#10 execute_ex (ex=0x7832d7817020) at /go/src/app/dist/static-php-cli/source/php-src/Zend/zend_vm_execute.h:57216
#11 0x000078332ef908a7 in zend_execute (op_array=0x7832d7866000, return_value=0x0) at /go/src/app/dist/static-php-cli/source/php-src/Zend/zend_vm_execute.h:61604
#12 0x000078332edfca5c in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /go/src/app/dist/static-php-cli/source/php-src/Zend/zend.c:1881
#13 0x000078332ed3d05a in php_execute_script (primary_file=0x7832dafef660) at /go/src/app/dist/static-php-cli/source/php-src/main/main.c:2523
#14 0x000078332ecaa4f1 in frankenphp_execute_script (file_name=0x7832d946ab00 "4b48bc1af71891ab467ffde5c30d1b724928ab8c9dee168d597ce7f9e1dc9498") at frankenphp.c:825
#15 0x000078332eca7c37 in _cgo_d49d0ae4a108_Cfunc_frankenphp_execute_script (v=0xc000810dd8) at /tmp/go-build/cgo-gcc-prolog:55
#16 0x000078332d966a01 in runtime.asmcgocall () at /usr/local/go/src/runtime/asm_amd64.s:918
#17 0x000000c0008016c0 in ?? ()
#18 0x00007832dafef7d0 in ?? ()
#19 0x00007832dafef834 in ?? ()
#20 0x0000000000000000 in ?? ()

Several Laravel users have confirmed the issue at https://github.com/laravel/octane/issues/791.
A reproducer is available in the linked PR.

Using a static build of FrankenPHP with debug symbols like the one available here https://github.com/dunglas/frankenphp/actions/runs/8206010369?pr=635 (frankenphp-linux-x86_64-debug) always triggers the error on Linux/amd64. I'm not able to reproduce on Apple Silicon (both on macOS and Linux).

PHP Version

PHP 8.3.3

Operating System

Ubuntu 22.04.4 LTS

@crazywhalecc

Some extra information: FrankenPHP static builds are created using @crazywhalecc's static-php-cli, which uses Musl under the hood.

does it build it statically with OpenSSL as well or is that linked as shared lib? What OpenSSL version is used?

I've done a bit of digging, I still don't know exactly what the underlying problem is, but here are my guesses so far:

EVP_CIPHER_CTX_reset() (

php-src/ext/openssl/openssl.c

Line 7736 in 8595bea

EVP_CIPHER_CTX_reset(cipher_ctx);

) is called even if EVP_CipherInit_ex() (

php-src/ext/openssl/openssl.c

Line 7553 in 8595bea

if (!EVP_CipherInit_ex(cipher_ctx, cipher_type, NULL, NULL, NULL, enc)) {

and

php-src/ext/openssl/openssl.c

Line 7596 in 8595bea

    
           if (!EVP_CipherInit_ex(cipher_ctx, NULL, NULL, key, (unsigned char *)*piv, enc)) {

) is called because we don't verify (

php-src/ext/openssl/openssl.c

Line 7686 in 8595bea

if (php_openssl_cipher_init(cipher_type, cipher_ctx, &mode,

) whether initialization is going well before calling EVP_CIPHER_CTX_reset().

Under heavy loads (this crash is only triggered during load tests), EVP_CipherInit_ex() probably fails for one reason or another.
In the documentation, it is not clear whether it is safe to call EVP_CIPHER_CTX_reset() if EVP_CipherInit_ex() has not been called. It seems that the crash only occurs when using Musl's mallocng allocator, which may do some extra safety checks compared to glibc (not sure about that).

Another unrelated thing: EVP_CipherInit_ex() is called two times in php_openssl_cipher_init(), shouldn't it be reset before being initialized again?

Take all of this with a grain of salt as I know nothing about OpenSSL and this code is a bit complicated.

@bukka

@bukka OpenSSL is compiled statically as well, the latest version if used.

Calling EVP_CipherInit_ex twice is necessary to set some things (like AEAD tag and key length) so this should be fine. There might be something unusual in combination latest OpenSSL with musl but need to debug it to see.

It might be irrelevant but how the toolchain has been built might count here too, see topic here.

@devnexen

@devnexen This build uses the default options for static-php-cli: https://github.com/dunglas/frankenphp/blob/main/build-static.sh#L140
And -static-pie for the final FrankenPHP binary: https://github.com/dunglas/frankenphp/blob/main/build-static.sh#L140C107-L140C118

So I have been looking through this properly. It took me longest to actually create the build with OpenSSL debug symbols and recreate the issue. It was recreatable only on my old Intel laptop (couldn't re-create on my more powerful AMD desktop).

The backtrace with all symbols looked like this

Thread 19 "thpool-8" received signal SIGSEGV, Segmentation fault.
[Switching to LWP 168570]
get_meta (p=p@entry=0x7f203ce8f090 "AES-256-CBC") at src/malloc/mallocng/meta.h:141
warning: 141	src/malloc/mallocng/meta.h: No such file or directory
(gdb) bt
#0  get_meta (p=p@entry=0x7f203ce8f090 "AES-256-CBC") at src/malloc/mallocng/meta.h:141
#1  0x00007f2092254ec3 in __libc_free (p=0x7f203ce8f090) at src/malloc/mallocng/free.c:105
#2  0x00007f2091af89f0 in evp_cipher_free_int (cipher=0x7f203c606e90) at crypto/evp/evp_enc.c:1735
#3  EVP_CIPHER_free (cipher=0x7f203c606e90) at crypto/evp/evp_enc.c:1751
#4  EVP_CIPHER_free (cipher=0x7f203c606e90) at crypto/evp/evp_enc.c:1741
#5  EVP_CIPHER_CTX_reset (ctx=0x7f20393cc490) at crypto/evp/evp_enc.c:47
#6  0x00007f2090d5bf83 in php_openssl_encrypt (data=0x7f203bf907f8 "b90b13db1fcbdb90be7d0ae7e8cf83e0abb9f1ef|GLFbFz2uJlMVG7bXsR8XmPocdfEzNK5qtUtL8lYu", data_len=81, method=0x7f203c485e78 "aes-256-cbc", method_len=11, 
    password=0x7f203bf76bf8 "d\216\345\241\301\227\355\354\327\301 \363\367\020\035s\301nZ4A\304\017\030T\312\372c%\221\256I", password_len=32, options=0, iv=0x7f203befb888 "\374ތM`\273\031K\370\366\360\005\213\306\022\266", iv_len=16, 
    tag=0x7f203c418a40, tag_len=16, aad=0x7f2092921e55 "", aad_len=0) at /go/src/app/dist/static-php-cli/source/php-src/ext/openssl/openssl.c:7700
#7  0x00007f2090d5c126 in zif_openssl_encrypt (execute_data=0x7f203c4189a0, return_value=0x7f203c418970) at /go/src/app/dist/static-php-cli/source/php-src/ext/openssl/openssl.c:7719
#8  0x00007f2090b7351f in ZEND_DO_ICALL_SPEC_RETVAL_USED_HANDLER () at /go/src/app/dist/static-php-cli/source/php-src/Zend/zend_vm_execute.h:1337
#9  execute_ex (ex=0x7f203c4171d0) at /go/src/app/dist/static-php-cli/source/php-src/Zend/zend_vm_execute.h:57216
#10 0x00007f20909cfec2 in zend_call_function (fci=0x7f203d064720, fci_cache=0x7f203d0646f0) at /go/src/app/dist/static-php-cli/source/php-src/Zend/zend_execute_API.c:957
#11 0x00007f20908a9591 in zif_frankenphp_handle_request (execute_data=<optimized out>, return_value=0x7f203c417140) at frankenphp.c:371
#12 0x00007f2090b7351f in ZEND_DO_ICALL_SPEC_RETVAL_USED_HANDLER () at /go/src/app/dist/static-php-cli/source/php-src/Zend/zend_vm_execute.h:1337
#13 execute_ex (ex=0x7f203c417020) at /go/src/app/dist/static-php-cli/source/php-src/Zend/zend_vm_execute.h:57216
#14 0x00007f2090b908a7 in zend_execute (op_array=0x7f203c466000, return_value=0x0) at /go/src/app/dist/static-php-cli/source/php-src/Zend/zend_vm_execute.h:61604
#15 0x00007f20909fca5c in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /go/src/app/dist/static-php-cli/source/php-src/Zend/zend.c:1881
#16 0x00007f209093d05a in php_execute_script (primary_file=0x7f203d06a660) at /go/src/app/dist/static-php-cli/source/php-src/main/main.c:2523
#17 0x00007f20908aa4f1 in frankenphp_execute_script (file_name=0x7f203ce0f0e0 "\b\221f= \177") at frankenphp.c:825
#18 0x00007f20908a7c37 in _cgo_d49d0ae4a108_Cfunc_frankenphp_execute_script (v=0xc000656dd8) at /tmp/go-build/cgo-gcc-prolog:55
#19 0x00007f208f566a01 in runtime.asmcgocall () at /usr/local/go/src/runtime/asm_amd64.s:918
#20 0x000000c000133340 in ?? ()
#21 0x00007f203d06a7d0 in ?? ()
#22 0x00007f203d06a834 in ?? ()
#23 0x0000000000000000 in ?? ()

It says that it is failing on de-allocation fetched cipher type_name here: https://github.com/openssl/openssl/blob/openssl-3.2.1/crypto/evp/evp_enc.c#L1735

The cipher context is however reset after freeing which can be seen here: https://github.com/openssl/openssl/blob/openssl-3.2.1/crypto/evp/evp_enc.c#L46-L48 so there doesn't seem any way to keep the freed context cipher around. I have been also checking if there is a way to maybe just partially initialize the context in evp_cipher_init_internal but can't see anything. If this was possible somehow, then it would be OpenSSL bug as it would prevent deallocation of the context.

The actual cipher type is set here: https://github.com/openssl/openssl/blob/openssl-3.2.1/crypto/evp/evp_enc.c#L1589 . The
ossl_algorithm_get1_first_name uses OPENSSL_strndup which uses malloc to allocate the type. There does not seem anything unusual.

The PHP code does not seem to have any issue either except the unnecessary EVP_CIPHER_CTX_reset in https://github.com/php/php-src/blob/php-8.3.3/ext/openssl/openssl.c#L7700-L7701 . Removing that won't change much though as internally EVP_CIPHER_CTX_free calls EVP_CIPHER_CTX_reset so the crash would still be there. We need to free the context as soon as it is created using EVP_CIPHER_CTX_new so there is no way around that. So any issue keeping that inconsistent would be an OpenSSL issue.

Another possibility is a problem in allocator. I would suggest to try to replace allocator as using MUSL one is not ideal anyway for highly multi-threaded application. It might be worth to put some effort into using jemalloc or simillar and see if it fixes the issue.

I created a build of FrankenPHP that uses https://github.com/microsoft/mimalloc instead of mallogng (php/frankenphp#666), and there is a similar problem (but not exactly the same).
This works, but under high load there are segmentation faults. Here is the stack trace:

Thread 31 "thpool-16" received signal SIGSEGV, Segmentation fault.
[Switching to LWP 2482670]
0x00007a4c8a95cc05 in ossl_provider_ctx (prov=0xdfdfdfdfdfdfdfdf) at crypto/provider_core.c:1328
1328	crypto/provider_core.c: Aucun fichier ou dossier de ce nom.
(gdb) bt
#0  0x00007a4c8a95cc05 in ossl_provider_ctx (prov=0xdfdfdfdfdfdfdfdf) at crypto/provider_core.c:1328
#1  0x00007a4c8a922a80 in evp_cipher_init_internal (ctx=0x200281a0fc0, cipher=<optimized out>, impl=<optimized out>, key=0x0, iv=0x0, enc=<optimized out>, params=0x0) at crypto/evp/evp_enc.c:220
#2  0x00007a4c8a922edb in EVP_CipherInit_ex (ctx=<optimized out>, cipher=<optimized out>, impl=<optimized out>, key=<optimized out>, iv=<optimized out>, enc=<optimized out>) at crypto/evp/evp_enc.c:462
#3  0x00007a4c89b81a3b in php_openssl_cipher_init (cipher_type=0x7a4c8e437f60 <aesni_256_cbc>, cipher_ctx=0x200281a0fc0, mode=0x7a4c35d4e7b0, ppassword=0x7a4c35d4e668, ppassword_len=0x7a4c35d4e660, 
    free_password=0x7a4c35d4e691, piv=0x7a4c35d4e658, piv_len=0x7a4c35d4e7f0, free_iv=0x7a4c35d4e690, tag=0x0, tag_len=16, options=0, enc=1)
    at /go/src/app/dist/static-php-cli/source/php-src/ext/openssl/openssl.c:7517
#4  0x00007a4c89b8221c in php_openssl_encrypt (data=0x7a4c31b95788 "a959b3426b7b0ced0bc8776263204d2494516209|hW8US9Lqt29NRnEGUTKfclqOykHIrMOioAMGHTuh", data_len=81, method=0x7a4c32767ec8 "aes-256-cbc", 
    method_len=11, password=0x7a4c31bada18 "\036\216/a\363-\257e\332Wu㖂&\033%\341\307\036O\243hOX(\257\204\346j\334\t", password_len=32, options=0, 
    iv=0x7a4c326671f8 "\352\350ơ}\301$时w=n>\265", <incomplete sequence \311>, iv_len=16, tag=0x7a4c32618a40, tag_len=16, aad=0x7a4c8b76a4d5 "", aad_len=0)
    at /go/src/app/dist/static-php-cli/source/php-src/ext/openssl/openssl.c:7650
#5  0x00007a4c89b82ca4 in zif_openssl_encrypt (execute_data=0x7a4c326189a0, return_value=0x7a4c32618970) at /go/src/app/dist/static-php-cli/source/php-src/ext/openssl/openssl.c:7719
#6  0x00007a4c8999a09d in ZEND_DO_ICALL_SPEC_RETVAL_USED_HANDLER () at /go/src/app/dist/static-php-cli/source/php-src/Zend/zend_vm_execute.h:1337
#7  execute_ex (ex=0x7a4c326171d0) at /go/src/app/dist/static-php-cli/source/php-src/Zend/zend_vm_execute.h:57216
#8  0x00007a4c897f694f in zend_call_function (fci=0x7a4c35d52710, fci_cache=0x7a4c35d526e0) at /go/src/app/dist/static-php-cli/source/php-src/Zend/zend_execute_API.c:957
#9  0x00007a4c896d0021 in zif_frankenphp_handle_request (execute_data=<optimized out>, return_value=0x7a4c32617140) at frankenphp.c:372
#10 0x00007a4c8999a09d in ZEND_DO_ICALL_SPEC_RETVAL_USED_HANDLER () at /go/src/app/dist/static-php-cli/source/php-src/Zend/zend_vm_execute.h:1337
#11 execute_ex (ex=0x7a4c32617020) at /go/src/app/dist/static-php-cli/source/php-src/Zend/zend_vm_execute.h:57216
#12 0x00007a4c899b7425 in zend_execute (op_array=0x7a4c32666000, return_value=0x0) at /go/src/app/dist/static-php-cli/source/php-src/Zend/zend_vm_execute.h:61604
#13 0x00007a4c898234ca in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /go/src/app/dist/static-php-cli/source/php-src/Zend/zend.c:1883
#14 0x00007a4c89763b4a in php_execute_script (primary_file=0x7a4c35d58650) at /go/src/app/dist/static-php-cli/source/php-src/main/main.c:2523
#15 0x00007a4c896d0fe1 in frankenphp_execute_script (file_name=0x0) at frankenphp.c:851
#16 0x00007a4c896ce637 in _cgo_feab5cfeb5bc_Cfunc_frankenphp_execute_script (v=0xc000805dd8) at /tmp/go-build/cgo-gcc-prolog:55
#17 0x00007a4c88375a01 in runtime.asmcgocall () at /usr/local/go/src/runtime/asm_amd64.s:918
#18 0x000000c000260380 in ?? ()
#19 0x00007a4c35d587c0 in ?? ()
#20 0x00007a4c35d58824 in ?? ()
#21 0x0000000000000000 in ?? ()

0xdfdfdfdfdfdfdfdf is interesting because it seems to be used as a magic number by some allocators to detect "use after free" issues (not sure if it's the case of mimalloc).

A user of FrankenPHP reported a crash that is a bit different but may be related (php/frankenphp#676 (comment)).

#0  get_nominal_size (end=0x7f936a6e020c "\223\177", p=0x7f936a6df6d0 "\300\241y\\\223\177") at src/malloc/mallocng/meta.h:163
#1  __libc_free (p=p@entry=0x7f936a6df6d0) at src/malloc/mallocng/free.c:110
#2  0x00007f93b5ea4654 in __libc_realloc (p=0x7f936a6df6d0, n=256) at src/malloc/mallocng/realloc.c:49
#3  0x00007f93b4cb5b5f in OPENSSL_LH_insert ()
#4  0x00007f93b4cb7607 in namemap_add_name ()
#5  0x00007f93b4cb8498 in get_legacy_cipher_names ()
#6  0x00007f93b4cb5f02 in OPENSSL_LH_doall_arg_thunk ()
#7  0x00007f93b4cd887e in OBJ_NAME_do_all ()
#8  0x00007f93b4cb7daf in ossl_namemap_stored ()
#9  0x00007f93b4c9a65e in evp_generic_do_all ()
#10 0x00007f93b4ca0dca in EVP_KEYMGMT_do_all_provided ()
#11 0x00007f93b4e47cd5 in OSSL_DECODER_CTX_new_for_pkey ()
#12 0x00007f93b4ce00f0 in pem_read_bio_key ()
#13 0x00007f93b4ce0554 in PEM_read_bio_PrivateKey ()
#14 0x00007f93b41ca9fc in php_openssl_pkey_from_zval (val=0x7f935ca180d0, public_key=0, passphrase=0x7f935fc00268 "", passphrase_len=0, arg_num=1)
    at /go/src/app/dist/static-php-cli/source/php-src/ext/openssl/openssl.c:3659
#15 0x00007f93b41ce38a in zif_openssl_pkey_get_private (execute_data=0x7f935ca18080, return_value=0x7f935ca18060) at /go/src/app/dist/static-php-cli/source/php-src/ext/openssl/openssl.c:4889
#16 0x00007f93b3ff5468 in ZEND_DO_ICALL_SPEC_RETVAL_USED_HANDLER () at /go/src/app/dist/static-php-cli/source/php-src/Zend/zend_vm_execute.h:1337
#17 execute_ex (ex=0x7f935ca16020) at /go/src/app/dist/static-php-cli/source/php-src/Zend/zend_vm_execute.h:57216
#18 0x00007f93b40127f0 in zend_execute (op_array=0x7f935ca65000, return_value=0x0) at /go/src/app/dist/static-php-cli/source/php-src/Zend/zend_vm_execute.h:61604
#19 0x00007f93b3e7e83f in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /go/src/app/dist/static-php-cli/source/php-src/Zend/zend.c:1891
#20 0x00007f93b3dbec37 in php_execute_script (primary_file=0x7f935f8763e0) at /go/src/app/dist/static-php-cli/source/php-src/main/main.c:2531
#21 0x00007f93b3d2c0c1 in frankenphp_execute_script (file_name=0x0) at frankenphp.c:851
#22 0x00007f93b3d29717 in _cgo_b7d6fd74a0c8_Cfunc_frankenphp_execute_script (v=0xc0005d2dd8) at /tmp/go-build/cgo-gcc-prolog:55
#23 0x00007f93b29c7d61 in runtime.asmcgocall () at /usr/local/go/src/runtime/asm_amd64.s:918
#24 0x000000c00028f180 in ?? ()
#25 0x00007f935f876550 in ?? ()
#26 0x00007f935f8765b4 in ?? ()
#27 0x0000000000000000 in ?? ()

I think I'm running into this as well but with a different stack trace, if that helps:

#0  get_meta (p=p@entry=0x7f264266b1e0 "") at src/malloc/mallocng/meta.h:141
#1  0x00007f269cb4c070 in __libc_free (p=0x7f264266b1e0) at src/malloc/mallocng/free.c:105
#2  0x00007f269c373740 in EVP_CIPHER_CTX_reset ()
#3  0x00007f269b5a30ad in php_openssl_encrypt (data=0x7f263806b918 "d7f1210abfc30cbe3d9309f313055ce5f554b7f6|sessions:guest:eFaPprsq4vlyas5i2UnNpiPO0isp0I2peU8Dh6QX", data_len=96, method=0x7f264153d3b0 "aes-256-cbc", method_len=11, password=0x7f263f0f6ec8 "\231\226k\250\vL~^\023\241s\225\345\207ya\027.\264\373\240\375\315\350N\277\246\222\366\300k\251", password_len=32, options=0, iv=0x7f263816e228 "f\226\030\303~Bz(iޤڗO", <incomplete sequence \370>, 
    iv_len=16, tag=0x7f26414172b0, tag_len=16, aad=0x7f269d2210d5 "", aad_len=0) at /go/src/app/dist/static-php-cli/source/php-src/ext/openssl/openssl.c:7700
#4  0x00007f269b5a3250 in zif_openssl_encrypt (execute_data=0x7f2641417210, return_value=0x7f26414171e0) at /go/src/app/dist/static-php-cli/source/php-src/ext/openssl/openssl.c:7719
#5  0x00007f269b3ba628 in ZEND_DO_ICALL_SPEC_RETVAL_USED_HANDLER () at /go/src/app/dist/static-php-cli/source/php-src/Zend/zend_vm_execute.h:1337
#6  execute_ex (ex=0x7f26414161d0) at /go/src/app/dist/static-php-cli/source/php-src/Zend/zend_vm_execute.h:57216
#7  0x00007f269b216ca2 in zend_call_function (fci=0x7f26471d5720, fci_cache=0x7f26471d56f0) at /go/src/app/dist/static-php-cli/source/php-src/Zend/zend_execute_API.c:957
#8  0x00007f269b0f02c1 in zif_frankenphp_handle_request (execute_data=<optimized out>, return_value=0x7f2641416140) at frankenphp.c:372
#9  0x00007f269b3ba628 in ZEND_DO_ICALL_SPEC_RETVAL_USED_HANDLER () at /go/src/app/dist/static-php-cli/source/php-src/Zend/zend_vm_execute.h:1337
#10 execute_ex (ex=0x7f2641416020) at /go/src/app/dist/static-php-cli/source/php-src/Zend/zend_vm_execute.h:57216
#11 0x00007f269b3d79b0 in zend_execute (op_array=0x7f2641466000, return_value=0x0) at /go/src/app/dist/static-php-cli/source/php-src/Zend/zend_vm_execute.h:61604
#12 0x00007f269b2439ff in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /go/src/app/dist/static-php-cli/source/php-src/Zend/zend.c:1891
#13 0x00007f269b183df7 in php_execute_script (primary_file=0x7f26471db660) at /go/src/app/dist/static-php-cli/source/php-src/main/main.c:2531
#14 0x00007f269b0f1281 in frankenphp_execute_script (file_name=0x0) at frankenphp.c:851
#15 0x00007f269b0ee8d7 in _cgo_b7d6fd74a0c8_Cfunc_frankenphp_execute_script (v=0xc000604dd8) at /tmp/go-build/cgo-gcc-prolog:55
#16 0x00007f2699d8cf21 in runtime.asmcgocall () at /usr/local/go/src/runtime/asm_amd64.s:918
#17 0x000000c00069c8c0 in ?? ()
#18 0x00007f26471db7d0 in ?? ()
#19 0x00007f269cb6d1b1 in __timedwait (addr=<optimized out>, val=6311272, clk=1193129792, at=0xc0000832d8, priv=1094803568) at src/thread/__timedwait.c:69
#20 0x00007f264f9510d0 in ?? ()
#21 0x00007f264f9510e0 in ?? ()
#22 0x00007f2652007b38 in ?? ()
#23 0x00007f26471dbb38 in ?? ()
#24 0x00007f26471db840 in ?? ()
#25 0x0000000000000010 in ?? ()
#26 0x00007f269b0ee23c in go_execute_script (rh=0x7f269af6d980 <_cgoexp_b7d6fd74a0c8_go_execute_script>) at _cgo_export.c:69
#27 0x00007f269b0eed10 in thread_do (thread_p=<optimized out>) at C-Thread-Pool/thpool.c:388
#28 0x00007f269cb6230c in start (p=0x7f26471db990) at src/thread/pthread_create.c:207
#29 0x00007f269cb63b75 in __clone () at src/thread/x86_64/clone.s:22

Running a FrankenPHP v1.1.5 amd64 static build with added ds extension (following these debug instructions) on https://github.com/ppy/osu-web

Of note, I cannot reproduce using wrk -c1 -t1 or ab -c 1. Falls over easily as soon as I add concurrency.

Any news?

I got #18516 which might potentially resolve this but needs a bit more work and testing to see if it's really the solution...

The #18516 is ready for review so if anyone wants to test it, that would be cool. I will be testing FrankenPHP with this changes later next week. I need to first see if I can still recreate it as I updated my laptop but if I do, I should be able to verify if that change fixes the problems.

probably resolved via 2f5ef4d

@dunglas

@dunglas found this one still open, cannot reproduce the crash with 8.4/8.5 anymore while 8.2.15 crashes. So this can be closed and we can remove the known incompatibility.

Navigation Menu

Repository navigation

Segmentation fault under high loads in openssl_encrypt in ZTS build (FrankenPHP) #13648

Description

PHP Version

Operating System

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Segmentation fault under high loads in openssl_encrypt in ZTS build (FrankenPHP) #13648

Description

Description

PHP Version

Operating System

Activity

dunglas commented on Mar 11, 2024

bukka commented on Mar 11, 2024

dunglas commented on Mar 11, 2024

dunglas commented on Mar 11, 2024

bukka commented on Mar 11, 2024

devnexen commented on Mar 11, 2024

dunglas commented on Mar 11, 2024

bukka commented on Mar 13, 2024

dunglas commented on Mar 16, 2024

dunglas commented on May 30, 2024

ThePooN commented on Jun 4, 2024

xepozz commented on May 14, 2025

bukka commented on May 14, 2025

bukka commented on May 22, 2025

andypost commented on Jun 5, 2025

henderkes commented on May 15, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions