-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Show shared library paths for symbols without debug info #8534
Comments
We can. We must detect that the address is from a dynamic library, locate it, parse it (ELF, Mach-O, ...), extract and parse the DWARF information, then keep it loaded in memory. All that for source code that isn't on the computer and we don't have any control over. Unwinding and decoding the backtrace is already quite expensive. That's adding even more. Is it really worth it? |
Not worth it. You can use gdb if you really want to know that. |
Looking at the backtrace in gdb, it doesn't mention line numbers so it's possible it doesn't have DWARF sections to parse, so loading it might not use much RAM...It may be worth it "some day" just for accuracy sake, it might not slow down backtrace generation significantly and could add more information to some backtraces in certain instances... |
Oh, it merely identifies the loaded library file when the DWARF information isn't present. I guess it's possible. |
I think doing this might actually be confusing to a user. Users program in Crystal, they don't need to see the backtrack going to C functions. You don't see such thing in Ruby. So if we want to do something here we should probably hide the stack entries that point to C libraries. |
The current question marks are a little confusing too, and it's still useful to know it went (and returned from) a 3rd party lib. Maybe replace the |
I think its useful to know that the exception was raised inside a C function callback (doesn't happen often). Hiding such lines would hide it and possibly cause some headhache, until you try in GDB. |
moved to #7471 as somewhat requested |
This is a feature request for backtrace, not emitting debug info. |
#9209 may have clues |
We'll first make it output some "3rd party library" portions of the stacktrace:
Test program:
Linux 0.31.1:
Same thing in gdb:
It's able to detect which file it came from for those question mark lines.
OS X 0.31.1:
and gdb OS X:
Similarly missing filenames, though it has method names correctly in OS X.
The text was updated successfully, but these errors were encountered: