Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
RE: [Help Requested] Test Differences on 64-bit vs. 32-bit NonStop
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Daniel Stenberg via curl-library <curl-library_at_lists.haxx.se>
Date: Sun, 11 Sep 2022 11:07:02 +0200 (CEST)
On Sat, 10 Sep 2022, rsbecker_at_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.
Date: Sun, 11 Sep 2022 11:07:02 +0200 (CEST)
On Sat, 10 Sep 2022, rsbecker_at_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.htmlReceived on 2022-09-11