Crashing when enabled #1196

Kagukara · 2023-12-22T19:52:40Z

Just got an update for mangohud-git from the AUR, now whenever I press the keybind to enable or when no_display is commented out, it crashed the program/game.

$ mangohud glxgears
Running synchronized to the vertical refresh.  The framerate should be
approximately the same as the monitor refresh rate.
/usr/include/c++/13.2.1/bits/stl_vector.h:1125: std::vector<_Tp, _Alloc>::reference std::vector<_Tp, _Alloc>::operator[](size_type) [with _Tp = float; _Alloc = std::allocator<float>; reference = float&; size_type = long unsigned int]: Assertion '__n < this->size()' failed.
Aborted (core dumped)

Switching over to the non AUR package, programs/games do not crash.

List relevant hardware/software information

OS: Arch Linux
Mangohud Version: v0.7.1-rc1-2-g1d357e1
GPU: AMD Radeon RX 7900 XTX (radeonsi, navi31, LLVM 18.0.0, DRM 3.54, 6.6.7-arch1-1)
GPU Driver: 4.6 Mesa 24.0.0-devel (git-8023ede00a)

To Reproduce
Steps to reproduce the behavior:

run mangohud glxgears in the terminal
Enable mangohud with your keybind or if you have no_display commented out glxgears will crash.

Expected behavior
For the application to not crash and for MangoHud to show the statistics I want to see in the overlay.

The text was updated successfully, but these errors were encountered:

Adiker · 2023-12-22T23:05:08Z

I have the same issue, though sometimes MangoHud works and sometimes it doesn't. It throws the exact same error for me. It seems that it most often doesn't work right after boot and while waiting for some time, it eventually shows up and works.

flightlessmango · 2023-12-23T10:38:52Z

I haven't been able to reproduce this yet.
Are there any other details that might affect this?
Are you using any other config options?

Kagukara · 2023-12-23T11:13:10Z

Just tested this with no config in ~/.config/MangoHud/ and got no crash. Here is the config I use which I copied from the GitHub and edited a few days ago.

MangoHud.conf.tar.gz

I'll try and narrow down what is causing the crash.

Kagukara · 2023-12-23T11:18:44Z

I commented out all the gpu_* stuff saved ran mangohud glxgears, then un-commented saved reran mangohud glxgears and its no longer crashing. Have no idea whats going on, so the error I got above is the only clue as to why it was happening.

Adiker · 2023-12-23T13:25:43Z

I'd also like to help resolve this error. But it's very strange that it seems to appear and disappear randomly. I'd like to provide logs or anything that might be helpful.

CxLynx · 2023-12-28T08:27:02Z

I'm experiencing this when fps_metricsis enabled in config if I compile with LTO enabled with GCC. Enabling LTO with clang(16) is a compile fail. LTO disabled, everything seems to work fine with both compilers.

My config

EDIT I tested this compiling 2 times with both before posting this, and then after posting, 3rd time trying with GCC LTO it worked just fine. Either I'm wrong and my results were just coincidence, and/or it's randomly intermittent as stated above.
EDIT2 Well nevermind! The GCC LTO build broke again after a reboot. I won't be digging deeper into this for now

Adiker · 2023-12-28T13:20:49Z

I'm experiencing this when fps_metricsis enabled in config if I compile with LTO enabled with GCC. Enabling LTO with clang(16) is a compile fail. LTO disabled, everything seems to work fine with both compilers.

My config

EDIT I tested this compiling 2 times with both before posting this, and then after posting, 3rd time trying with GCC LTO it worked just fine. Either I'm wrong and my results were just coincidence, and/or it's randomly intermittent as stated above. EDIT2 Well nevermind! The GCC LTO build broke again after a reboot. I won't be digging deeper into this for now

Great findings ! I think AUR package builds with GCC and LTO enabled, so that might explain why MangoHud crashes. I can confirm this only happens with fps_metrics enabled though. It would be nice if you could share these findings on MangoHud AUR repository, so the maintainer would remove GCC LTO flag when building the package ? Unless something can be done with MangoHud own source code to fix these compiling problems.

