#1 conflicting types for `__malloc_hook'

open
None
5
2002-03-07
2001-08-08
No

I am trying CVS version from August 8th, 2001

I had the same Problem with fnccheck-1.4

gcc -Wall -O3 -fPIC -DFNCCHK_USE_THREAD
-I/usr/local/include -I/usr/include -c fnclibmalloc.c
fnclibmalloc.c:81: conflicting types for
`__malloc_hook'
/usr/include/malloc.h:226: previous declaration of
`__malloc_hook'
fnclibmalloc.c:82: conflicting types for
`__realloc_hook'
/usr/include/malloc.h:229: previous declaration of
`__realloc_hook'
fnclibmalloc.c:83: conflicting types for `__free_hook'
/usr/include/malloc.h:224: previous declaration of
`__free_hook'
fnclibmalloc.c:84: conflicting types for
`__memalign_hook'
/usr/include/malloc.h:232: previous declaration of
`__memalign_hook'
make[2]: *** [fnclibmalloc.o] Error 1
make[2]: Leaving directory `/usr/src/fnccheck/src/lib'

Quick fix:

remove definitions in fnclibmalloc.c line 81 - 84

My System:

Debian Woody

troubadix:/usr/src/fnccheck# gcc -v
Reading specs from
/usr/lib/gcc-lib/i386-linux/2.95.3/specs
gcc version 2.95.3 20010315 (Debian release)

troubadix:/usr/src/fnccheck# /lib/libc.so.6
GNU C Library stable release version 2.2.3,

Discussion

  • Howard Chu

    Howard Chu - 2001-09-23

    Logged In: YES
    user_id=330860

    The malloc_hook's are very dependent on the version of
    glibc that you use. It looks like the definitions they used
    work well for glibc 2.1, I checked against glibc 2.1.3
    source. I built fnccheck on SuSE Linux 6 with glibc 2.0
    with no real hassles, but again the malloc_hook prototypes
    are different. (In glibc 2.0 they have one fewer argument,
    missing the caller's address. I worked around this by
    invoking gcc's __builtin_return_address in the hook
    functions.)

    Unfortunately I don't see a very consistent way of
    detecting which version of the malloc library is in use.
    I've made a simple patch that allows me to work with glibc
    2.0 or 2.1, but I haven't looked at glibc 2.2 yet. I also
    typedef'd those function pointers, it makes the rest of the
    declarations much simpler...

     
  • Johan Johansson

    Johan Johansson - 2001-11-16

    Logged In: YES
    user_id=117280

    Unfortunately it is not as easy to get it to compile as to
    #define away memory profiling since it among other things
    attempts to return a null pointer from a void function. I
    guess I could try to investigate the whole shebang.

     
  • Howard Chu

    Howard Chu - 2001-12-11

    Logged In: YES
    user_id=330860

    I've fixed this in my version of the code.
    The final argument to the hook functions just needs a const
    qualifier. e.g.

    typedef void * (mallfunc)(size_t, const void * caller);

    extern mallfunc *__malloc_hook;

    My patched code is available at
    http://highlandsun.com/hyc/fncchk15.tgz

     
  • Yannick Perret

    Yannick Perret - 2002-03-07

    Logged In: YES
    user_id=146450

    Yes. Classical error. In fact the malloc.h header changed in
    many ways since I wrote this part of fnccheck.

    In the current version (3.0) I first check the headers with
    'configure' in order to activate/desactivate memory hooks if
    the format is not the same.

    I don't know how to make a generic test...
    Maybe the best way would be that libc people create a common
    entry point to hooks, with no dependancies with the real
    functions, or to use varargs functions to allow future
    extentions without breaking the initial parameters...

     
  • Yannick Perret

    Yannick Perret - 2002-03-07
    • assigned_to: nobody --> hexasoft
     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks