curl / Mailing Lists / curl-library / Single Mail
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

From: Daniel Stenberg via curl-library <>
Date: Sun, 11 Sep 2022 11:07:02 +0200 (CEST)

On Sat, 10 Sep 2022, 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.

  | Commercial curl support up to 24x7 is available!
  | Private help, bug fixes, support, ports, new features
Received on 2022-09-11