Date: Wed, 23 Oct 2002 07:46:44 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: djgpp-workers AT delorie DOT com Subject: Re: CBFalconer's malloc In-Reply-To: <3DB5D1E6.648F14BF@yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On Tue, 22 Oct 2002, CBFalconer wrote: > I still have to go for the .h files, nor have I looked for > malloc.txh. I'd really recommend to read malloc.txh before anything else, it will probably make many things clear. > Another useful thing would be an example of a > debugging package using all this. malldbg.c is such an example. > I have limited time, my wife > seems to be amazingly able to find things other than programming > for me to do :-) Well, that's something we all here are very familiar ;-) > > Another example is __libc_malloc_fail_hook, which, if points to > > something non-NULL, is called by malloc when it is about to fail the > > call. An application that sets up such a hook can later print how > > many allocations failed. __libc_malloc_hook is called whenever a > > block is returned to an application, and the info about that block is > > passed as arguments to the hook; this can be used to gather statistics > > about memory allocations. Etc., etc. > > > > malldbg.c uses these hooks to implement a simple malloc debugging > > and memory reporting package. > > How is that different from an external intercept (see the sample > xmalloc call above)? It is perfectly free to collect statistics > on the count of calls and the count of NULL returns. Maybe it isn't, I don't know. But the internal hooks are inherently more flexible since they can allow access to internal variables of the functions they hook.