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().

  1. is idea in general? or it's better use process tools backtrace? (e.g. gcc
    backtrace()/backtrace_symbols())
  2. when ptrace() invoked, somehow effect other threads?
  3. if system out of resources (e.g. memory/disk space) may gdb fork fail?
  4. how print stack trace of current thread only? (i can address of current method gcc backtrace())

  1. 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'd abort() , have nice core file peruse.
  2. i don't know if specified anywhere - suspicion it's os , thread library dependent (somebody please correct me if i'm wrong here).
  3. yes, might fail (same the core file though).
  4. i believe done via gettid() , gdb init-file , user-defined command trickery, again, don't think bother.

Comments

Popular posts from this blog

java - SNMP4J General Variable Binding Error -

windows - Python Service Installation - "Could not find PythonClass entry" -

Determine if a XmlNode is empty or null in C#? -