debugging - Using gdb from inside process to get stack trace -
in code have runtime assert macro (let's call runtime_assert). should in multi threaded application.
when condition passed evaluated false, runtime_assert terminates program dumping stack trace , followed calling _exit().
as know, dumping stack trace isn't trivial task (how stack trace c++ using gcc line number information?).
the idea invoke gdb pid of process calling system().
- is idea in general? or it's better use process tools backtrace? (e.g. gcc
backtrace()/backtrace_symbols()) - when ptrace() invoked, somehow effect other threads?
- if system out of resources (e.g. memory/disk space) may gdb fork fail?
- how print stack trace of current thread only? (i can address of current method gcc backtrace())
- don't think idea - time
system()
done , gdb attaches other threads way beyond trouble point. don't think bothering stack trace worth in case (it might when give app "less-sophisticated" users , any info out of them useful). here i'dabort()
, have nice core file peruse. - i don't know if specified anywhere - suspicion it's os , thread library dependent (somebody please correct me if i'm wrong here).
- yes, might fail (same the core file though).
- i believe done via
gettid()
, gdb init-file , user-defined command trickery, again, don't think bother.
Comments
Post a Comment