Googling for "Free to wrong pool" shows that this error is specific to Perl, so your call to free() is calling Perl's own free() but surely your library isn't calling Perl's own malloc(). And my keen insight tells me that this is probably due to a C-preprocessor macro. So I chdir to perl/lib/CORE and "grep free *.h" and get:

XSUB.h:#    define free         PerlMem_free
[download]

which is unfortunate. Preventing XS routines from being able to easily choose which malloc system they want to use (Perl's or C's -- which are sometimes the same) is not the best idea.

In the meantime, you can "#undef free" before your call to free() to work around the problem (but don't use "free" any further down in your code, even indirectly via some other obscure C-preprocessor macro).

If I got the function pointer syntax right then something like this would be a workaround maybe?

void (perls_free)( void*p ) = &free;
#undef free

// free() should now refer to the crt free() and use perls_free() for 
+XS
[download]

Though the long term solution would be to remove the #define from the header file in favour of Safefree().

That said, the whole area of memory allocation functions and macro's in the Perl codebase is a mess. Sometime last year I did a not totally crude grep and eliminate duplicates process on the sources and discovered that between the 4 basic functions--malloc(), calloc(), realloc() & free()--there were (from memory) 114 different ways of calling them through the multiplicitous variations of functions and macros. It's truely amazing that there are many more memory problems than there are.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

I think you are missing a "*":

void (*perls_fre­e)( void*p ) = &free;
#undef free
[download]

But that still risks the second half of my warning:

(but don't use "free" any further down in your code, even indirectly via some other obscure C-preprocessor macro).

which seems rather difficult to avoid with any certainty given your assessment of the current messiness. :)

Update: BTW, I am aware that the "&" is "optional", but I consider this simply to be a mistake on the part of the ANSI C definers. (:

- tye        

Not easy indeed. None of the following work:

#define d a

#include <stdio.h>

void a() { printf("a\n"); }
void b() { printf("b\n"); }

int main() {
   a();
#define a b
   a();

   (*&a)();

   /* \a(); */

#define c a
   c();

   d();

   return 0;
}
[download]

Of course not. (: The C preprocessor is mostly just text substitution and is defined to not care about the order in which things are defined.

A more interesting case that also doesn't work is:

#include <stdio.h>

void flee(int i)     { printf("flee(%d)\n",i); }
void perlFlee(int i) { printf("perlFlee(%d)\n",i); }

int main()
{
   flee(1);
#define flee perlFlee
   flee(2);

#define _stitch(a,b) a ## b
#define Free(x) _stitch(fl,ee)( x )
   Free(3);

   return 0;
}
[download]

Which produces "perlFlee(3)" as its last line of output.

And this tenancity of the C preprocessor is why (at least when the idea of XS came about), there should have been (similar to several other changes that were made for similar reasons) a global s/\bfree\b/Perl_free/, and s/\bmalloc\b/Perl_malloc/g done to the Perl source code so "#define free..." could be eliminated (replaced with "#define Perl_free free" for some systems, of course).

- tye        

    To free an SV that you've created, call "SvREFCNT_dec(SV*)". Norma
+lly
    this call is not necessary (see "Reference Counts and Mortality").
[download]

addition to free memory out from external library, consult that library's logic. Perl do not uses external char*, it will copy its data into newly created SV

He's not asking about freeing the SV. He asking about freeing the string from which he created an SV.

Furthermore, SvREFCNT_dec should not be used here. Making the SV mortal (using sv_2mortal) will automatically free the SV at the end of the XSUB. Think of sv_2mortal as a delayed SvREFCNT_dec.

I am not a Windows expert, but if I remind correctly, there memory has to be released from the same library where it was allocated.

The api documentation states clearly:

The user is responsible for calling free() on the value.

and example C-programs call it and it works :-(

And it came to pass that in time the Great God Om spake unto Brutha, the Chosen One: "Psst!"
(Terry Pratchett, Small Gods)