Void Linux x64-musl Segfault

[13-05]

I have cloned the repo, and cloned vcpkg to install nlohmann-json. After installing nlohmann-json, i did the mkdir build && cd build, then i tried cmake ... This throws the following error:

CMake Error at /usr/share/cmake-3.22/Modules/FindPackageHandleStandardArgs.cmake:230 (message):
  Could NOT find nlohmann_json (missing: NLOHMANN_JSON_INCLUDE_DIR)
Call Stack (most recent call first):
  /usr/share/cmake-3.22/Modules/FindPackageHandleStandardArgs.cmake:594 (_FPHSA_FAILURE_MESSAGE)
  cmake/Findnlohmann_json.cmake:24 (find_package_handle_standard_args)
  CMakeLists.txt:12 (find_package)

Now, I moved the include directory for vcpkg/packages/nlohmann-json-* tons of places, but it still cant find nlohmann-json, and I don't know what else to do.

[ouwou]

i believe you would need to add -DCMAKE_TOOLCHAIN_FILE=[path to vcpkg]/scripts/buildsystems/vcpkg.cmake to your cmake command. you could also just install it directly from the repo which might be easier and is probably more likely to get picked up by the find module

[ghost]

alright, lemme try that

[ghost]

the executable provided in the readme is glibc linked, not musl linked, so it cant run on my system. i tried using gcompat to run it (compatibility layer for glibc executables for musl), but the executable requires glibc libcurl and i dont know how to get that easily

[ouwou]

well what happened to manually building it? i feel like thats probably easier than trying to run some compatibility layer over an executable that maybe shouldnt even be in the readme to begin with

[ghost]

yeah ill look more into manually building it, sorry got a little sidetracked with trying to run the executable. lemme try to build it from source

[ghost]

alright, built it, got a segfault, prolly a separate issue, ill open that when i feel like it prolly but it might just be my os thats not compatible with abaddon

[ouwou]

well it should work. feel free to open another issue i dont like when it crashes :^) someone had mystery segfaults when using clang to compile though. if you are using clang try gcc

[ghost]

i dont have clang installed, but ill see if i can find the specifics of why it crashed. when i get more info on it ill open a new issue

[ouwou]

try gdb and run bt when it crashes

[ghost]

alright, here's the output

Reading symbols from abaddon...
(gdb) run
Starting program: /home/outsider/development/abaddon/abaddon

Program received signal SIGSEGV, Segmentation fault.
__strchrnul (s=0x1 <error: Cannot access memory at address 0x1>, c=c@entry=59) at src/string/strchrnul.c:19
19	src/string/strchrnul.c: No such file or directory.
(gdb) bt
#0  __strchrnul (s=0x1 <error: Cannot access memory at address 0x1>, c=c@entry=59)
    at src/string/strchrnul.c:19
#1  0x00007ffff7fb2ef8 in strchr (s=<optimized out>, c=59) at src/string/strchr.c:5
#2  0x00007ffff5cfc5f5 in std::locale::_Impl::_Impl(char const*, unsigned long) ()
   from /lib/libstdc++.so.6
#3  0x00007ffff5cfcff5 in std::locale::locale(char const*) () from /lib/libstdc++.so.6
#4  0x00005555556270b4 in main ()

[ghost]

something something string library error?

[ouwou]

looks like something here. maybe a musl thing? accessing weird memory addresses looks really strange though. std::setlocale might be returning nullptr which std::locale::locale(const char*) doesnt like

[ghost]

yeah, i think you're right that it's a musl thing. super weird that musl in place of glibc lead to a segfault imo

[ouwou]

well it is sort of my fault for not checking the return value. but id like to make sure its handled properly. the locale stuff only really shows up when formatting message timestamps. do you know if musl can even handle that (specifically %X %x in strftime)?

[ghost]

hm alright. no, i dont know if musl can handle that, i've just installed void for the first time a few days ago; first time using something with musl. ill check tho

[ghost]

i ran the below code (compiled with g++ if that matters) to test %X%x (100% stole it):

#include <iostream>
#include <ctime>

