backtrace/1784: GDB dynamically activated to perform stack tracebacks

[schaefer at r-t-s-inc dot com]

>Number:         1784
>Category:       backtrace
>Synopsis:       GDB dynamically activated to perform stack tracebacks
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Wed Sep 29 15:58:01 UTC 2004
>Closed-Date:
>Last-Modified:
>Originator:     Richard T. Schaefer
>Release:        unknown-1.0
>Organization:
>Environment:
All
>Description:
I was wondering if anyone had thought about using GDB as a shared library to be dynamically activated into an application to be able to do extensive tracebacks prior to aborting on things like segmentation faults and access violations ? 

I thought about creating a thread for gdb, initializing gdb, and telling it the thread to do a tracback on. I do not know if I can have GDB in the same process environment that I am trying to debug. I do not think PTRACE would work.  Considering gdb has remoting interfaces, would I be able to create a new communication environment that would communicate to itself ? Is this too much of a stretch for gdb ? 
>How-To-Repeat:

>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted: