in reply to Re^2: [Win32] "Free to wrong pool ..." error
in thread [Win32] "Free to wrong pool ..." error

The problem seems only to arise when it's the external library that allocates the memory.

That's (probably) because the external library is calling the C-runtime malloc(), but the XS code is calling the XS header redefined free() instead of the C-runtime one.

If you call malloc() from within XS code, that is also redefined to use a Perl header wrapper which means the perl malloc is called and it allocates the memory from it's internal pools (and probably tags it). So when you then call free() (the redefined version), it can check the tags (or cross reference the address or however it determines that it is "freeing from the wrong pool"), and everything matches up, so no message.

But when the memory was allocated in an external library (by the C-runtime), and you then attempt to free it from your XS code, the Perl memory management routines have no record of the address you are trying to free (as it didn't allocate it), so it issues the warning.

One possible answer is to create your own free() (just to confuse matters further:), and place it at the end of your XS/Inline C code. And #undef free before you call it. Something like: 

// Your inline C stuff here

...
// where you currently call free() call MyFree()
    MyFree( p );
...


void MyFree( void *p ) {
#undef free

    free( p );
}
//EOF

[download]
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

Replies are listed 'Best First'.
Re^4: [Win32] "Free to wrong pool ..." error
by syphilis (Archbishop) on Feb 10, 2009 at 05:45 UTC
    Yes - I think that makes sense, and I find that if I first #undef free, then I can successfully call free(). I wonder what sort of trouble one could get into by doing that. (I think I would prefer to use the external library's freeing routine, assuming such exists.)

    Further to ikegami's suggestion that this type of "Free to wrong pool..." error occurs with threaded perls (which I've since confirmed as correct for Win32), I decided to build a threaded perl on linux. But, on linux, there was no such error with either a "threaded" or "unthreaded" build of perl. As best I can tell, it's a Win32-only problem, but only if perl was built with threads capability.

    Thanks for the thoughts, guys - I appreciate your insight.

    Cheers,
    Rob
[reply]
[d/l]
[reply]
      I wonder what sort of trouble one could get into by doing that. (I think I would prefer to use the external library's freeing routine, assuming such exists.)

      I don't see that you would have any trouble doing that...provided you ensure that you only call the CRT_free() for those things allocated directly by the CRT_malloc(). If the external library concerned exports its own free() then obviously use that, as they might be doing something extra in there. But if they don't, you are in effect just providing access to the CRT_free().

      Reading Nick Clerk's post, I don;t think either of his proposals would help you here in as much as what he is suggesting is to ensure that the VMem class use perl mallloc et al., rather than the CRT's. Whilst that would (probably) help prevent many of the "free to wrong pool" messages generated by memory allocated & freed by perl, it wouldn't address your situation where an external library allocates the memory (via the CRT) and leaves the caller (you) to free it.

      IMO, the correct answer is for perl to not redefine the CRT calls, but rather define (and require all internal allocations use) its own distinct Perl_malloc()/Perl_free() etc. (which it of course already does), but not then redefine the CRT calls to use those. But that ship has already sailed. (Preprocessors are evil I say: EVIL! :)

      An alternative (which I hate, but that could be retro-fitted at this stage without too much effort), would be to define and expose CRT_malloc(), CRT_free() etc. in the header files. If this was done early enough in the chain, then they would be unaffected by later redefinitions and woudl allow you to call CRT_free() for your particular problem.

      In effect, that is what my hack does. It just gives you access to the CRT free() call--which is the only solution to the original problem.

      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
[d/l]

In Section Seekers of Perl Wisdom