int main() {
  time_t curr_time;
  tm * curr_tm;
  char date_string[100];
  char time_string[100];
  time(&curr_time);
  curr_tm = localtime(&curr_time);
	
  strftime(time_string, 50, "%X %x", curr_tm);

  std::cout << time_string << std::endl;
  return 0;
}

the output is this:

so, it seems like it can handle %X%x

[ouwou]

well i mean does it respect the system locale? like if you set the date/time as somewhere in europe will it change from mm/dd/yyyy to dd/mm/yyyy

[ghost]

hm, no. this is what happens when i set it to athens. changes the time and stuff but not the order

[ouwou]

thats localtime doing that. a little google seems to indicate theres no localization i guess so i dont think theres anything to be done with formatting timestamps

[ghost]

hm okay

[ouwou]

i think that should fix the crash. lmk if it doesnt

[ghost]

that's... weird. i compiled it and got the exact same segfault error as before. removed the old dir, cloned it again, redid the whole process, im not accidentally recompiling the old code. same exact error.

Reading symbols from abaddon...
(gdb) run
Starting program: /home/outsider/development/abaddon/abaddon

Program received signal SIGSEGV, Segmentation fault.
__strchrnul (s=0x1 <error: Cannot access memory at address 0x1>, c=c@entry=59) at src/string/strchrnul.c:19
19	src/string/strchrnul.c: No such file or directory.
(gdb) bt
#0  __strchrnul (s=0x1 <error: Cannot access memory at address 0x1>, c=c@entry=59)
    at src/string/strchrnul.c:19
#1  0x00007ffff7fb2ef8 in strchr (s=<optimized out>, c=59) at src/string/strchr.c:5
#2  0x00007ffff5cfc5f5 in std::locale::_Impl::_Impl(char const*, unsigned long) ()
   from /lib/libstdc++.so.6
#3  0x00007ffff5cfcff5 in std::locale::locale(char const*) () from /lib/libstdc++.so.6
#4  0x00005555556258cb in main ()

[ouwou]

maybe make sure you compile as debug and try and step through line by line to see exactly which line triggers it. ill have to look into it more tomorrow. maybe try compiling a simple program that tries to do std::locale("C")

[ghost]

alright, ill compile a sample program as debug and do that

[ghost]

there are tons of errors like this, dont know how to fix it. here's my test code:

#include <iostream>
#include <ctime>

int main() {
  std::cout << std::locale("C") << std::endl;
  return 0;
}

[ouwou]

try

#include <locale>

int main() {
    std::locale foo("C");
}

i think itd be more clear if you stepped line by line thru main which u can do with break main and next in gdb

[ghost]

yeahhh, idk. your above test code worked perfectly:

i'm pretty unfamiliar with gdb so bear with me here, but basically you want me to run abaddon line by line to determine where the issue is at?

[ouwou]

yeah basically. i thought gdb would automatically print line numbers anyways when you run bt. are you compiling in debug mode? maybe also add a puts(systemLocale); under this line just to see if it is in fact null or something else is going on

[ghost]

hey! sorry, i completely forgot about this. i did a lot of stuff, then started to get into memory hacking a little bit with gdb, then i remembered i used gdb for this, so now im back lol. just built abaddon, heres the output from stepping through line by line:

the issue's still there, obvs, but i think debugging made it somewhat clearer what it was? when i stepped through i noticed it got through most system locales no prob

BUT, the last success log before the segfault was this:

so, i guess it is a locale issue

[ghost]

#1  0x00007ffff7fb2ef8 in strchr (s=<optimized out>, c=59) at src/string/strchr.c:5
#2  0x00007ffff5cfc5f5 in std::locale::_Impl::_Impl(char const*, unsigned long) () from /lib/libstdc++.so.6
#3  0x00007ffff5cfcff5 in std::locale::locale(char const*) () from /lib/libstdc++.so.6
#4  0x000055555563c1c1 in main (argc=1, argv=0x7fffffffde78) at /home/outsider/development/abaddon/src/abaddon.cpp:947
#5  0x00007ffff7f6d70a in libc_start_main_stage2 (main=0x55555563c158 <main(int, char**)>, argc=1, argv=0x7fffffffde78) at src/env/__libc_start_main.c:94
#6  0x0000555555631516 in _start ()

heres the backtrace btw, it does have the line number (947) on the #4 part