flightlessmango / MangoHud

A Vulkan and OpenGL overlay for monitoring FPS, temperatures, CPU/GPU load and more. Discord: https://discordapp.com/invite/Gj5YmBb
MIT License
6.52k stars 288 forks source link

Won't run when compiled with -D_GLIBCXX_ASSERTIONS #6

Closed guihkx closed 4 years ago

guihkx commented 4 years ago

FYI: You can safely disregard this issue if you wish, since by default MangoHud doesn't enable GCC hardening flags, such as -D_GLIBCXX_ASSERTIONS.

But I decided to report it here anyway, just in case. Quick background info: I'm building a Flatpak package for MangoHud. Currently, it can build both 64 and 32-bit libraries just fine, and they mostly work too (well, except for this error and the missing glxinfo binary in Flatpak).

However, the installation part is a problem at the moment. I have to manually copy the .so to whatever Flatpak app I want to use the HUD on (e.g. Steam, Lutris), due to some Flatpak restrictions. I'm still trying to find a solution to install MangoHud "globally".

Anyway, back to the issue. To build Flatpak apps we use flatpak-builder, and by default they enable these hardening flags in GCC (they can be bypassed though, that's why I said you can disregard this issue).

But a few commits ago, MangoHud was working just fine with the build made by flatpak-builder. Now, it fails to run with the following error:

$ env MANGOHUD=1 vkcube
/usr/include/c++/9.2.0/bits/stl_vector.h:1042: std::vector<_Tp, _Alloc>::reference std::vector<_Tp, _Alloc>::operator[](std::vector<_Tp, _Alloc>::size_type) [with _Tp = CPUData_; _Alloc = std::allocator<CPUData_>; std::vector<_Tp, _Alloc>::reference = CPUData_&; std::vector<_Tp, _Alloc>::size_type = long unsigned int]: Assertion '__builtin_expect(__n < this->size(), true)' failed.

I'm not a C/C++ programmer, so it was kinda difficult for me to find out where the error was coming from, especially because I have mango/lib32-mango installed here on Arch and they were working just fine. After some Googling, I tried to modify the PKGBUILD to include just the -D_GLIBCXX_ASSERTIONS flag and I've also disabled stripping the debug info from the binary.

Bingo! Here's what gdb tells me:

$ env MANGOHUD=1 gdb -quiet vkcube
Reading symbols from vkcube...
(No debugging symbols found in vkcube)
(gdb) r
Starting program: /usr/bin/vkcube 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
/usr/lib/../share/gcc-9.2.0/python/libstdcxx/v6/xmethods.py:731: SyntaxWarning: list indices must be integers or slices, not str; perhaps you missed a comma?
  refcounts = ['_M_refcount']['_M_pi']
/usr/include/c++/9.2.0/bits/stl_vector.h:1042: std::vector<_Tp, _Alloc>::reference std::vector<_Tp, _Alloc>::operator[](std::vector<_Tp, _Alloc>::size_type) [with _Tp = CPUData_; _Alloc = std::allocator<CPUData_>; std::vector<_Tp, _Alloc>::reference = CPUData_&; std::vector<_Tp, _Alloc>::size_type = long unsigned int]: Assertion '__builtin_expect(__n < this->size(), true)' failed.

Program received signal SIGABRT, Aborted.
0x00007ffff7c2df25 in raise () from /usr/lib/libc.so.6
(gdb) bt
#0  0x00007ffff7c2df25 in raise () from /usr/lib/libc.so.6
#1  0x00007ffff7c17897 in abort () from /usr/lib/libc.so.6
#2  0x00007ffff570c984 in std::__replacement_assert (__file=__file@entry=0x7ffff5787f98 "/usr/include/c++/9.2.0/bits/stl_vector.h", __line=__line@entry=1042, 
    __function=__function@entry=0x7ffff57b8890 "std::vector<_Tp, _Alloc>::reference std::vector<_Tp, _Alloc>::operator[](std::vector<_Tp, _Alloc>::size_type) [with _Tp = CPUData_; _Alloc = std::allocator<CPUData_>; std::vector<_Tp, _Alloc>::referen"..., __condition=__condition@entry=0x7ffff5787e58 "__builtin_expect(__n < this->size(), true)")
    at /usr/include/c++/9.2.0/x86_64-pc-linux-gnu/bits/c++config.h:463