Kagukara · 2023-12-28T23:14:34Z

I have been able to reproduce the crash. Using gamescope 3.13.16-1 and running mangohud gamescope glxgears then enabling mangohud with fps_metrics enabled in config (I have fps_metrics=avg,0.01,0.001 in my config).

Giving me the error I gave initially.

/usr/include/c++/13.2.1/bits/stl_vector.h:1125: std::vector<_Tp, _Alloc>::reference std::vector<_Tp, _Alloc>::operator[](size_type) [with _Tp = float; _Alloc = std::allocator<float>; reference = float&; size_type = long unsigned int]: Assertion '__n < this->size()' failed.
gamescope: children shut down!
(EE) failed to read Wayland events: Broken pipe

This caused the crash to happen 100% of the time. Commenting out fps_metrics in the config didn't cause a crash to happen.

Kagukara · 2023-12-28T23:18:31Z

Never mind doesn't happen 100% of the time. Somehow its no longer crashing with fps_metrics=avg,0.01,0.001 not commented out. All I did was remove avg,0.01,0.001 and save then re-added back the variables one by one and saved each time with glxgears still running.

Adiker · 2023-12-29T01:38:48Z

Never mind doesn't happen 100% of the time. Somehow its no longer crashing with fps_metrics=avg,0.01,0.001 not commented out. All I did was remove avg,0.01,0.001 and save then re-added back the variables one by one and saved each time with glxgears still running.

Yes, it doesn't happen all the time. It does happen almost always right after rebooting the system though. So definitely it's related to fps_metrics and GCC. Still, not sure what fix should be implemented here...

Actually, same as the OP, I'm also using Radeon GPU with Mesa. I'm curious if this crash also occurs on Nvidia or Intel GPUs.

Kagukara · 2023-12-29T11:48:22Z

I've been using the AUR version for a while now, which is now on version 0.7.1.rc1.r5.gc8c987d-1. I have fps_metrics=avg,0.01,0.001 set and it wasn't till yesterday when I downgraded gamescope that it crashed a few times before suddenly working again. I also tested it just after boot and had no crash.

MangoHud.conf.tar.gz

flightlessmango · 2023-12-29T12:03:57Z

Mangohud should not be used with gamescope, it's not supported and any crashes are unlikely to be fixed.
Instead you should use mangoapp

Adiker · 2023-12-29T12:08:43Z

Mangohud should not be used with gamescope, it's not supported and any crashes are unlikely to be fixed.
Instead you should use mangoapp

I'm not using gamescope and I still get the crashes. So it's definitely not related to gamescope.

Adiker · 2024-01-07T18:31:35Z

Are there any updates for this ? Still happens for me, fps_metrics enabled right after system reboot results in this error:
/usr/include/c++/13.2.1/bits/stl_vector.h:1125: std::vector<_Tp, _Alloc>::reference std::vector<_Tp, _Alloc>::operator[](size_type) [with _Tp = float; _Alloc = std::allocator<float>; reference = float&; size_type = long unsigned int]: Assertion '__n < this->size()' failed.

flightlessmango · 2024-01-07T21:09:46Z

I haven't been able to repro it.
It would be very useful if you could compile a debug version of mangohud and get a gdb back trace of the crash

Adiker · 2024-01-08T23:15:41Z

I built MangoHud as debugoptimized and captured a backtrace (running MangoHud with vkcube). I hope this could at least be a hint what's happening.
#0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44 #1 0x00007ffff79948a3 in __pthread_kill_internal (signo=6, threadid=<optimized out>) at pthread_kill.c:78 #2 0x00007ffff7944668 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 #3 0x00007ffff792c4b8 in __GI_abort () at abort.c:79 #4 0x00007fffebfa6d92 in ?? () from /usr/lib/mangohud/libMangoHud.so #5 0x00007fffebe76ad9 in ?? () from /usr/lib/mangohud/libMangoHud.so #6 0x00007fffebfe7ca3 in ?? () from /usr/lib/mangohud/libMangoHud.so #7 0x00007ffff79929eb in start_thread (arg=<optimized out>) at pthread_create.c:444 #8 0x00007ffff7a167cc in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78

Kagukara · 2024-01-17T21:14:26Z

Got round to running gdb for this issue of MangoHud which only crashes on a freshly booted PC, with either fps_metrics=avg,0.01 or fps_metrics=avg,0.01,0.001 set. Running mangohub vkcube to get the crash.

I'm not sure if this is the right way to use gdb but its how I was told in a past issue.

First I ran this in the terminal:

if ! grep -qi 'kernel.core_pattern' /etc/sysctl.conf; then
  sudo sh -c 'echo "kernel.core_pattern=core.%p.%u.%s.%e.%t" >> /etc/sysctl.conf'
  sudo sysctl -p
fi
ulimit -c unlimited

Then I ran mangohud vkcube which generated a file called core.2738.1000.6.vkcube.1705524812

Then I wasn't sure if this was correct but its what I did next:

$ gdb mangohud core.2738.1000.6.vkcube.1705524812 
GNU gdb (GDB) 13.2
Copyright (C) 2023 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-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
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"...
"/usr/bin/mangohud": not in executable format: file format not recognized

warning: Can't open file /memfd:xshmfence (deleted) during file-backed mapping note processing
[New LWP 2744]
[New LWP 2738]
[New LWP 2752]
[New LWP 2758]
[New LWP 2743]
[New LWP 2756]
[New LWP 2757]

This GDB supports auto-downloading debuginfo from the following URLs:
  <https://debuginfod.archlinux.org>
Enable debuginfod for this session? (y or [n]) y
Debuginfod has been enabled.
To make this setting permanent, add 'set debuginfod enabled on' to .gdbinit.
                                                                                              
warning: Section `.reg-xstate/2744' in core file too small.
Core was generated by `vkcube'.                                                               
Program terminated with signal SIGABRT, Aborted.

