On Sat, 10 Sep 2022, rsbec...@nexbridge.com wrote:
With that, the stack trace on SIGSEGV is:
Process (2,981) received non-deferrable signal SIGSEGV (number: 11)
(xInspect 2,981):bt
#0 0xfffffffff11d9ccc in memcpyHP ()
#1 0xfffffffff11ddb74 in memcpy ()
#2 0x7fe26435 in ossl_cipher_fillblock (buf=<value optimized out>,
buflen=<value optimized out>, blocksize=<value optimized out>,
in=0x6fffee10, inlen=<value optimized out>)
at
/home/ituglib/randall/openssl-3.0/providers/implementations/ciphers/cipherco
mmon_block.c:68
This is deeeeep inside of OpenSSL.
#14 0x7fd24dd8 in RAND_status ()
at /home/ituglib/randall/openssl-3.0/crypto/rand/rand_lib.c:300
#15 0x700ea82d in rand_enough ()
rand_enough() calls RAND_status(), which is a public OpenSSL function. All the
previous stack levels are inside OpenSSL. This looks very much like an OpenSSL
problem to me.
RAND_status() does not even have an argument, it cannot be used wrongly AFAIK.
--
/ daniel.haxx.se
| Commercial curl support up to 24x7 is available!
| Private help, bug fixes, support, ports, new features
| https://curl.se/support.html
--
Unsubscribe: https://lists.haxx.se/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
