#1 conflicting types for `__malloc_hook'

[Stefan Heimers]

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,

[Howard Chu]

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]

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]

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]

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...