|[4 earlier articles]|
|Re: Suggestions for C malloc debugging tool firstname.lastname@example.org (Philip Lijnzaad) (1997-01-12)|
|Re: Suggestions for C malloc debugging tool email@example.com (T.E.Dickey) (1997-01-12)|
|Re: Suggestions for C malloc debugging tool firstname.lastname@example.org (1997-01-12)|
|Re: Suggestions for C malloc debugging tool email@example.com (Charles Fiterman) (1997-01-12)|
|Re: Suggestions for C malloc debugging tool firstname.lastname@example.org (Harish Patil) (1997-01-22)|
|Re: Suggestions for C malloc debugging tool email@example.com (1997-01-25)|
|Re: Suggestions for C malloc debugging tool firstname.lastname@example.org (1997-01-25)|
|From:||email@example.com (Bob Mercier)|
|Date:||25 Jan 1997 22:11:54 -0500|
|Organization:||Cinenet Communications,Internet Access,Los Angeles;310-301-4500|
While not in the league of some of the other suggestions, I developed
a simple extension to malloc while debugging the X server several
years ago, and it proved invaluable to me.
I read the text symbols of the program at startup and save them away,
at each malloc allocate enough space for the user's buffer plus a
vector of unsigned longs for the text addresses of the backtrace all
the way to main. When I detect an error, duplicate free or SIGSEGV or
SIGBUS near an allocated block, I dump the symbolic backtrace of the
point of allocation, the point it was free'd and the current PC. When
you need this type of code there's nothing else that will work...
The x86 architecture makes this type of code easy to write as it's
easy to generate a backtrace on the fly. Other machines, mips/irix
for example, make this a little harder. Take a look at GNU's binutils
for an architecture-independant way to load the symbol table and
lookup up a symbol..
Return to the
Search the comp.compilers archives again.