-
Notifications
You must be signed in to change notification settings - Fork 0
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
combine nim classic stacktrace with C++ backtraces to get full backtrace + other TODO's regarding nimStackTraceOverride
#49
Comments
I don't think that combining them is desirable, from the point of view of performance. Let's look at their respective problems: Default stack tracing:
libbacktrace alternative:
I don't think file path length is something we can blame on libbacktrace. Those paths are injected in the debugging section by So I propose we focus on getting the libbacktrace version feature-complete by letting it extract stack traces from exceptions. Maybe with something dumb but cheap like storing the output of stackTraceOverrideGetTraceback() in the Exception object. As a separate goal, clarify how file paths present in libbacktrace's output are generated and controlled. |
I should've been clear, I mean to give an option for combining (off by default);
even with
no, just --stacktrace:on, which can be combined with -d:danger for eg
do you mean a nim exception? these stacktraces are generated only --stacktrace:on which instruments cgen'd code by adding nimFrame/popFrame; so fixing ting would indeed require the combining I was mentioning
for some reason re-running my old command shows a different result today, using latest nim devel cb0f7c5 --excessivestacktrace is now honored but --excessivestacktrace:off is now buggy, see |
Won't it be overridden here? https://github.com/nim-lang/Nim/blob/b6924383df63c91f0ad6baf63d0b1aa84f9329b7/config/nim.cfg#L73
Yes, for https://nim-lang.org/docs/system.html#getStackTrace%2Cref.Exception
I hope not. I want the feature without that overhead. |
no, see for yourself with: proc main() = doAssert false
main() in fact, -d:danger --stacktrace:on is quite useful in some situations
but I'm arguing there should be a way for user to have that, as an option: Nim standard stacktraces enable things that are impossible with libbacktrace stacktraces, such as:
for the 2nd point, some debuggers (eg lldb) show the inlined procs as |
OK. We'll have to complicate the logic in "system/excpt.nim". How would we avoid any stack tracing duplication? You only want to use libbacktrace in non-Nim code, right? How do we do that? |
nimStackTraceOverride
the simplest, way, 100% robust is via address comparison:
notenot yet sure how to get addresses of frames via libbacktrace but it should be exposed somewhere; eg with the simpler alternative based on string comparisonan alternative, but not sure if it's 100% robust, would be doing it from string comparison of generated stacktrace locations, so that:
would deduplicate to:
other example, in the case
would also deduplicate to:
so it seems to work in all cases but that assumes we can match exactly file/line info bw debug info (libbacktrace) and nimFrame data (standard backtrace); hopefully ok since we are in control of debug info generated |
nimStackTraceOverride
nimStackTraceOverride
/cc @stefantalpalaru what do you think of this?
-d:nativeStackTrace
itself, i couldn't make it workproc getBacktrace*(): string {.noinline.}
could be more efficient see [performance]proc getBacktrace*(): string {.noinline.}
should reuse input buffer status-im/nim-libbacktrace#3--excessivestacktrace
, eg i got some non-absplute paths shown eg:EDIT: seems to work now for some reason
[EDIT]: --excessivestacktrace:off buggy
retried today, now I'm seeing a different behavior:
/Users/timothee/git_clone/nim/Nim_prs/t10308.nim
is not a real path, it's a concatenation of cwd/Users/timothee/git_clone/nim/Nim_prs
and the main project filet10308.nim
note
to get override stacktrace use:
links
--stacktrace:inline
, and--ignoreInline
nim-lang/RFCs#198D20200304T034657
The text was updated successfully, but these errors were encountered: