malloc & friends hidden proto issues

Mike Frysinger vapier at gentoo.org
Sun Jul 19 19:41:29 UTC 2009


On Friday 17 July 2009 01:36:37 Carmelo AMOROSO wrote:
> I've recently added for testing hidden_proto in {m,re,c}alloc functions to
> ensure that from within the libc we always called the hidden __GI_xxx
> symbols.
>
> Using this uClibc with firefox and bash I found a problem.
> Both bash and firefox provide a their own implementation of memory
> allocation functions (bash internally, firefox by libejmalloc.so).
>
> Because the dynamic linker will search undefined symbols firstly in the
> application, any reference to malloc/free functions will be resolved by the
> application's symbols.
>
> If we use the hidden_protos, calls to malloc/free from libc are resolved
> inside libc itslef at it is expected.
>
> Now we have getcwd and strdup that use malloc for allocate memory and
> return the pointer to the caller. This memory is after freed by the
> application, calling free(), that is not the libc one implementation,
> leading to error, sigbus and so on.
>
> Do you think it is wrong to use the hidden_protos for this class of
> functions, or we should think better at how internal symbols are actually
> used by uClibc ?

should figure out how glibc manages it and do something similar.  something 
like this seems to work under glibc (which is to say, glibc calls the local 
malloc() implementation):

#include <stdio.h>
#include <string.h>
void *malloc(size_t s) { printf("%s(%zu)\n", __func__, s); return NULL; }
void free(void *p) { printf("%s(%p)\n", __func__, p); }
main(int argc, char *argv[]) { free(strdup(argv[0])); }

i'll have to rebuild glibc locally with more debugging enabled to see how they 
do it, but it seems like their strdup() will call malloc() rather than the 
hidden alias.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.busybox.net/pipermail/uclibc/attachments/20090719/f2929827/attachment.pgp>


More information about the uClibc mailing list