[Solved] Issue with nouveau and vulkan/opengl

[Nima0908]

Hello,
iam using llvm/musl system with nouveau and i cant get nvk/zink to work as using it causes a segfault. Iam not too sure if its nvk or zink, as when not using zink, i dont get the segfault but as far as i see it vulkan isnt used in that case at all, so it might even be the nvk driver. Iam on the newest version of mesa and the kernel (both stable). When booting from the livegui usb it works, but it doesnt use nvk or zink at all and just plain old nouveau. I tried plain nouveau too but i have no other opengl implementation set so it doesnt change anything from nouveau + nvk how i use it now.

A lot more detailed information how i found out what the issue is can be found here:
https://forums.gentoo.org/viewtopic-t-1177089.html

I have some snippets of dmesg and strace which reveal where the SIGSEGV happens more precisely:

Strace:

Code: Select all

9999  execve("/usr/bin/Hyprland", ["Hyprland", "--watchdog-fd", "4"], 0x7ffd3c919408 /* 27 vars */) = 0
...
9999  open("/usr/lib/libvulkan_nouveau.so", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 37
...
9999  read(37, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0\0\0\0\0\0\0\0"..., 960) = 960
...
9999  close(37)  

Dmesg:

Code: Select all

[  289.417994] nouveau 0000:01:00.0: [drm] *ERROR* DP-3: invalid native reply 0x03
[ 1303.945024] niri[65121]: segfault at 0 ip 00007f1a88cce7e0 sp 00007ffdf3ac25d0 error 4 in libvulkan_nouveau.so[ecd7e0,7f1a886ee000+610000] likely on CPU 6 (core 2, socket 0)
[ 1303.945034] Code: 8b 05 f4 7b 0a 00 eb 22 66 90 4a 8b 34 30 48 83 c6 08 ba 08 00 00 00 48 89 df e8 9f 6f 02 00 48 8b 05 d4 7b 0a 00 49 83 c6 10 <4a> 8b 4c 30 f8 48 83 f9 19 74 d5 48 85 c9 75 ec 48 8b 44 24 08 48
[ 1382.333368] niri[114350]: segfault at 0 ip 00007f63526ce7e0 sp 00007ffd949c94e0 error 4 in libvulkan_nouveau.so[ecd7e0,7f63520ee000+610000] likely on CPU 6 (core 2, socket 0)
[ 1382.333379] Code: 8b 05 f4 7b 0a 00 eb 22 66 90 4a 8b 34 30 48 83 c6 08 ba 08 00 00 00 48 89 df e8 9f 6f 02 00 48 8b 05 d4 7b 0a 00 49 83 c6 10 <4a> 8b 4c 30 f8 48 83 f9 19 74 d5 48 85 c9 75 ec 48 8b 44 24 08 48
[ 1592.371916] niri[147065]: segfault at 0 ip 00007fa0916ce7e0 sp 00007fff58b3c6b0 error 4 in libvulkan_nouveau.so[ecd7e0,7fa0910ee000+610000] likely on CPU 5 (core 1, socket 0)
[ 1592.371924] Code: 8b 05 f4 7b 0a 00 eb 22 66 90 4a 8b 34 30 48 83 c6 08 ba 08 00 00 00 48 89 df e8 9f 6f 02 00 48 8b 05 d4 7b 0a 00 49 83 c6 10 <4a> 8b 4c 30 f8 48 83 f9 19 74 d5 48 85 c9 75 ec 48 8b 44 24 08 48
[ 1877.886359] niri[158492]: segfault at 0 ip 00007f0e536d8d30 sp 00007ffecf3c68a0 error 4 in libvulkan_nouveau.so[ed7d30,7f0e530f3000+61b000] likely on CPU 7 (core 3, socket 0)
[ 1877.886370] Code: 8b 05 34 d3 0a 00 eb 22 66 90 4a 8b 34 30 48 83 c6 08 ba 08 00 00 00 48 89 df e8 9f ad 02 00 48 8b 05 14 d3 0a 00 49 83 c6 10 <4a> 8b 4c 30 f8 48 83 f9 19 74 d5 48 85 c9 75 ec 48 8b 44 24 08 48

I have never used nouveau before (i wouldnt even now but iam forced to) so i have no clue why this happens. I searched online and couldnt find another issue like this at all.

From the two snippets, i would assume its userspace nouveau, so i gues the issue resides inside of mesa, or more precisely either nvk or zink but again iam not sure. Running

Code: Select all

vulkaninfo

returns a segfault, so i would guess its nvk`s fault. Does anyone know how to fix it or how to pinpoint it more precisely?
Thank you for your time and answers (and sorry for the confusing explaination)

[GDH-gentoo]

Maybe it's easier to obtain a backtrace from Niri with GDB / LLDB than it was doing so from Hyprland.

[Nima0908]

Thanks for your answer. Thans a very good idea, ill try it. For now, i ran vulkaninfo in gdb as it resulted in the same outcome (a SIGSEGV). I got following outcome:

Code: Select all

0x00007ffff7c1b9a8 in __malloc_alloc_meta () from /usr/lib/libvulkan_nouveau.so

Havent had time to really look into it yet, but from what i see its a issue with compilling against musl. Ill look into it further, but maybe someone already knows about that issue .

[GDH-gentoo]

That's a little better. Could you post the full backtrace (GDB command bt) from vulkaninfo?

[Nima0908]

Sure. The full bt is:

Code: Select all

#0 0x00007ffff7c1b9a8 in __malloc_alloc_meta () from /usr/lib/libvulkan_nouveau.so
No symbol table info available.
#1 0x00000000000000 in ?? ()
No symbol table info available. 

I have no clue from what library the last one is exactly so i have no clue which one i should build with debug symbols. I build mesa with full debug symbol support and installsources.

[Hu]

The bad frame #1 is likely because you do not have proper debug symbols for frame #0, so the stack walk fails. If you had proper debug symbols, I would expect to see a source file name, not a shared object name. Please rebuild libvulkan_nouveau.so with debug symbols, and try again.

[elllannlaz]

This looks like an NVK issue, not really Zink.

If vulkaninfo already segfaults in libvulkan_nouveau.so, the problem is in Vulkan userspace (Mesa/NVK), and Zink is just exposing it.

Also, llvm/musl + nouveau/NVK is a pretty uncommon setup, so it could be a build-specific bug.

I’d test with a minimal setup and probably report it as an NVK/Mesa issue with your versions and GPU

[GDH-gentoo]

I have no clue from what library the last one is exactly so i have no clue which one i should build with debug symbols>

Make sure at least media-libs/mesa (for libvulkan_nouveau.so a.k.a NVK and other libraries), media-libs/vulkan-loader (for libvulkan.so.1, which is dlopen()'ed by the zink driver) and dev-util/vulkan-tools (for vulkaninfo) are built with debug information, and repeat the backtrace.

[Nima0908]

After rebuilding vulkan-loader and vulkan-tools with debugsymbols and installsources now too and manually loading /usr/lib/debug/usr/lib/libvulkan_nouveau.so.debug (because it didnt load automatically) i got the following:

Code: Select all

(gdb) bt full
#0
0x00007ffff7c1b9a0 in __malloc_alloc_meta () from /usr/lib/libvulkan_nouveau.so
No symbol table info available.
#1
0x0000000000000000 in ?? ()
No symbol table info available.

I still dont know what file the other one belongs too. Ill file a bug report on mesa as soon as i can, i havent had time till now

[GDH-gentoo]

Honestly, I don't know what you are doing with GDB. You are supposed to run a program that segfaults, let it segfault, and post the backtrace when it does. You have three programs to pick from, according to your tests: Hyprland, Niri and vulkaninfo. You say that you rebuilt dev-util/vulkan-tools with debug information, among others. Fine, pick vulkaninfo then. That's gdb vulkaninfo, then run (once in GDB), then wait for the segfault, then bt.

Also, let us see what you did, post the output of find /usr/lib/debug -type f.

Mesa developers are likely going to want a proper backtrace too if you create an issue upstream.

[Nima0908]

That is what iam doing the whole time? I run gdb vulkaninfoand then run inside gdb. Iam not that stupid. Here is the output of the command:

Code: Select all

/usr/lib/debug/usr/bin/x86_64-pc-linux-musl-vulkaninfo.debug
/usr/lib/debug/usr/lib/libVkLayer_MESA_overlay.so.debug
/usr/lib/debug/usr/lib/libgallium-25.3.6.so.debug
/usr/lib/debug/usr/lib/libVkLayer_MESA_device_select.so.debug
/usr/lib/debug/usr/lib/libvulkan.so.1.4.335.debug
/usr/lib/debug/usr/lib/gbm/dri_gbm.so.debug
/usr/lib/debug/usr/lib/libEGL_mesa.so.0.0.0.debug
/usr/lib/debug/usr/lib/libvulkan_nouveau.so.debug
/usr/lib/debug/usr/lib/libVkLayer_MESA_anti_lag.so.debug
/usr/lib/debug/usr/lib/libgbm.so.1.0.0.debug

As you can see, iam not incompetent and build the debug symbols.

If i now run gdb vulkaninfo and then run inside and bt after it segfaults i get the backtrace i already posted:

Code: Select all

 #0 0x00007ffff7c1b9a8 in __malloc_alloc_meta () from /usr/lib/libvulkan_nouveau.so
No symbol table info available.
#1 0x00000000000000 in ?? ()
No symbol table info available.

If youre unhappy with this bt, iam too but i cant change it. The symbol table is built and gets loaded. Iam trying my best to figure out what #1 correlates to so i can build the corresponding debug symbols for it. I know how gdb and other debugging tools work, iam no newbie to this area, and if i were i woudnt have chosen llvm/musl. Therefore i would much appreciate it not being told that i dont know how these tools work . Thank you

[GDH-gentoo]

That is what iam doing the whole time?

OK, OK, you weren't very descriptive about what you were doing, so I had to make sure...

I run gdb vulkaninfoand then run inside gdb. Iam not that stupid. Here is the output of the command:

Code: Select all

/usr/lib/debug/usr/bin/x86_64-pc-linux-musl-vulkaninfo.debug
...

[...]

If i now run gdb vulkaninfo and then run inside and bt after it segfaults i get the backtrace i already posted:

Wait, the actual ELF executable is /usr/bin/x86_64-pc-linux-musl-vulkaninfo? Try using that name when running in GDB, i. e. gdb x86_64-pc-linux-musl-vulkaninfo, and see if the backtrace improves.

[Hu]

Also, as a general tip, post the full output of what you think should be working. If you had shown a single code block that starts at your shell prompt, includes gdb program, the gdb startup banner, the fault notice, and all the commands you entered, it would be easier for us to check that you didn't miss a step.

I don't know why your current steps aren't working, but my interpretation of the latest gdb output is that you still don't have debug symbols loaded for the innermost function. I see that you say you loaded them, but whatever you did, it doesn't seem to have helped.

[Nima0908]

Thank fou for all your answers. I decided now to switch over to lldb (just to try out if this works better for me) and i got the following:

Code: Select all

marius@gentoo ~ $ lldb vulkaninfo

(lldb) target create "vulkaninfo"
Current executable set to '/usr/bin/vulkaninfo' (x86_64).

(lldb) run
Process 14516 launched: '/usr/bin/vulkaninfo' (x86_64)
Process 14516 stopped
* thread #1, name = 'vulkaninfo', stop reason = signal SIGSEGV: address not mapped to object (fault address=0x0)
    frame #0: 0x00007ffff7c1b9a0 libvulkan_nouveau.so`__malloc_alloc_meta + 96
libvulkan_nouveau.so`__malloc_alloc_meta:
->  0x7ffff7c1b9a0 <+96>:  movq   -0x8(%rax,%r14), %rcx
    0x7ffff7c1b9a5 <+101>: cmpq   $0x19, %rcx
    0x7ffff7c1b9a9 <+105>: je     0x7ffff7c1b980            ; <+64>
    0x7ffff7c1b9ab <+107>: testq  %rcx, %rcx

(lldb) bt all
* thread #1, name = 'vulkaninfo', stop reason = signal SIGSEGV: address not mapped to object (fault address=0x0)
  * frame #0: 0x00007ffff7c1b9a0 libvulkan_nouveau.so`__malloc_alloc_meta + 96
    frame #1: 0x00007ffff7c1c1a2 libvulkan_nouveau.so`alloc_slot + 418
    frame #2: 0x00007ffff7c1bde3 libvulkan_nouveau.so`__libc_malloc_impl + 419
    frame #3: 0x00007ffff7a1e0b7 libvulkan_nouveau.so`ralloc_size(ctx=0x0000000000000000, size=<unavailable>) at ralloc.c:118:18 [inlined]
    frame #4: 0x00007ffff7a1e0aa libvulkan_nouveau.so`rzalloc_size(ctx=0x0000000000000000, size=<unavailable>) at ralloc.c:152:16
    frame #5: 0x00007ffff7a1ab2b libvulkan_nouveau.so`_mesa_hash_table_u64_create(mem_ctx=<unavailable>) at hash_table.c:892:9
    frame #6: 0x00007ffff7a2630c libvulkan_nouveau.so`u_printf_singleton_init_or_ref at u_printf.c:392:27
    frame #7: 0x00007ffff758792f libvulkan_nouveau.so`(anonymous namespace)::vtn_bindgen_dummy::vtn_bindgen_dummy(this=<unavailable>) at nvkcl.cpp:318:10
    frame #8: 0x00007ffff7587922 libvulkan_nouveau.so`__cxx_global_var_init at nvkcl.cpp:327:29 [inlined]
    frame #9: 0x00007ffff7587922 libvulkan_nouveau.so`_GLOBAL__sub_I_nvkcl.cpp at nvkcl.cpp:0
    frame #10: 0x00007ffff7ff3858 libc.so`_dlstart + 1688

(lldb) continue
Process 14516 resuming
Process 14516 exited with status = 11 (0x0000000b)

Judging from this it seems to be a nullpointer issue.

Here is also my GDB output:

Code: Select all

marius@gentoo ~ $ gdb vulkaninfo

GNU gdb (Gentoo 16.3 vanilla) 16.3
Copyright (C) 2024 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-musl".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://bugs.gentoo.org/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from vulkaninfo...
Reading symbols from /usr/lib/debug/usr/bin/x86_64-pc-linux-musl-vulkaninfo.debug...

(gdb) run
Starting program: /usr/bin/vulkaninfo 
Loading libc++ pretty-printers.

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7c1b9a0 in __malloc_alloc_meta () from /usr/lib/libvulkan_nouveau.so

(gdb) bt full
#0  0x00007ffff7c1b9a0 in __malloc_alloc_meta () from /usr/lib/libvulkan_nouveau.so
No symbol table info available.
#1  0x0000000000000000 in ?? ()
No symbol table info available.

(gdb) continue
Continuing.

Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.

(gdb) exit

GDH-gentoo please excuse my rudeness in my last message. I hope i didnt offend you in any way with it. Iam very sorry for my inappropriate language i used in it.

[GDH-gentoo]

I would have tried using the name x86_64-pc-linux-musl-vulkaninfo instead of plain vulkaninfo, but anyway, LLDB did provide some more information:

Code: Select all

    frame #3: 0x00007ffff7a1e0b7 libvulkan_nouveau.so`ralloc_size(ctx=0x0000000000000000, size=<unavailable>) at ralloc.c:118:18 [inlined]

This corresponds to the last function in NVK that was executed before jumping to code in musl.

src/util/ralloc.c

Code: Select all

void *
ralloc_size(const void *ctx, size_t size)
{
   /* Some malloc allocation doesn't always align to 16 bytes even on 64 bits
    * system, from Android bionic/tests/malloc_test.cpp:
    *  - Allocations of a size that rounds up to a multiple of 16 bytes
    *    must have at least 16 byte alignment.
    *  - Allocations of a size that rounds up to a multiple of 8 bytes and
    *    not 16 bytes, are only required to have at least 8 byte alignment.
    */
   void *block = malloc(align64(size + sizeof(ralloc_header),
                                alignof(ralloc_header)));
   // ...

   if (unlikely(block == NULL))
      return NULL;

   info = (ralloc_header *) block;
   // ...
   return PTR_FROM_HEADER(info);
}

So this is just calling malloc(). The rest are internals of musl's implementation of malloc(), which where the segfault seems to happen —maybe a null pointer dereference, like you said— , but isn't as detailed because musl itself wasn't rebuilt with debug information:

Code: Select all

* thread #1, name = 'vulkaninfo', stop reason = signal SIGSEGV: address not mapped to object (fault address=0x0)
  * frame #0: 0x00007ffff7c1b9a0 libvulkan_nouveau.so`__malloc_alloc_meta + 96
    frame #1: 0x00007ffff7c1c1a2 libvulkan_nouveau.so`alloc_slot + 418
    frame #2: 0x00007ffff7c1bde3 libvulkan_nouveau.so`__libc_malloc_impl + 419

src/malloc/lite_malloc.c

Code: Select all

#include <stdlib.h>
// ...
static void *default_malloc(size_t n)
{
	return __libc_malloc_impl(n);
}

weak_alias(default_malloc, malloc);

src/malloc/mallocng/glue.h

Code: Select all

// use macros to appropriately namespace these.
// ...
#define alloc_meta __malloc_alloc_meta
// ...
#define malloc __libc_malloc_impl

src/malloc/mallocng/meta.h

Code: Select all

#include "glue.h"

src/malloc/mallocng/malloc.c

Code: Select all

#include "meta.h"
//...
struct meta *alloc_meta(void)
{
	// Function body
}
// ...
static int alloc_slot(int sc, size_t req)
{
	// Function body
}

void *malloc(size_t n)
{
	// Function body
}

The segmentaton fault happens when executing the body of alloc_meta() a.k.a. __malloc_alloc_meta() after macro expansion. However, in principle, the only information that is passed from NVK to musl is the requested size of the memory allocation, so I'm still not exactly sure about what's happening, and whose fault is it (NVK or musl), so I suggest repeating with musl also rebuilt with debug symbols.

[Nima0908]

Thanks for your answer. Sorry, i totally overread x86_64-vulkaninfo. Thanks for the suggestion with building musl with debug symbols, now the output is much more precise. Here is the output of lldb vulkaninfo:

Code: Select all

(lldb) target create "vulkaninfo"
Current executable set to '/usr/bin/vulkaninfo' (x86_64).

(lldb) run
Process 6423 launched: '/usr/bin/vulkaninfo' (x86_64)
Process 6423 stopped
* thread #1, name = 'vulkaninfo', stop reason = signal SIGSEGV: address not mapped to object (fault address=0x0)
    frame #0: 0x00007ffff7c1b9a0 libvulkan_nouveau.so`__malloc_alloc_meta + 96
libvulkan_nouveau.so`__malloc_alloc_meta:
->  0x7ffff7c1b9a0 <+96>:  movq   -0x8(%rax,%r14), %rcx
    0x7ffff7c1b9a5 <+101>: cmpq   $0x19, %rcx
    0x7ffff7c1b9a9 <+105>: je     0x7ffff7c1b980            ; <+64>
    0x7ffff7c1b9ab <+107>: testq  %rcx, %rcx

(lldb) bt all
* thread #1, name = 'vulkaninfo', stop reason = signal SIGSEGV: address not mapped to object (fault address=0x0)
  * frame #0: 0x00007ffff7c1b9a0 libvulkan_nouveau.so`__malloc_alloc_meta + 96
    frame #1: 0x00007ffff7c1c1a2 libvulkan_nouveau.so`alloc_slot + 418
    frame #2: 0x00007ffff7c1bde3 libvulkan_nouveau.so`__libc_malloc_impl + 419
    frame #3: 0x00007ffff7a1e0b7 libvulkan_nouveau.so`ralloc_size(ctx=0x0000000000000000, size=<unavailable>) at ralloc.c:118:18 [inlined]
    frame #4: 0x00007ffff7a1e0aa libvulkan_nouveau.so`rzalloc_size(ctx=0x0000000000000000, size=<unavailable>) at ralloc.c:152:16
    frame #5: 0x00007ffff7a1ab2b libvulkan_nouveau.so`_mesa_hash_table_u64_create(mem_ctx=<unavailable>) at hash_table.c:892:9
    frame #6: 0x00007ffff7a2630c libvulkan_nouveau.so`u_printf_singleton_init_or_ref at u_printf.c:392:27
    frame #7: 0x00007ffff758792f libvulkan_nouveau.so`(anonymous namespace)::vtn_bindgen_dummy::vtn_bindgen_dummy(this=<unavailable>) at nvkcl.cpp:318:10
    frame #8: 0x00007ffff7587922 libvulkan_nouveau.so`__cxx_global_var_init at nvkcl.cpp:327:29 [inlined]
    frame #9: 0x00007ffff7587922 libvulkan_nouveau.so`_GLOBAL__sub_I_nvkcl.cpp at nvkcl.cpp:0
    frame #10: 0x00007ffff7ff3878 libc.so`do_init_fini(queue=0x00007ffff7ffbf10) at dynlink.c:1610:16
    frame #11: 0x00007ffff7ff6693 libc.so`dlopen(file=<unavailable>, mode=1) at dynlink.c:2223:3
    frame #12: 0x00007ffff7d8dd4c libvulkan.so.1`loader_platform_open_library(libPath="/usr/lib/libvulkan_nouveau.so") at vk_loader_platform.h:414:12 [inlined]
    frame #13: 0x00007ffff7d8dd3f libvulkan.so.1`loader_scanned_icd_add(inst=0x0000000000000000, icd_tramp_list=0x00007ffff7db3ab0, filename=<unavailable>, api_version=<unavailable>, lib_status=<unavailable>) at loader.c:2096:14
    frame #14: 0x00007ffff7d8e756 libvulkan.so.1`loader_icd_scan(inst=0x0000000000000000, icd_tramp_list=0x00007ffff7db3ab0, pCreateInfo=0x0000000000000000, skipped_portability_drivers=0x0000000000000000) at loader.c:4156:13
    frame #15: 0x00007ffff7d8e440 libvulkan.so.1`loader_preload_icds at loader.c:2356:23
    frame #16: 0x00007ffff7d940df libvulkan.so.1`terminator_EnumerateInstanceExtensionProperties(pLayerName=0x0000000000000000, pPropertyCount=0x00007fffffffd2ac, pProperties=0x00007ffff7d0f350) at loader.c:7574:9
    frame #17: 0x00007ffff7d9eab9 libvulkan.so.1`vkEnumerateInstanceExtensionProperties(pLayerName=0x0000000000000000, pPropertyCount=0x00007fffffffd2ac, pProperties=0x00007ffff7d0f350) at trampoline.c:240:15
    frame #18: 0x0000555555687e00 vulkaninfo`std::__1::vector<VkExtensionProperties, std::__1::allocator<VkExtensionProperties>> GetVectorInit<VkExtensionProperties, VkResult (*&)(char const*, unsigned int*, VkExtensionProperties*), char const*&>(func_name="vkEnumerateInstanceExtensionProperties", f=(vulkaninfo`vkEnumerateInstanceExtensionProperties), init=(extensionName = "", specVersion = 0), ts=<no value available>) at vulkaninfo.h:243:15
    frame #19: 0x00005555556869d1 vulkaninfo`std::__1::vector<VkExtensionProperties, std::__1::allocator<VkExtensionProperties>> GetVector<VkExtensionProperties, VkResult (*&)(char const*, unsigned int*, VkExtensionProperties*), char const*&>(func_name=<unavailable>, f=<unavailable>, ts=<no value available>) at vulkaninfo.h:253:12 [inlined]
    frame #20: 0x0000555555686936 vulkaninfo`AppInstance::AppGetGlobalLayerExtensions(this=0x00007fffffffdb30, layer_name=0x0000000000000000) at vulkaninfo.h:720:16 [inlined]
    frame #21: 0x0000555555686936 vulkaninfo`AppInstance::AppGetInstanceExtensions(this=0x00007fffffffdb30) at vulkaninfo.h:612:29
    frame #22: 0x000055555567bc3a vulkaninfo`AppInstance::AppInstance(this=0x00007fffffffdb30) at vulkaninfo.h:539:9
    frame #23: 0x000055555564818e vulkaninfo`main(argc=1, argv=0x00007fffffffe048) at vulkaninfo.cpp:1301:32
    frame #24: 0x00007ffff7f99dba libc.so`libc_start_main_stage2(main=(vulkaninfo`main at vulkaninfo.cpp:1254), argc=<unavailable>, argv=0x00007fffffffe048) at __libc_start_main.c:95:7
    frame #25: 0x000055555559bae6 vulkaninfo`_start + 22

(lldb) continue
Process 6423 resuming
Process 6423 exited with status = 11 (0x0000000b) 

(lldb) exit

And here for lldb x86_64-vulkaninfo:

Code: Select all

(lldb) target create "x86_64-pc-linux-musl-vulkaninfo"
Current executable set to '/usr/bin/x86_64-pc-linux-musl-vulkaninfo' (x86_64).

(lldb) run
Process 6483 launched: '/usr/bin/x86_64-pc-linux-musl-vulkaninfo' (x86_64)
Process 6483 stopped
* thread #1, name = 'x86_64-pc-linux', stop reason = signal SIGSEGV: address not mapped to object (fault address=0x0)
    frame #0: 0x00007ffff7c1b9a0 libvulkan_nouveau.so`__malloc_alloc_meta + 96
libvulkan_nouveau.so`__malloc_alloc_meta:
->  0x7ffff7c1b9a0 <+96>:  movq   -0x8(%rax,%r14), %rcx
    0x7ffff7c1b9a5 <+101>: cmpq   $0x19, %rcx
    0x7ffff7c1b9a9 <+105>: je     0x7ffff7c1b980            ; <+64>
    0x7ffff7c1b9ab <+107>: testq  %rcx, %rcx

(lldb) bt all
* thread #1, name = 'x86_64-pc-linux', stop reason = signal SIGSEGV: address not mapped to object (fault address=0x0)
  * frame #0: 0x00007ffff7c1b9a0 libvulkan_nouveau.so`__malloc_alloc_meta + 96
    frame #1: 0x00007ffff7c1c1a2 libvulkan_nouveau.so`alloc_slot + 418
    frame #2: 0x00007ffff7c1bde3 libvulkan_nouveau.so`__libc_malloc_impl + 419
    frame #3: 0x00007ffff7a1e0b7 libvulkan_nouveau.so`ralloc_size(ctx=0x0000000000000000, size=<unavailable>) at ralloc.c:118:18 [inlined]
    frame #4: 0x00007ffff7a1e0aa libvulkan_nouveau.so`rzalloc_size(ctx=0x0000000000000000, size=<unavailable>) at ralloc.c:152:16
    frame #5: 0x00007ffff7a1ab2b libvulkan_nouveau.so`_mesa_hash_table_u64_create(mem_ctx=<unavailable>) at hash_table.c:892:9
    frame #6: 0x00007ffff7a2630c libvulkan_nouveau.so`u_printf_singleton_init_or_ref at u_printf.c:392:27
    frame #7: 0x00007ffff758792f libvulkan_nouveau.so`(anonymous namespace)::vtn_bindgen_dummy::vtn_bindgen_dummy(this=<unavailable>) at nvkcl.cpp:318:10
    frame #8: 0x00007ffff7587922 libvulkan_nouveau.so`__cxx_global_var_init at nvkcl.cpp:327:29 [inlined]
    frame #9: 0x00007ffff7587922 libvulkan_nouveau.so`_GLOBAL__sub_I_nvkcl.cpp at nvkcl.cpp:0
    frame #10: 0x00007ffff7ff3878 libc.so`do_init_fini(queue=0x00007ffff7ffbf10) at dynlink.c:1610:16
    frame #11: 0x00007ffff7ff6693 libc.so`dlopen(file=<unavailable>, mode=1) at dynlink.c:2223:3
    frame #12: 0x00007ffff7d8dd4c libvulkan.so.1`loader_platform_open_library(libPath="/usr/lib/libvulkan_nouveau.so") at vk_loader_platform.h:414:12 [inlined]
    frame #13: 0x00007ffff7d8dd3f libvulkan.so.1`loader_scanned_icd_add(inst=0x0000000000000000, icd_tramp_list=0x00007ffff7db3ab0, filename=<unavailable>, api_version=<unavailable>, lib_status=<unavailable>) at loader.c:2096:14
    frame #14: 0x00007ffff7d8e756 libvulkan.so.1`loader_icd_scan(inst=0x0000000000000000, icd_tramp_list=0x00007ffff7db3ab0, pCreateInfo=0x0000000000000000, skipped_portability_drivers=0x0000000000000000) at loader.c:4156:13
    frame #15: 0x00007ffff7d8e440 libvulkan.so.1`loader_preload_icds at loader.c:2356:23
    frame #16: 0x00007ffff7d940df libvulkan.so.1`terminator_EnumerateInstanceExtensionProperties(pLayerName=0x0000000000000000, pPropertyCount=0x00007fffffffd28c, pProperties=0x00007ffff7d0f350) at loader.c:7574:9
    frame #17: 0x00007ffff7d9eab9 libvulkan.so.1`vkEnumerateInstanceExtensionProperties(pLayerName=0x0000000000000000, pPropertyCount=0x00007fffffffd28c, pProperties=0x00007ffff7d0f350) at trampoline.c:240:15
    frame #18: 0x0000555555687e00 x86_64-pc-linux-musl-vulkaninfo`std::__1::vector<VkExtensionProperties, std::__1::allocator<VkExtensionProperties>> GetVectorInit<VkExtensionProperties, VkResult (*&)(char const*, unsigned int*, VkExtensionProperties*), char const*&>(func_name="vkEnumerateInstanceExtensionProperties", f=(x86_64-pc-linux-musl-vulkaninfo`vkEnumerateInstanceExtensionProperties), init=(extensionName = "", specVersion = 0), ts=<no value available>) at vulkaninfo.h:243:15
    frame #19: 0x00005555556869d1 x86_64-pc-linux-musl-vulkaninfo`std::__1::vector<VkExtensionProperties, std::__1::allocator<VkExtensionProperties>> GetVector<VkExtensionProperties, VkResult (*&)(char const*, unsigned int*, VkExtensionProperties*), char const*&>(func_name=<unavailable>, f=<unavailable>, ts=<no value available>) at vulkaninfo.h:253:12 [inlined]
    frame #20: 0x0000555555686936 x86_64-pc-linux-musl-vulkaninfo`AppInstance::AppGetGlobalLayerExtensions(this=0x00007fffffffdb10, layer_name=0x0000000000000000) at vulkaninfo.h:720:16 [inlined]
    frame #21: 0x0000555555686936 x86_64-pc-linux-musl-vulkaninfo`AppInstance::AppGetInstanceExtensions(this=0x00007fffffffdb10) at vulkaninfo.h:612:29
    frame #22: 0x000055555567bc3a x86_64-pc-linux-musl-vulkaninfo`AppInstance::AppInstance(this=0x00007fffffffdb10) at vulkaninfo.h:539:9
    frame #23: 0x000055555564818e x86_64-pc-linux-musl-vulkaninfo`main(argc=1, argv=0x00007fffffffe028) at vulkaninfo.cpp:1301:32
    frame #24: 0x00007ffff7f99dba libc.so`libc_start_main_stage2(main=(x86_64-pc-linux-musl-vulkaninfo`main at vulkaninfo.cpp:1254), argc=<unavailable>, argv=0x00007fffffffe028) at __libc_start_main.c:95:7
    frame #25: 0x000055555559bae6 x86_64-pc-linux-musl-vulkaninfo`_start + 22

(lldb) continue
Process 6483 resuming
Process 6483 exited with status = 11 (0x0000000b) 

(lldb) exit

What hits my eye still is

Code: Select all

 ralloc_size(ctx=0x0000000000000000)

. As far as iam aware, drivers shouldnt try to allocate memory using a null context (i may be wrong though).

[GDH-gentoo]

Thanks. There's something that I don't understand.

Code: Select all

    frame #10: 0x00007ffff7ff3878 libc.so`do_init_fini(queue=0x00007ffff7ffbf10) at dynlink.c:1610:16
    frame #11: 0x00007ffff7ff6693 libc.so`dlopen(file=<unavailable>, mode=1) at dynlink.c:2223:3
    ...
    frame #24: 0x00007ffff7f99dba libc.so`libc_start_main_stage2(main=(vulkaninfo`main at vulkaninfo.cpp:1254), argc=<unavailable>, argv=0x00007fffffffe048) at __libc_start_main.c:95:7

These stack frames say that it's code from libc.so, and show function name, function arguments, source file, line, etc., in a way that is consistent with having rebuilt musl with debug information, but...

Code: Select all

  * frame #0: 0x00007ffff7c1b9a0 libvulkan_nouveau.so`__malloc_alloc_meta + 96
    frame #1: 0x00007ffff7c1c1a2 libvulkan_nouveau.so`alloc_slot + 418
    frame #2: 0x00007ffff7c1bde3 libvulkan_nouveau.so`__libc_malloc_impl + 419

... these others don't, and say that it's code from libvulkan_nouveau.so, even though these are musl symbols, as if there had been some kind of static linking. So, could I ask you, now that you have a musl with debug information, to rebuild media-libs/mesa (again with debug information), but saving the build log this time, in case that we have to check something later, and rerun x86_64-pc-linux-musl-vulkaninfo with LLDB?

What hits my eye still is

Code: Select all

 ralloc_size(ctx=0x0000000000000000)

. As far as iam aware, drivers shouldnt try to allocate memory using a null context (i may be wrong though).

No, the code really does pass a null pointer explicitly:

Code: Select all

    frame #5: 0x00007ffff7a1ab2b libvulkan_nouveau.so`_mesa_hash_table_u64_create(mem_ctx=<unavailable>) at hash_table.c:892:9
    frame #6: 0x00007ffff7a2630c libvulkan_nouveau.so`u_printf_singleton_init_or_ref at u_printf.c:392:27

src/util/u_printf.c

Code: Select all

void
u_printf_singleton_init_or_ref(void)
{
   simple_mtx_lock(&u_printf_lock);

   if ((u_printf_cache.users++) == 0) {
      u_printf_cache.ht = _mesa_hash_table_u64_create(NULL);
   }

   simple_mtx_unlock(&u_printf_lock);
}

[Nima0908]

Thank you for your answer. Of course. Here is the new lldb codeblock:

Code: Select all

(lldb) target create "x86_64-pc-linux-musl-vulkaninfo"
Current executable set to '/usr/bin/x86_64-pc-linux-musl-vulkaninfo' (x86_64).

(lldb) run
Process 9555 launched: '/usr/bin/x86_64-pc-linux-musl-vulkaninfo' (x86_64)
Process 9555 stopped
* thread #1, name = 'x86_64-pc-linux', stop reason = signal SIGSEGV: address not mapped to object (fault address=0x0)
    frame #0: 0x00007ffff7c1b9a0 libvulkan_nouveau.so`__malloc_alloc_meta + 96
libvulkan_nouveau.so`__malloc_alloc_meta:
->  0x7ffff7c1b9a0 <+96>:  movq   -0x8(%rax,%r14), %rcx
    0x7ffff7c1b9a5 <+101>: cmpq   $0x19, %rcx
    0x7ffff7c1b9a9 <+105>: je     0x7ffff7c1b980            ; <+64>
    0x7ffff7c1b9ab <+107>: testq  %rcx, %rcx

(lldb) bt all
* thread #1, name = 'x86_64-pc-linux', stop reason = signal SIGSEGV: address not mapped to object (fault address=0x0)
  * frame #0: 0x00007ffff7c1b9a0 libvulkan_nouveau.so`__malloc_alloc_meta + 96
    frame #1: 0x00007ffff7c1c1a2 libvulkan_nouveau.so`alloc_slot + 418
    frame #2: 0x00007ffff7c1bde3 libvulkan_nouveau.so`__libc_malloc_impl + 419
    frame #3: 0x00007ffff7a1e0b7 libvulkan_nouveau.so`ralloc_size(ctx=0x0000000000000000, size=<unavailable>) at ralloc.c:118:18 [inlined]
    frame #4: 0x00007ffff7a1e0aa libvulkan_nouveau.so`rzalloc_size(ctx=0x0000000000000000, size=<unavailable>) at ralloc.c:152:16
    frame #5: 0x00007ffff7a1ab2b libvulkan_nouveau.so`_mesa_hash_table_u64_create(mem_ctx=<unavailable>) at hash_table.c:892:9
    frame #6: 0x00007ffff7a2630c libvulkan_nouveau.so`u_printf_singleton_init_or_ref at u_printf.c:392:27
    frame #7: 0x00007ffff758792f libvulkan_nouveau.so`(anonymous namespace)::vtn_bindgen_dummy::vtn_bindgen_dummy(this=<unavailable>) at nvkcl.cpp:318:10
    frame #8: 0x00007ffff7587922 libvulkan_nouveau.so`__cxx_global_var_init at nvkcl.cpp:327:29 [inlined]
    frame #9: 0x00007ffff7587922 libvulkan_nouveau.so`_GLOBAL__sub_I_nvkcl.cpp at nvkcl.cpp:0
    frame #10: 0x00007ffff7ff3878 libc.so`do_init_fini(queue=0x00007ffff7ffbf10) at dynlink.c:1610:16
    frame #11: 0x00007ffff7ff6693 libc.so`dlopen(file=<unavailable>, mode=1) at dynlink.c:2223:3
    frame #12: 0x00007ffff7d8dd4c libvulkan.so.1`loader_platform_open_library(libPath="/usr/lib/libvulkan_nouveau.so") at vk_loader_platform.h:414:12 [inlined]
    frame #13: 0x00007ffff7d8dd3f libvulkan.so.1`loader_scanned_icd_add(inst=0x0000000000000000, icd_tramp_list=0x00007ffff7db3ab0, filename=<unavailable>, api_version=<unavailable>, lib_status=<unavailable>) at loader.c:2096:14
    frame #14: 0x00007ffff7d8e756 libvulkan.so.1`loader_icd_scan(inst=0x0000000000000000, icd_tramp_list=0x00007ffff7db3ab0, pCreateInfo=0x0000000000000000, skipped_portability_drivers=0x0000000000000000) at loader.c:4156:13
    frame #15: 0x00007ffff7d8e440 libvulkan.so.1`loader_preload_icds at loader.c:2356:23
    frame #16: 0x00007ffff7d940df libvulkan.so.1`terminator_EnumerateInstanceExtensionProperties(pLayerName=0x0000000000000000, pPropertyCount=0x00007fffffffd28c, pProperties=0x00007ffff7d0f350) at loader.c:7574:9
    frame #17: 0x00007ffff7d9eab9 libvulkan.so.1`vkEnumerateInstanceExtensionProperties(pLayerName=0x0000000000000000, pPropertyCount=0x00007fffffffd28c, pProperties=0x00007ffff7d0f350) at trampoline.c:240:15
    frame #18: 0x0000555555687e00 x86_64-pc-linux-musl-vulkaninfo`std::__1::vector<VkExtensionProperties, std::__1::allocator<VkExtensionProperties>> GetVectorInit<VkExtensionProperties, VkResult (*&)(char const*, unsigned int*, VkExtensionProperties*), char const*&>(func_name="vkEnumerateInstanceExtensionProperties", f=(x86_64-pc-linux-musl-vulkaninfo`vkEnumerateInstanceExtensionProperties), init=(extensionName = "", specVersion = 0), ts=<no value available>) at vulkaninfo.h:243:15
    frame #19: 0x00005555556869d1 x86_64-pc-linux-musl-vulkaninfo`std::__1::vector<VkExtensionProperties, std::__1::allocator<VkExtensionProperties>> GetVector<VkExtensionProperties, VkResult (*&)(char const*, unsigned int*, VkExtensionProperties*), char const*&>(func_name=<unavailable>, f=<unavailable>, ts=<no value available>) at vulkaninfo.h:253:12 [inlined]
    frame #20: 0x0000555555686936 x86_64-pc-linux-musl-vulkaninfo`AppInstance::AppGetGlobalLayerExtensions(this=0x00007fffffffdb10, layer_name=0x0000000000000000) at vulkaninfo.h:720:16 [inlined]
    frame #21: 0x0000555555686936 x86_64-pc-linux-musl-vulkaninfo`AppInstance::AppGetInstanceExtensions(this=0x00007fffffffdb10) at vulkaninfo.h:612:29
    frame #22: 0x000055555567bc3a x86_64-pc-linux-musl-vulkaninfo`AppInstance::AppInstance(this=0x00007fffffffdb10) at vulkaninfo.h:539:9
    frame #23: 0x000055555564818e x86_64-pc-linux-musl-vulkaninfo`main(argc=1, argv=0x00007fffffffe028) at vulkaninfo.cpp:1301:32
    frame #24: 0x00007ffff7f99dba libc.so`libc_start_main_stage2(main=(x86_64-pc-linux-musl-vulkaninfo`main at vulkaninfo.cpp:1254), argc=<unavailable>, argv=0x00007fffffffe028) at __libc_start_main.c:95:7
    frame #25: 0x000055555559bae6 x86_64-pc-linux-musl-vulkaninfo`_start + 22

(lldb) continue
Process 9555 resuming
Process 9555 exited with status = 11 (0x0000000b) 

(lldb) exit

Sadly, nothing changed .

Here are also the buildlogs:

https://paste.c-net.org/DreadGabriela

https://paste.c-net.org/ChartsTerminal

https://paste.c-net.org/CostsCrusty

This is the order they are in my /var/log/portage, idk why three, they are all from the last emerge (this one to update mesa using sudo emerge -av1 media-libs/mesa).

[GDH-gentoo]

Sadly, nothing changed .

Which is also a hint...

https://paste.c-net.org/ChartsTerminal

This is the build log.

I'm starting to think that you might be hitting bug #967728 a.k.a. Rust tools continue to suck, episode #N+1 in a different way. Could you post the outputs of:

Code: Select all

$ readelf -d  /usr/lib/libvulkan_nouveau.so
$ readelf -s  /usr/lib/libvulkan_nouveau.so | grep malloc

?

[Nima0908]

Thanks four answer. Here are the outputs of the commands you requested:

readelf -d /usr/libvulkan/libvulkan_nouveau.so:

Code: Select all

Dynamic section at offset 0x10c1270 contains 37 entries:
  Tag                Type           Name/Value
  0x0000000000000001 (NEEDED)       Shared library: [libdrm.so.2]
  0x0000000000000001 (NEEDED)       Shared library: [libz.so.1]
  0x0000000000000001 (NEEDED)       Shared library: [libzstd.so.1]
  0x0000000000000001 (NEEDED)       Shared library: [libwayland-client.so.0]
  0x0000000000000001 (NEEDED)       Shared library: [libdisplay-info.so.3]
  0x0000000000000001 (NEEDED)       Shared library: [libudev.so.1]
  0x0000000000000001 (NEEDED)       Shared library: [libSPIRV-Tools.so]
  0x0000000000000001 (NEEDED)       Shared library: [libexpat.so.1]
  0x0000000000000001 (NEEDED)       Shared library: [libc++abi.so.1]
  0x000000000000000e (SONAME)       Library soname: [libvulkan_nouveau.so]
  0x000000000000001e (FLAGS)        SYMBOLIC BIND_NOW 
  0x000000006ffffffb (FLAGS_1)      NOW 
  0x0000000000000007 (RELA)         0x4cda8
  0x0000000000000008 (RELASZ)       720 (bytes)
  0x0000000000000009 (RELAENT)      24 (bytes)
  0x0000000000000024 (RELR)         0x4d078
  0x0000000000000023 (RELRSZ)       7440 (bytes)
  0x0000000000000025 (RELRENT)      8 (bytes)
  0x0000000000000017 (JMPREL)       0x4ed88
  0x0000000000000002 (PLTRELSZ)     2928 (bytes)
  0x0000000000000003 (PLTGOT)       0x10c5058
  0x0000000000000014 (PLTREL)       RELA
  0x0000000000000006 (SYMTAB)       0x2d0
  0x000000000000000b (SYMENT)       24 (bytes)
  0x0000000000000005 (STRTAB)       0x1a20c
  0x000000000000000a (STRSZ)        207766 (bytes)
  0x000000006ffffef5 (GNU_HASH)     0x14670
  0x0000000000000019 (INIT_ARRAY)   0x1050568
  0x000000000000001b (INIT_ARRAYSZ) 16 (bytes)
  0x000000000000001a (FINI_ARRAY)   0x1050578
  0x000000000000001c (FINI_ARRAYSZ) 8 (bytes)
  0x000000000000000c (INIT)         0x93c4c0
  0x000000000000000d (FINI)         0x93c4c3
  0x000000006ffffff0 (VERSYM)       0x12d68
  0x000000006ffffffe (VERNEED)      0x1464c
  0x000000006fffffff (VERNEEDNUM)   1
  0x0000000000000000 (NULL)         0x0

readelf -s /usr/lib/libvulkan_nouveau.so | grep malloc:

Code: Select all

  2021: 000000000101cf10   439 FUNC    GLOBAL DEFAULT    17 malloc_usable_size
  3097: 000000000101aff0     5 FUNC    WEAK   DEFAULT    17 malloc

I also looked at the link to the Bug you provided and read through it and therefore checked

Code: Select all

readelf -d /usr/lib/libvulkan_nouveau.so | grep libc.so

and

Code: Select all

readelf -s /usr/lib/libvulkan_nouveau.so | grep program_invocation_name

The first command returned nothing, the second

Code: Select all

   1935: 00000000010cc130     8 OBJECT  WEAK   DEFAULT    29 program_invocation_name

This reveals that it is statically linked to libc.a exactly like the bug describes. It seemed like its really the same bug or atleast very similar.

[GDH-gentoo]

It seemed like its really the same bug or atleast very similar.

Yes, I'm quite sure that what you are getting is a different manifestation of the same bug. That's unfortunate.

EDIT: It's exactly bug #970166, which sam_ marked as duplicate of #967728.

The outputs I requested are variations of the ones in the bug report:

Code: Select all

Dynamic section at offset 0x10c1270 contains 37 entries:
  Tag                Type           Name/Value
  0x0000000000000001 (NEEDED)       Shared library: [libdrm.so.2]
  0x0000000000000001 (NEEDED)       Shared library: [libz.so.1]
  0x0000000000000001 (NEEDED)       Shared library: [libzstd.so.1]
  0x0000000000000001 (NEEDED)       Shared library: [libwayland-client.so.0]
  0x0000000000000001 (NEEDED)       Shared library: [libdisplay-info.so.3]
  0x0000000000000001 (NEEDED)       Shared library: [libudev.so.1]
  0x0000000000000001 (NEEDED)       Shared library: [libSPIRV-Tools.so]
  0x0000000000000001 (NEEDED)       Shared library: [libexpat.so.1]
  0x0000000000000001 (NEEDED)       Shared library: [libc++abi.so.1]

libc.so should be there, but isn't. Therefore piping through grep should return nothing.

Code: Select all

  3097: 000000000101aff0     5 FUNC    WEAK   DEFAULT    17 malloc

Symbol malloc should be undefined in libvulkan_nouveau.so, just like program_invocation_name in the bug report. Because it is defined in libc.so.

This reveals that it is statically linked to libc.a exactly like the bug describes.

Agreed, and also explains the strange output of LLDB's bt command.

[Nima0908]

Alright, thank you very much. After deleting rusts bundled in libc.a and recompilling mesa it worked perfectly (although now my rust toolchain is completely broken XD).