Re: Producing memory traces of C storage allocation?

"Joachim Durchholz" <joachim_d@gmx.de>
2 Jul 2001 00:30:04 -0400

          From comp.compilers

Related articles
Producing memory traces of C storage allocation? ratatat@army.net (2001-06-28)
Re: Producing memory traces of C storage allocation? joachim_d@gmx.de (Joachim Durchholz) (2001-07-02)
Re: Producing memory traces of C storage allocation? graeme@epc.co.uk (Graeme Roy) (2001-07-02)
Re: Producing memory traces of C storage allocation? gneuner@dyn.com (2001-07-02)
Re: Producing memory traces of C storage allocation? frido@q-software-solutions.com (Friedrich Dominicus) (2001-07-17)
| List of all articles for this month |
From: "Joachim Durchholz" <joachim_d@gmx.de>
Newsgroups: comp.compilers
Date: 2 Jul 2001 00:30:04 -0400
Organization: Compilers Central
References: 01-06-065
Keywords: storage, C
Posted-Date: 02 Jul 2001 00:30:03 EDT

Corndog <ratatat@army.net> wrote:
> Hmm..this is quite the question Im sure, but does anyone know of a C
> compiler or is anyone able to tell me how to create one (roars of
> laughter) that is able to force the program being generated to log all
> calls to memory allocation routines like malloc and free in order for
> me to be able to determine the size of the heap at any point during
> the program execution? Or is there another simpler more intelligent
> way of doing it? Just writing wrappers for them doesnt work (I think)
> cos I wont intercept such calls by library routines.


This depends on the setup of the library routines and the linker.
I've worked with a compiler that has a debug version of malloc/free; all
inter-library calls to malloc/free will use these.
As for the intra-library calls: the debug library already uses the debug
versions of malloc/free, so no need to worry.


> I also know I can
> just write a separate program that will monitor the heap size of a
> target program, only doing it this way I cannot make any guarantees
> about the shape of the resulting graph cos I cant control the way the
> OS decides to interleave the execution of the two! Right?


You can give the monitoring thread a higher priority and let it sleep.
This is good for gathering general time-related memory statistics, but
it's difficult to relate that statistics to actions within the
application software.


You could also try a tool like BoundsChecker, which tries to trace
memory leaks. Checking tools like this can even work without explicit
debugging support compiled into the software, though I don't know how
they do this.


Regards,
Joachim


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.