Re: [Valgrind-users] ARM64 executable crashes without Valgrind but runs with Valgrind: Debugging Help Needed

[Paul F. <pj...@wa...>]

On 15-11-24 08:34, Mathew T wrote:
> Hello,
> 
> I’m seeking assistance with a challenging issue involving an
> executable on an ARM64 Ubuntu system. Here’s the problem and what I’ve
> done to investigate it so far:
> 
> Problem Summary: I have an ARM64 executable that crashes with a
> segmentation fault(early to main function, looks like when loading .so
> libraries) when run independently. However, when running it with
> Valgrind, the program completes its execution, although Valgrind does
> report an Invalid free error.

Can you share the source? Even a cut down reproducer?

I've had a quick look at the openssl code. Maybe not the same as your 
version.

void BN_clear_free(BIGNUM *a)
{
     if (a == NULL)
         return;
     if (a->d != NULL && !BN_get_flags(a, BN_FLG_STATIC_DATA))
         bn_free_d(a, 1);
     if (BN_get_flags(a, BN_FLG_MALLOCED)) {
         OPENSSL_cleanse(a, sizeof(*a));
         OPENSSL_free(a);
     }
}

It looks BIGNUM has a member 'd' that actually points to the allocated 
block. I also presume that at the point of failure 'a' is valid and that 
its flags field is also OK.

bn_free_d is probably inlined. I don't see why we don't see the CRYPTO 
function in the callstack. Maybe that's not always used?


> 
> Valgrind Output (partial):
> ===================
> plaintext
> Copy code
> ==2644== Invalid free() / delete / delete[] / realloc()
> ==2644==    at 0x7127AD0: free (in
> /usr/libexec/valgrind/vgpreload_memcheck-arm64-linux.so)
> ==2644==    by 0x838C0CB: BN_clear_free (in
> /usr/lib/aarch64-linux-gnu/libcrypto.so.3)
> ==2644==    by 0x7B8CEAB: ??? (in /usr/lib/aarch64-linux-gnu/libssh.so.4.8.7)
> ==2644==    by 0x7B9121F: ??? (in /usr/lib/aarch64-linux-gnu/libssh.so.4.8.7)
> ==2644==    by 0x7B7DF3F: ??? (in /usr/lib/aarch64-linux-gnu/libssh.so.4.8.7)
> ==2644==    by 0x68C5623: call_init (dl-init.c:70)
> ==2644==    by 0x68C5623: call_init (dl-init.c:26)
> ==2644==    by 0x68C572B: _dl_init (dl-init.c:117)
> ==2644==    by 0x68D7CC7: ??? (in
> /usr/lib/aarch64-linux-gnu/ld-linux-aarch64.so.1)
> ==2644==  Address 0x1 is not stack'd, malloc'd or (recently) free'd

This looks like it's happening before main _dl_init. ld.so loads shared 
libraries and runs any global init code (like C++ constructors).

> Additional Information:
> ====================
> The crash appears to be related to libcrypto and libssh libraries.
> libssh.so.4 and libcrypto.so.3 versions on the system match the
> versions the executable was compiled against.
> I have attempted to gather debug symbols for these libraries to
> analyze further, but only limited information is available from the
> system-provided packages.

Getting debuginfo would help.

> Questions:
> =========
> 1. Could the difference in behavior (running under Valgrind vs.
> standalone) indicate a specific type of issue, such as a memory
> alignment problem?

The memory layout is different when running under valgrind. Mainly the 
stack is in a different place. Allocation alignment is probably the same.

> 2. Are there recommended methods or tools, other than Valgrind and
> GDB, that might help debug memory management issues specifically on
> ARM64?

Sanitizers?

> 3. Has anyone encountered similar issues when libcrypto or libssh
> functions are involved?

No, I don't use Linux arm64 much.

A+
Paul