#3  0x00007ffff570af17 in std::vector<CPUData_, std::allocator<CPUData_> >::operator[] (__n=4, this=0x7ffff57d7a08 <cpuStats+8>) at /usr/include/c++/9.2.0/bits/locale_facets.h:877
#4  CPUStats::UpdateCoreMhz (this=0x7ffff57d7a00 <cpuStats>) at ../../src/cpu.cpp:210
#5  0x00007ffff570b1bc in CPUStats::UpdateCPUData (this=0x7ffff57d7a00 <cpuStats>) at ../../src/cpu.cpp:150
#6  0x00007ffff570be3c in CPUStats::Init (this=0x7ffff57d7a00 <cpuStats>) at ../../src/cpu.cpp:143
#7  0x00007ffff570c124 in CPUStats::CPUStats (this=0x7ffff57d7a00 <cpuStats>) at ../../src/cpu.cpp:99
#8  0x00007ffff56f5158 in __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535) at ../../src/cpu.cpp:220
#9  _GLOBAL__sub_I_cpu.cpp(void) () at ../../src/cpu.cpp:220
#10 0x00007ffff7fe272a in call_init.part () from /lib64/ld-linux-x86-64.so.2
#11 0x00007ffff7fe2831 in _dl_init () from /lib64/ld-linux-x86-64.so.2
#12 0x00007ffff7fe6603 in dl_open_worker () from /lib64/ld-linux-x86-64.so.2
#13 0x00007ffff7d2bd79 in _dl_catch_exception () from /usr/lib/libc.so.6
#14 0x00007ffff7fe5eee in _dl_open () from /lib64/ld-linux-x86-64.so.2
#15 0x00007ffff7bdf34c in ?? () from /usr/lib/libdl.so.2
#16 0x00007ffff7d2bd79 in _dl_catch_exception () from /usr/lib/libc.so.6
#17 0x00007ffff7d2be13 in _dl_catch_error () from /usr/lib/libc.so.6
#18 0x00007ffff7bdfab9 in ?? () from /usr/lib/libdl.so.2
#19 0x00007ffff7bdf3da in dlopen () from /usr/lib/libdl.so.2
#20 0x00007ffff7de783c in ?? () from /usr/lib/libvulkan.so.1
#21 0x00007ffff7debe6e in vkCreateInstance () from /usr/lib/libvulkan.so.1
#22 0x00005555555576b5 in ?? ()
#23 0x00007ffff7c19153 in __libc_start_main () from /usr/lib/libc.so.6
#24 0x00005555555597ae in ?? ()

If you chose to fix this (but again, you don't have to), let me know if I can provide any other information.

Thanks.

jackun commented 4 years ago

Could you check jackun_wip branch? There might be some out-of-bounds errors lurking still.

guihkx commented 4 years ago

It's working!

image

Thank you very much. Feel free to close this issue anytime!

jackun commented 4 years ago

Is it easier to set the define with meson_options.txt? Can suggest a better name for the var too :D

guihkx commented 4 years ago

Is it easier to set the define with meson_options.txt?

I'll be honest, I'm not exactly sure what you mean by that. Judging by the file name, I'm assuming that's how you'd set the options for meson...? At least for Flatpak, setting an option is really easy.

We use a "special" YAML or JSON file, called the Flatpak manifest, which is used to automate the building and installation process of your app/extension (in this case, it's an extension to Steam, but it doesn't work yet). So, right now, I'm not changing any of the meson options.

This is how my Flatpak manifest looks like (it won't make much sense if you are not familiar with them, lol):

https://gist.github.com/guihkx/9abc2e4173bb42187077253260e9c342

Can suggest a better name for the var too :D

That name is fine, IMO :)

jackun commented 4 years ago

Hm, yeah, it's basically the same anyway https://mesonbuild.com/Build-options.html#using-build-options

telans commented 4 years ago

Closing as fixed