|[4 earlier articles]|
|Re: Suggestions for C malloc debugging tool email@example.com (Philip Lijnzaad) (1997-01-12)|
|Re: Suggestions for C malloc debugging tool firstname.lastname@example.org (T.E.Dickey) (1997-01-12)|
|Re: Suggestions for C malloc debugging tool email@example.com (1997-01-12)|
|Re: Suggestions for C malloc debugging tool firstname.lastname@example.org (Charles Fiterman) (1997-01-12)|
|Re: Suggestions for C malloc debugging tool email@example.com (Harish Patil) (1997-01-22)|
|Re: Suggestions for C malloc debugging tool firstname.lastname@example.org (1997-01-25)|
|Re: Suggestions for C malloc debugging tool email@example.com (1997-01-25)|
|From:||firstname.lastname@example.org (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.