malloc & friends hidden proto issues

Khem Raj raj.khem at gmail.com
Fri Jul 17 09:13:50 UTC 2009


On (17/07/09 10:45), Carmelo AMOROSO wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Khem Raj wrote:
> > On (17/07/09 10:19), Carmelo AMOROSO wrote:
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >> Khem Raj wrote:
> >>> On (17/07/09 07:36), Carmelo AMOROSO wrote:
> >>>> -----BEGIN PGP SIGNED MESSAGE-----
> >>>> Hash: SHA1
> >>>>
> >>>> Folks,
> >>>> 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 ?
> >> Hi Khem,
> >>> IMO when reimplementing malloc by applications, other functions referring to malloc in libc 
> >>> should also be reimplemented in terms of user defined malloc and free.
> >>>
> >> good point... but the application should know exactly which function has to be
> >> reimplemented.
> > 
> > yeah I would assume or they could track there own allocations and somehow their free
> > should be able to differentiate between libc free and non-libc free and redirect calls 
> > accordingly.
> > 
> > Thx
> > 
> > -Khem
> > 
> Anyway, glibc in this case behaves correctly. See an extract of the readelf -s below.
> As you can see, the strdup from uClibc (due the use of hidden_proto) is referencing
> the __GI_malloc while the glibc version is referring to the malloc.
> Interestingly all the other symbols (memcpy and strlen) are the hidden versions in both case.
> So it seems the glibc is ad hod treating differently the call to malloc, as it knew of a
> possible re-implementation.
> 
> 
> - --------- uClibc/libc/string/strdup.os  ---------
> 
>  [snip]
>     15: 00000000    96 FUNC    GLOBAL HIDDEN    1 __GI_strdup
>     16: 00000000     0 NOTYPE  GLOBAL DEFAULT  UND _GLOBAL_OFFSET_TABLE_
>     17: 00000000     0 NOTYPE  GLOBAL DEFAULT  UND __GI_strlen
>     18: 00000000     0 NOTYPE  GLOBAL DEFAULT  UND __GI_malloc
>     19: 00000000     0 NOTYPE  GLOBAL DEFAULT  UND __GI_memcpy
> 
> - --------- /glibc/objdir/string/strdup.os ---------
> 
> [snip]
>     19: 00000000    76 FUNC    GLOBAL HIDDEN    1 __GI___strdup
>     20: 00000000     0 NOTYPE  GLOBAL DEFAULT  UND _GLOBAL_OFFSET_TABLE_
>     21: 00000000     0 NOTYPE  GLOBAL DEFAULT  UND __GI_strlen
>     22: 00000000     0 NOTYPE  GLOBAL DEFAULT  UND malloc
>     23: 00000000     0 NOTYPE  GLOBAL DEFAULT  UND __GI_memcpy
>     24: 00000000    76 FUNC    GLOBAL DEFAULT    1 __strdup
>     25: 00000000    76 FUNC    WEAK   DEFAULT    1 strdup
> 
> what do you think ?

I think you should look at the disasm of strdup () in finally linked shared library
and see how malloc is resolved. btw. in my build even uclibc
(recent trunk on mips and older version of uclibc-nptl/arm) has malloc and not
__GI_malloc in symbol table

I have MALLOC_STANDARD=y in my config.



> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
> 
> iEYEARECAAYFAkpgOhoACgkQoRq/3BrK1s/nNgCgs7HDc4Xu3tsaWtJEj/vXp4co
> rxEAoMCPVJjBUIvZMI0G1lUAP//YuhBL
> =O4C5
> -----END PGP SIGNATURE-----
> _______________________________________________
> uClibc mailing list
> uClibc at uclibc.org
> http://lists.busybox.net/mailman/listinfo/uclibc


More information about the uClibc mailing list