I'm seeing something on AIX 5.2 that's a new one on me. We have a toolset
that uses ptrace (a bit like a debugger), loads a library into the target
application on initialization, does a bunch of stuff and then detaches. From
AIX 4.2 to 5.1 this doesn't introduce anything weird (at least nothing we
don't deliberately do!) into the target application. With AIX 5.2, however,
I'm seeing that a different version of malloc is being called from the
application - namely malloc_y_heap.

On entry to our initialization routine in the shared library I can see that
the TOC entry for malloc points to the malloc in libc.a, exactly as
expected. However, after I call malloc, the TOC entry changes to point to
malloc_y_heap.

For instance, I put printf statements in before and after the call to
malloc. The second value shown is the address of the actual routine that
will be branched to:

malloc => 0xf0196a90 (0xd01df42c 0xf019da04)
< Here's where the malloc happens >
malloc => 0xf0196a90 (0xd01ea4c8 0xf019da04)

See how the address 0xd01df42c (which is the malloc routine in libc.a) has
changed to 0xd01ea4c8 (malloc_y_heap).


To some extent I don't care about this so long as it will always happen on
AIX 5.2 and isn't some random thing I should look into. Does anyone have any
light to throw on this?

Andy.

--
I'm not really here - it's just your warped imagination.

"Andy Platt" <ajp@turnip.his.com> wrote in message
news:3f8c4ba8$1@news101.his.com...
> I'm seeing something on AIX 5.2 that's a new one on me. We have a toolset
> that uses ptrace (a bit like a debugger), loads a library into the target
> application on initialization, does a bunch of stuff and then detaches.
From
> AIX 4.2 to 5.1 this doesn't introduce anything weird (at least nothing we
> don't deliberately do!) into the target application. With AIX 5.2,
however,
> I'm seeing that a different version of malloc is being called from the
> application - namely malloc_y_heap.

I should have tried a simpler testcase first. This always happens after the
first call to malloc anywhere. So a simple test program shows it:

---------------------------------
#include <stdio.h>

typedef unsigned long ap_Uint32;

static void dummy (void)
{
malloc (8);
}

void SeeWhatHappens (void)
{
printf ("malloc => 0x%08x (0x%08x 0x%08x)\n", malloc,
((ap_Uint32 *) malloc) [0],
((ap_Uint32 *) malloc) [1]);
malloc(4);
printf ("malloc => 0x%08x (0x%08x 0x%08x)\n", malloc,
((ap_Uint32 *) malloc) [0],
((ap_Uint32 *) malloc) [1]);
}

int main (int argc, char **argv)
{
SeeWhatHappens ();
return 0;
}
-------------------------------

cc -o testit.exe testit.c
../testit.exe
malloc => 0xf0196a90 (0xd01df42c 0xf019da04)
malloc => 0xf0196a90 (0xd01ea4c8 0xf019da04)


I guess my question remains. Will AIX 5.2 always use malloc_y_heap instead
of malloc? (BTW, it also changes free to free_y_heap, etc.).

Andy.

--
I'm not really here - it's just your warped imagination.

"Andy Platt" <ajp@turnip.his.com> wrote:

> > don't deliberately do!) into the target application. With AIX 5.2,
> however,
> > I'm seeing that a different version of malloc is being called from the
> > application - namely malloc_y_heap.

Looks like this is caused by the replacement malloc features documented in
the malloc manpage on AIX 5.2. That's all I really needed to know but
perhaps this thread will be useful to someone searching for the same thing
later!

Andy.

--
I'm not really here - it's just your warped imagination.