This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

malloc_hook questions ...


Hi guys,

	I've recently been trying to use the glibc malloc hooks instead of an
LD_PRELOAD hack in my re-work of 'memprof', and a number of interesting
issues rear their heads.

	* trivial bug - the 'man malloc_hook' sample is missing a
	  '\n"' like this:

        /* `printf' might call `malloc', so protect it too. */
-           printf ("malloc(%u) called from %p returns %p0,
+           printf ("malloc(%u) called from %p returns %p0\n",
               (unsigned int) size, caller, result);


	* nastier bug:

		If I cut/paste the (fixed) sample, and compile it thus:
	gcc -shared -o /tmp/foo foo.c

		Then run it:
	LD_PRELOAD=/tmp/foo gedit

		I discover that gedit only (apparently) does 2 malloc calls ;-)

	malloc(5) called from 0xb6dfaf1e returns 0x80b60080
	malloc(352) called from 0xb6de8a7f returns 0x80b60180
	... [ nothing else ] ...

		This rather mirrors my experience in memprof where hooks
	appear to (randomly) stop working for no good reason. Any
	ideas ?


	* even nastier bug:

	I want to hook malloc and of course re-use the internal implementation
to generate full-stack based memory profiling data. My 1st cut at this
looked like this [ inspired by the man page example ].

+	pthread_mutex_lock (&hook_guard);
	__free_hook = old_free_hook;
	{
		free (ptr);
	}
	__free_hook = do_free;
+	pthread_mutex_unlock (&hook_guard);

	I'm trying to protect against other threads using the non-instrumented
version ;-)

	Naturally a moment's thought convinces you that this is not going to
work, since if __free_hook is 'old_free_hook' then you'll never hit the
pthread mutex lock anyway, and life will be bad: we'll randomly loose
(some) malloc/free/realloc/memaligns as we go along [ not good for the
tracking code ].

	So - in short: how can I re-use the glibc malloc functionality without
having to do this scary thread stuff ? [ __thread hooks would do it (at
some cost) I guess ]. Of course if the semantic was instead that in
__free_hook we could call 'old_free_hook' ourselves then life might be
better, but quite possibly I've just got confused.

	Help for the hopelessly ignorant appreciated :-)

	Thanks,

		Michael.

-- 
 michael.meeks@novell.com  <><, Pseudo Engineer, itinerant idiot



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]