It's most likely not a problem with using the "right" or "wrong" malloc function. It sounds more like you're freeing memory outside of where it's being allocated. For example, something gets allocated with the libc malloc() but gets freed with the perl PerlMem_free(). This is an issue for more than just perl extensions... anytime you use a library that might have been linked with a debugging memory allocator you can encounter this. The rule of thumb is that you free memory in the same module you used to allocate it. That is, if you have a C library which exports a function like:

char* my_crappy_strdup( const char* str ) {
   char* s = malloc(strlen(str)+1);
   memcpy( s, str, strlen(str)+1 );
   return s;
}
[download]

Then you also need to provide, in the same source file:

void my_crappy_free( char* str ) {
   free(s);
}
[download]

And make sure that the caller of my_crappy_strdup() knows that they need to call my_crappy_free() on whatever data is created. Then it doesn't matter if that C library is using perl's memory manager, ElectricFence, libc, or whatever. One of the interesting consequences of this, by the way, is that it's basically impossible to use libc's strdup() in perl extensions without some nasty #define magic because you'll never be able to get at the libc free() call... c.