You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
panic: panic
thread "main" (604503):
libbacktrace error: no debug info in ELF executable
libbacktrace error: no debug info in ELF executable
libbacktrace error: no debug info in ELF executable
libbacktrace error: no debug info in ELF executable
libbacktrace error: no debug info in ELF executable
note: looks like debug info is missing, try to recompile with `-g` flag
on both compilers (GCC and Clang). On ARM Mac this works as expected. Seems debug info is present in the executable as well
Reproduced on Ubuntu WSL machine(and I suspect it's the case on bare Windows machine also):
/mnt/c/dev/personal/spawn/thirdparty/libbacktrace$ uname -a
Linux B1Z0N 5.10.102.1-microsoft-standard-WSL2 #1 SMP Wed Mar 2 00:30:59 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
I checked the output with --showcc flag and the resulting command is using gcc with -g flag, which means it is working as intended:
Also when I check the out file with file command it shows:
/mnt/c/dev/personal/spawn$ file out
out: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=6e429c170ce4d28a4dcdfe98daad5bab1ebf6808, for GNU/Linux 3.2.0, with debug_info, not stripped
This is a good sign, specifically with debug_info, not stripped at the end. ELF debug symbols are here. Everything is working on this part.
Bugs candidates
Looked into it for a couple of hours and figured out that probably it has something to do with one of:
Outdated version of libbacktrace library - we use somewhat older files in our code. Perhaps something is fixed or updated already.
Specifically in darwin(macos) case, we have already pre-compiled libbacktrace library that is linked to the main executable here. Down below that line we are adding libbacktrace.c file to our compilation in case of non-darwin systems (linux, windows). Probably that's why such a difference in behavior.
Of course it can always be a mere bug in libbacktrace library. But the probability of this is undetermined. The library is highly used in top projects, which decreases the prob, but it is also very complex.
I also checked the API of this library and according to that our wrapper code must be ok.
Next
So if debug symbols are ok and our wrapper code is ok, the thing is probably in how we distribute the lib and which version of it we use in our project. With that I am going to look into the specific version of libbacktrace library that we use here and how we use it.
I'll be back with more updates.
UPD: I'm stuck with my Windows PC being really bad for building this libbacktrace library based on autotools. I'll switch to something more productive till I have UNIX system PC.
Reacted by Mykola Fedurko, Artem Yurchenko and Petr Makhnev
Activity
B1Z0N commentedon Apr 1, 2024
Reproduced
Reproduced on Ubuntu WSL machine(and I suspect it's the case on bare Windows machine also):
/mnt/c/dev/personal/spawn/thirdparty/libbacktrace$ uname -a Linux B1Z0N 5.10.102.1-microsoft-standard-WSL2 #1 SMP Wed Mar 2 00:30:59 UTC 2022 x86_64 x86_64 x86_64 GNU/LinuxI checked the output with
--showccflag and the resulting command is usinggccwith-gflag, which means it is working as intended:Also when I check the
outfile withfilecommand it shows:/mnt/c/dev/personal/spawn$ file out out: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=6e429c170ce4d28a4dcdfe98daad5bab1ebf6808, for GNU/Linux 3.2.0, with debug_info, not strippedThis is a good sign, specifically
with debug_info, not strippedat the end. ELF debug symbols are here. Everything is working on this part.Bugs candidates
Looked into it for a couple of hours and figured out that probably it has something to do with one of:
libbacktrace.cfile to our compilation in case of non-darwin systems (linux, windows). Probably that's why such a difference in behavior.I also checked the API of this library and according to that our wrapper code must be ok.
Next
So if debug symbols are ok and our wrapper code is ok, the thing is probably in how we distribute the lib and which version of it we use in our project. With that I am going to look into the specific version of libbacktrace library that we use here and how we use it.
I'll be back with more updates.
UPD: I'm stuck with my Windows PC being really bad for building this libbacktrace library based on autotools. I'll switch to something more productive till I have UNIX system PC.
ArtemkaKun commentedon Apr 1, 2024
Btw we have libbacktrace copy pasted from V repo, maybe we can handle this library and stuff in a better way or something
B1Z0N commentedon Apr 1, 2024
That's a precious part of info! I'll take a look at it.
i582 commentedon Apr 1, 2024
@B1Z0N great!