warning: Section `.reg-xstate/2744' in core file too small.
#0  0x000072f4ad1fe83c in ?? ()
[Current thread is 1 (LWP 2744)]
(gdb) bt
#0  0x000072f4ad1fe83c in ?? ()
#1  0x000072f49bdffcf0 in ?? ()
#2  0x60ca1d64e4d43800 in ?? ()
#3  0x0000000000000006 in ?? ()
#4  0x000072f49be006c0 in ?? ()
#5  0x000072f49bdffc70 in ?? ()
#6  0x000072f49bdffcf0 in ?? ()
#7  0x000072f49bdffd00 in ?? ()
#8  0x000072f4ad1ae668 in ?? ()
#9  0x000072f4ad349b50 in ?? ()
#10 0x000072f4ad1964b8 in ?? ()
#11 0x0000000000000020 in ?? ()
#12 0x000072f4a1085098 in ?? ()
#13 0x0000000000000465 in ?? ()
#14 0x000072f4a1087ad0 in ?? ()
#15 0x000072f49bdffeb0 in ?? ()
#16 0x000072f49bdffd70 in ?? ()
#17 0x0000000000000001 in ?? ()
#18 0x000072f49bdffd00 in ?? ()
#19 0x000072f49bdffbc0 in ?? ()
#20 0x000072f4a0fd6a35 in ?? ()
#21 0x000072f4a1099b13 in ?? ()
#22 0x0000000000000000 in ?? ()
(gdb)

Hope this helps.

EDIT: When I finished this comment I tried again with fps_metrics=avg,0.01,0.001 set and ran mangohud vkcube and it didn't crash. My systems uptime is 16 mins.

flightlessmango · 2024-01-17T22:33:59Z

@Adiker @Kagukara It looks like neither of you used a debug verison of mangohud, that's why it's showing ?? instead of methods in the code.
@Kagukara I'm not sure core dumps works properly with shared libraries like this, I would try running vkcube in gdb directly mangohud gdb vkcube

Adiker · 2024-01-17T23:04:44Z

#0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44 #1 0x00007ffff79948a3 in __pthread_kill_internal (signo=6, threadid=<optimized out>) at pthread_kill.c:78 #2 0x00007ffff7944668 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 #3 0x00007ffff792c4b8 in __GI_abort () at abort.c:79 #4 0x00007fffebfa7fc2 in ?? () from /usr/lib/mangohud/libMangoHud.so #5 0x00007fffebe77419 in ?? () from /usr/lib/mangohud/libMangoHud.so #6 0x00007fffebfe8ed3 in ?? () from /usr/lib/mangohud/libMangoHud.so #7 0x00007ffff79929eb in start_thread (arg=<optimized out>) at pthread_create.c:444 #8 0x00007ffff7a167cc in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78

This is with debug version of MangoHud, built with meson. Seems like output is still the same.

After writing the comment, exact same behavior as @Kagukara observed - MangoHud works fine without crashing, I think the crashing stops at around 10 minutes of system uptime.

flightlessmango · 2024-01-17T23:32:23Z

check what file /usr/lib/mangohud/libMangoHud.so returns, should say it has debuginfo

Kagukara · 2024-01-17T23:52:06Z

It looks like neither of you used a debug verison of mangohud, that's why it's showing ?? instead of methods in the code.

Ah, yea my bad. ~~Is compiling the debug version the same as what's in the README or is there something else I need to do?~~ Got it, ./build.sh build_dbg instead of ./build.sh build.

Also for gdb, do you want the same as before but with mangohud gdb vkcube or just mangohud gdb vkcube and do bt?

Kagukara · 2024-01-18T00:37:43Z

I have compiled with the debug version and gotten the gdb backtrace.

$ file /usr/lib/mangohud/lib64/libMangoHud.so 
/usr/lib/mangohud/lib64/libMangoHud.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=aec9ba43c44e72ca5f6982a9d42080557b973c49, with debug_info, not stripped

$ mangohud vkcube

/usr/include/c++/13.2.1/bits/stl_vector.h:1125: std::vector<_Tp, _Alloc>::reference std::vector<_Tp, _Alloc>::operator[](size_type) [with _Tp = float; _Alloc = std::allocator<float>; reference = float&; size_type = long unsigned int]: Assertion '__n < this->size()' failed.
Aborted (core dumped)

$ mangohud gdb vkcube

/usr/include/c++/13.2.1/bits/stl_vector.h:1125: std::vector<_Tp, _Alloc>::reference std::vector<_Tp, _Alloc>::operator[](size_type) [with _Tp = float; _Alloc = std::allocator<float>; reference = float&; size_type = long unsigned int]: Assertion '__n < this->size()' failed.

Thread 3 "vkcube" received signal SIGABRT, Aborted.
[Switching to Thread 0x7fffe9e006c0 (LWP 1675)]
__pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
44	     return INTERNAL_SYSCALL_ERROR_P (ret) ? INTERNAL_SYSCALL_ERRNO (ret) : 0;

(gdb) bt
#0  __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
#1  0x00007ffff74818a3 in __pthread_kill_internal (signo=6, threadid=<optimized out>) at pthread_kill.c:78
#2  0x00007ffff7431668 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#3  0x00007ffff74194b8 in __GI_abort () at abort.c:79
#4  0x00007fffeaff8b82 in std::__glibcxx_assert_fail(char const*, int, char const*, char const*) () from /usr/lib/mangohud/lib64/libMangoHud.so
#5  0x00007fffeaacc781 in std::vector<float, std::allocator<float> >::operator[] (this=0x7fffe9dffbf0, __n=18446744073709551615) at /usr/include/c++/13.2.1/bits/stl_vector.h:1125
#6  0x00007fffeaacb890 in fpsMetrics::calculate (this=0x5555556355a0) at ../../src/fps_metrics.h:73
#7  0x00007fffeaad8780 in std::__invoke_impl<void, void (fpsMetrics::*)(), fpsMetrics*> (
    __f=@0x55555564d760: (void (fpsMetrics::*)(fpsMetrics * const)) 0x7fffeaacb288 <fpsMetrics::calculate()>, __t=@0x55555564d758: 0x5555556355a0)
    at /usr/include/c++/13.2.1/bits/invoke.h:74
#8  0x00007fffeaad86df in std::__invoke<void (fpsMetrics::*)(), fpsMetrics*> (__fn=@0x55555564d760: (void (fpsMetrics::*)(fpsMetrics * const)) 0x7fffeaacb288 <fpsMetrics::calculate()>)
    at /usr/include/c++/13.2.1/bits/invoke.h:96
#9  0x00007fffeaad864f in std::thread::_Invoker<std::tuple<void (fpsMetrics::*)(), fpsMetrics*> >::_M_invoke<0ul, 1ul> (this=0x55555564d758)
    at /usr/include/c++/13.2.1/bits/std_thread.h:292
#10 0x00007fffeaad8608 in std::thread::_Invoker<std::tuple<void (fpsMetrics::*)(), fpsMetrics*> >::operator() (this=0x55555564d758) at /usr/include/c++/13.2.1/bits/std_thread.h:299
#11 0x00007fffeaad85ec in std::thread::_State_impl<std::thread::_Invoker<std::tuple<void (fpsMetrics::*)(), fpsMetrics*> > >::_M_run (this=0x55555564d750)
    at /usr/include/c++/13.2.1/bits/std_thread.h:244
#12 0x00007fffeb03ac93 in execute_native_thread_routine () from /usr/lib/mangohud/lib64/libMangoHud.so
#13 0x00007ffff747f9eb in start_thread (arg=<optimized out>) at pthread_create.c:444
#14 0x00007ffff75037cc in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78

Kagukara · 2024-01-18T00:42:41Z

Here is with mangohud gdb glxgears as well.

$ mangohud gdb glxgears

/usr/include/c++/13.2.1/bits/stl_vector.h:1125: std::vector<_Tp, _Alloc>::reference std::vector<_Tp, _Alloc>::operator[](size_type) [with _Tp = float; _Alloc = std::allocator<float>; reference = float&; size_type = long unsigned int]: Assertion '__n < this->size()' failed.

Thread 11 "glxgears" received signal SIGABRT, Aborted.
[Switching to Thread 0x7fffdb4006c0 (LWP 2990)]
__pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
44	     return INTERNAL_SYSCALL_ERROR_P (ret) ? INTERNAL_SYSCALL_ERRNO (ret) : 0;

(gdb) bt
#0  __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
#1  0x00007ffff73698a3 in __pthread_kill_internal (signo=6, threadid=<optimized out>) at pthread_kill.c:78
#2  0x00007ffff7319668 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#3  0x00007ffff73014b8 in __GI_abort () at abort.c:79
#4  0x00007ffff7be4d82 in std::__glibcxx_assert_fail(char const*, int, char const*, char const*) () from /usr/lib/mangohud/lib/libMangoHud_opengl.so
#5  0x00007ffff76c29f3 in std::vector<float, std::allocator<float> >::operator[] (this=0x7fffdb3ffbf0, __n=18446744073709551615) at /usr/include/c++/13.2.1/bits/stl_vector.h:1125
#6  0x00007ffff76c1202 in fpsMetrics::calculate (this=0x5555556449c0) at ../../src/fps_metrics.h:73
#7  0x00007ffff76d0014 in std::__invoke_impl<void, void (fpsMetrics::*)(), fpsMetrics*> (__f=@0x5555558122c0: (void (fpsMetrics::*)(fpsMetrics * const)) 0x7ffff76c0bfa <fpsMetrics::calculate()>, __t=@0x5555558122b8: 0x5555556449c0) at /usr/include/c++/13.2.1/bits/invoke.h:74
#8  0x00007ffff76cff73 in std::__invoke<void (fpsMetrics::*)(), fpsMetrics*> (__fn=@0x5555558122c0: (void (fpsMetrics::*)(fpsMetrics * const)) 0x7ffff76c0bfa <fpsMetrics::calculate()>) at /usr/include/c++/13.2.1/bits/invoke.h:96
#9  0x00007ffff76cfee3 in std::thread::_Invoker<std::tuple<void (fpsMetrics::*)(), fpsMetrics*> >::_M_invoke<0ul, 1ul> (this=0x5555558122b8) at /usr/include/c++/13.2.1/bits/std_thread.h:292
#10 0x00007ffff76cfe9c in std::thread::_Invoker<std::tuple<void (fpsMetrics::*)(), fpsMetrics*> >::operator() (this=0x5555558122b8) at /usr/include/c++/13.2.1/bits/std_thread.h:299
#11 0x00007ffff76cfe80 in std::thread::_State_impl<std::thread::_Invoker<std::tuple<void (fpsMetrics::*)(), fpsMetrics*> > >::_M_run (this=0x5555558122b0) at /usr/include/c++/13.2.1/bits/std_thread.h:244
#12 0x00007ffff7c26e93 in execute_native_thread_routine () from /usr/lib/mangohud/lib/libMangoHud_opengl.so
#13 0x00007ffff73679eb in start_thread (arg=<optimized out>) at pthread_create.c:444
#14 0x00007ffff73eb7cc in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78

This was the last time it crashed before it started working again (only did these two within the 10mins), uptime of 10mins.

flightlessmango · 2024-01-18T14:55:03Z

Does this fix the crash d4a66cc ?

Kagukara · 2024-01-18T15:03:10Z

Rebuilt with the commit, restarted PC and the fix seems to have fixed the crash. Thank you.

Adiker · 2024-01-18T15:08:41Z

I can confirm crash is also gone for me. Thanks !

Kagukara · 2024-01-18T15:12:54Z

Although now 0.01 and 0.001 do not work and only show 0fps, with 0.01 showing 1% and 0.001 showing nothing.

Kagukara · 2024-01-18T15:30:20Z

Now they start working, seems like after x amount of time like with the crash it starts to work as normal but this time it doesn't crash.

flightlessmango · 2024-01-18T23:56:47Z

it starts working after some time of mangohud running or the os running?

Kagukara · 2024-01-19T02:05:16Z

it starts working after some time of mangohud running or the os running?

After the OS running, like with the crash.

Turning on your PC, opening a terminal and running mangohud glxgears (toggling it on if needed) will result in MangoHud acting like this: #1196 (comment).

Kagukara · 2024-01-19T02:28:42Z

I've switched to sway version 1.9-dev-5fc85c50 (Jan 19 2024, branch 'master') from sway version 1.8.1, which has resulted in the GPU metrics not working as well in the overlay.

nvtop and amdgpu_top both show working GPU metrics.

[2024-01-19 02:24:02.462] [MANGOHUD] [error] [loader_nvml.cpp:42] Failed to open 64bit libnvidia-ml.so.1: libnvidia-ml.so.1: cannot open shared object file: No such file or directory
[2024-01-19 02:24:02.463] [MANGOHUD] [error] [nvml.cpp:45] Failed to load NVML
[2024-01-19 02:24:02.465] [MANGOHUD] [error] [nvctrl.cpp:56] XNVCtrl didn't find the correct display

I have rebuilt MangoHud debug but still get the same error. Building with -Dwith_xnvctrl=disabled gets:

[2024-01-19 02:33:29.904] [MANGOHUD] [error] [loader_nvml.cpp:42] Failed to open 64bit libnvidia-ml.so.1: libnvidia-ml.so.1: cannot open shared object file: No such file or directory
[2024-01-19 02:33:29.904] [MANGOHUD] [error] [nvml.cpp:45] Failed to load NVML

I have left mangohud glxgears running for 10 mins of system uptime, toggling the overlay didn't do anything to make it work. When exiting glxgears and rerunning the command MangoHud now shows the fps_metrics for 0.01 and 0.001 working.

The GPU metrics not showing was to do with sway-git/xwayland.

Kagukara · 2024-01-19T02:43:10Z

Retested but running mangohud glxgears every minuet, and 0.01, 0.001 for fps_metrics in the overlay started working at Uptime: 10 mins

flightlessmango · 2024-01-19T18:57:36Z

This should hopefully resolve the issue 3cee6f1

flightlessmango · 2024-01-19T19:03:47Z

As for the NVML issue, double check that you actually have nvidia drivers for the architecture the application is

Kagukara · 2024-01-19T19:20:14Z

As for the NVML issue, double check that you actually have nvidia drivers for the architecture the application is

It was because of sway-git, I got this when running vkcube

Selected GPU 0: AMD Radeon RX 7900 XTX (RADV NAVI31), type: DiscreteGpu
vulkan: No DRI3 support detected - required for presentation
Note: you can probably enable DRI3 in your Xorg config
vulkan: No DRI3 support detected - required for presentation
Note: you can probably enable DRI3 in your Xorg config
vulkan: No DRI3 support detected - required for presentation
Note: you can probably enable DRI3 in your Xorg config
Could not find both graphics and present queues

Also got this as well:

$ glxinfo | grep -iE 'device:|OpenGL version string:'
DRI3 not available
failed to load driver: zink
    Device: llvmpipe (LLVM 18.0.0, 256 bits) (0xffffffff)
OpenGL version string: 4.5 (Compatibility Profile) Mesa 24.1.0-devel (git-30e09d0e98)

Looks like it had to do with swaywm/sway#7897 and/or swaywm/sway#7910?

Kagukara · 2024-01-19T19:26:16Z

This should hopefully resolve the issue 3cee6f1

That seems to have fixed the problem. Thank you.

Kagukara closed this as completed Jan 19, 2024

Crashing when enabled #1196

Crashing when enabled #1196

Comments

Kagukara commented Dec 22, 2023

Adiker commented Dec 22, 2023 • edited Loading

flightlessmango commented Dec 23, 2023

Kagukara commented Dec 23, 2023

Kagukara commented Dec 23, 2023 • edited Loading

Adiker commented Dec 23, 2023

CxLynx commented Dec 28, 2023 • edited Loading

Adiker commented Dec 28, 2023

Kagukara commented Dec 28, 2023 • edited Loading

Kagukara commented Dec 28, 2023 • edited Loading

Adiker commented Dec 29, 2023 • edited Loading

Kagukara commented Dec 29, 2023

flightlessmango commented Dec 29, 2023

Adiker commented Dec 29, 2023

Adiker commented Jan 7, 2024

flightlessmango commented Jan 7, 2024

Adiker commented Jan 8, 2024 • edited Loading

Kagukara commented Jan 17, 2024 • edited Loading

flightlessmango commented Jan 17, 2024

Adiker commented Jan 17, 2024 • edited Loading

flightlessmango commented Jan 17, 2024

Kagukara commented Jan 17, 2024 • edited Loading

Kagukara commented Jan 18, 2024

Kagukara commented Jan 18, 2024 • edited Loading

flightlessmango commented Jan 18, 2024

Kagukara commented Jan 18, 2024

Adiker commented Jan 18, 2024

Kagukara commented Jan 18, 2024 • edited Loading

Kagukara commented Jan 18, 2024

flightlessmango commented Jan 18, 2024

Kagukara commented Jan 19, 2024 • edited Loading

Kagukara commented Jan 19, 2024 • edited Loading

Kagukara commented Jan 19, 2024

flightlessmango commented Jan 19, 2024

flightlessmango commented Jan 19, 2024

Kagukara commented Jan 19, 2024 • edited Loading

Kagukara commented Jan 19, 2024 • edited Loading

Adiker commented Dec 22, 2023 •

edited

Loading

Kagukara commented Dec 23, 2023 •

edited

Loading

CxLynx commented Dec 28, 2023 •

edited

Loading

Kagukara commented Dec 28, 2023 •

edited

Loading

Kagukara commented Dec 28, 2023 •

edited

Loading

Adiker commented Dec 29, 2023 •

edited

Loading

Adiker commented Jan 8, 2024 •

edited

Loading

Kagukara commented Jan 17, 2024 •

edited

Loading

Adiker commented Jan 17, 2024 •

edited

Loading

Kagukara commented Jan 17, 2024 •

edited

Loading

Kagukara commented Jan 18, 2024 •

edited

Loading

Kagukara commented Jan 18, 2024 •

edited

Loading

Kagukara commented Jan 19, 2024 •

edited

Loading

Kagukara commented Jan 19, 2024 •

edited

Loading

Kagukara commented Jan 19, 2024 •

edited

Loading

Kagukara commented Jan 19, 2024 •

edited

Loading