Segfault at instance creation

[Florisheinen1]

I am trying out rust and ash to do some graphics, but after programming a bit, my program segfaulted. Removing more and more code while testing with valgrind finally showed me I get an invalid read at instance creation:

pub fn test() {
    let entry = unsafe { ash::Entry::linked() };
    let instance = unsafe { entry.create_instance(&Default::default(), None).unwrap() };
    unsafe {
        instance.destroy_instance(None);
    }
}

If I run this program (just a main calling the test function) with valgrind, I get the following result:

==31771== Invalid read of size 8
==31771==    at 0x40286C8: strncmp (strcmp.S:172)
==31771==    by 0x400668D: is_dst (dl-load.c:216)
==31771==    by 0x400810E: _dl_dst_count (dl-load.c:253)
==31771==    by 0x400810E: expand_dynamic_string_token (dl-load.c:395)
==31771==    by 0x40082B7: fillin_rpath.isra.0 (dl-load.c:483)
==31771==    by 0x4008602: decompose_rpath (dl-load.c:654)
==31771==    by 0x400ABF5: cache_rpath (dl-load.c:696)
==31771==    by 0x400ABF5: cache_rpath (dl-load.c:677)
==31771==    by 0x400ABF5: _dl_map_object (dl-load.c:2165)
==31771==    by 0x4003494: openaux (dl-deps.c:64)
==31771==    by 0x4A6FC27: _dl_catch_exception (dl-error-skeleton.c:208)
==31771==    by 0x4003C7B: _dl_map_object_deps (dl-deps.c:248)
==31771==    by 0x400EA0E: dl_open_worker_begin (dl-open.c:592)
==31771==    by 0x4A6FC27: _dl_catch_exception (dl-error-skeleton.c:208)
==31771==    by 0x400DF99: dl_open_worker (dl-open.c:782)
==31771==  Address 0x513ca89 is 9 bytes inside a block of size 15 alloc'd
==31771==    at 0x4848899: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==31771==    by 0x40271FF: malloc (rtld-malloc.h:56)
==31771==    by 0x40271FF: strdup (strdup.c:42)
==31771==    by 0x4008594: decompose_rpath (dl-load.c:629)
==31771==    by 0x400ABF5: cache_rpath (dl-load.c:696)
==31771==    by 0x400ABF5: cache_rpath (dl-load.c:677)
==31771==    by 0x400ABF5: _dl_map_object (dl-load.c:2165)
==31771==    by 0x4003494: openaux (dl-deps.c:64)
==31771==    by 0x4A6FC27: _dl_catch_exception (dl-error-skeleton.c:208)
==31771==    by 0x4003C7B: _dl_map_object_deps (dl-deps.c:248)
==31771==    by 0x400EA0E: dl_open_worker_begin (dl-open.c:592)
==31771==    by 0x4A6FC27: _dl_catch_exception (dl-error-skeleton.c:208)
==31771==    by 0x400DF99: dl_open_worker (dl-open.c:782)
==31771==    by 0x4A6FC27: _dl_catch_exception (dl-error-skeleton.c:208)
==31771==    by 0x400E34D: _dl_open (dl-open.c:883)

The segfault only gets noticed once in a while, so to increase the odds of valgrind finding it, I ran valgrind with valgrind --redzone-size=256 ./target/debug/program.

My question: What could have gone wrong? Am I incorrectly using the Default functionality here? (Which would be weird because it also segfaulted without using the Default) Or could this be a driver issue?

[Ralith]

I think the code you pasted above should work fine. Judging by the backtrace, it looks like this is happening inside dlopen. Being part of libc it's unlikely for that to be broken, but it nonetheless looks like it's passing a bad length to strncmp.

Why is your code not present in the backtrace you quoted? Can you get a more complete backtrace? Can you reproduce the issue with a debug libc?

[Florisheinen1]

Running valgrind with the --num-calls=50 instead of the default 12 got me a longer stack trace, resulting in the following output: valgrind-memcheck_v18.txt

I accidentally found out that an older version of valgrind has a bug in which stack traces are incorrectly shown which is solved in newer versions. I then saw I was indeed using an older version (version 3.18), so I updated the valgrind to 3.20. The funny thing is that suddenly valgrind did not find a segfault anymore!

I am wondering whether the initial memcheck contained a false positive, or if the newer version does not catch the error. I do know my original code, not the minimum reproducible code I've provided here, does in fact have a segfault, so I will come back soon to this thread to elaborate, as I did think the wrong instance resulted in this weird behaviour.

[MarijnS95]

@Florisheinen1 did you ever figure this out or can I mark your comment as answer?

[Florisheinen1]

I continued with the same code on Windows 11 for a while, which did not crash or freeze, and later returned to Ubuntu again. Now it works fine on Ubuntu somehow, so I have a gut feeling it might be because of driver issues, or because I made some tiny mistake on my end that resulted in undefined behaviour.
I magically do not have this problem anymore, so I would be fine with this thread being closed.