-
Notifications
You must be signed in to change notification settings - Fork 4
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
no stacktrace shown when signalHandler called (eg SIGSEGV
)
#9
Comments
SIGSEGV
SIGSEGV
)
You're on to something here, but I wonder what makes libbacktrace encounter program counters that have no corresponding debugging info, in the middle of a stack trace. Function inlining? Something else? As for "t12012.nim", the problem is that both "NimMainModule()" and "fun()" are inlined into "main()", which we skip. Problem described upstream here: ianlancetaylor/libbacktrace#60 (comment) Fortunately, there is already a mechanism in place for dealing with these inlines, but it only covers Every env var and Nim/GCC option you discovered by reading the code is already documented in the README. Let me know if I missed something. Don't get too excited about "-fno-optimize-sibling-calls" - it disables the C compiler's tail-call optimisation, with serious performance hits in some programs. We can't do all that debuggers can and we're limited to the debugging info that libbacktrace passes to us, so no column info, if we want to keep it simple. |
I'm trying to get a stacktrace for nim-lang/Nim#17157:
details
main.nim: example from nim-lang/Nim#17157:
nim: 1.5.1 95697d00fa7e6f642c1e99b2baa4d76e468d1c77
nim-libbacktrace: 40be351
note 1
adding
--passc:"-fno-omit-frame-pointer -fno-optimize-sibling-calls"
didn't help. Note that this flag is useful in combination with optimized builds to get more complete stacktraces, however it didn't help here. It did help with the example in #5, a full stacktrace was obtained thanks to it even with -d:release or -d:danger. IMO we should mention this flag in docs for-d:nimStackTraceOverride
, at least if this issue can get fixednote 2
with -d:noSignalHandler i'll just get:
note 3
if i add
doAssert false
right before the place that causes SIGSEGV in compiler, it works:but then interestingly, it doesn't show:
on top, which also seems like a bug
without
--passc:"-fno-omit-frame-pointer -fno-optimize-sibling-calls"
it shows 25 frames instead of 29, which makes sense.So it looks like
SIGSEGV
(which triggers signal handler) causes the stacktraces to disappearnote 4
I'm not getting absolute paths even if I specify
--listfullpaths
or--excessivestacktrace
note 5: reduced example
nim r --stacktrace:on t12012.nim
nim r --stacktrace:off -d:nimStackTraceOverride --import:libbacktrace -g t12012.nim
note 6: lldb works
lldb t12012
(compiled as in note 5) does work and shows the relevant parts of the stacktraceso this seems like a bug in nim-libbacktrace
note 6
after instrumenting and playing with nim-libbacktrace code, i found
NIM_LIBBACKTRACE_DEBUG
, it turns out with this flag it works:NIM_LIBBACKTRACE_DEBUG=1 nim r -b:cpp --stacktrace:off -d:nimStackTraceOverride --import:libbacktrace -g -d:case5 -f $timn_D/tests/nim/all/t12012.nim
=> the relevant part of stacktrace is now shown:
so this is definitely a bug in nim-libbacktrace
note 7
going back to original example,
NIM_LIBBACKTRACE_DEBUG=1
makes it work.with nim compiled with:
--passc:"-fno-omit-frame-pointer -fno-optimize-sibling-calls" -d:danger
i get:
--passc:"-fno-omit-frame-pointer -fno-optimize-sibling-calls" -d:danger
i get 38 frames; notice the frames with line = 0; I'm curious whether we can report correct line numbers or whether that's the best we can do herenote that
--passc:"-fno-omit-frame-pointer -fno-optimize-sibling-calls" -d:danger
gives best of both worlds:-d:danger
(0.6s runtime up to the crash)note 8
with:
NIM_LIBBACKTRACE_DEBUG=1 lldb -- bin/nim.r10 c -d:case2 --lib:lib $timn_D/tests/nim/all/t12012.nim
I also get some line numbers being 0, so maybe there's the line info is unavailable for those frames:
note 9
what about column numbers? it should be available as shown in lldb stacktrace, so we should expose it instead of just showing line numbers
The text was updated successfully, but these errors were encountered: