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

Did you try on a threaded linux build?

Good point that I hadn't thought of. I was thinking that the difference was one of Linux versus Win32, but I gather you're suggesting it's one of threaded vs unthreaded. My linux builds are unthreaded and my Win32 builds are threaded, so you could be (and most likely are) right.

As it turns out, I *do* have an unthreaded build of perl-5.10.0 on Win32 and, indeed, there's no problem with calling free(string) on that particular build. So it looks like it's an issue on threaded builds of perl *only*.

Sounds like this bypasses a redefinition of free by Inline::C

Not sure what I'm s'posed to deduce from that. The issue I was describing is a general XS issue and not something limited to Inline::C (but you probably knew that). And there's usually no problem with free() in XS/Inline::C if the memory is allocated with malloc(). For instance, there's no problem with the following (in either threaded or unthreaded perl):

use warnings;
use Inline C => <<'EOC';

#include <malloc.h>

void foo() {
     char * string;
     string = malloc(10 * sizeof(char));
     free(string);
}

EOC

foo();
print "All done without error\n";
[download]

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

Cheers,
Rob

Comment on Re^2: [Win32] "Free to wrong pool ..." error Select or Download Code

Replies are listed 'Best First'.
Re^3: [Win32] "Free to wrong pool ..." error by BrowserUk (Patriarch) on Feb 09, 2009 at 11:52 UTC
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."	[reply] [d/l] [select]
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]
Re^5: [Win32] "Free to wrong pool ..." error by ikegami (Patriarch) on Feb 10, 2009 at 06:25 UTC
I seem to remember Windows being rather singular in the memory allocation system it uses by default. Here's some related reading: banishing "free to wrong pool", and making Win32 faster? (Not a solution)	[reply]
Re^5: [Win32] "Free to wrong pool ..." error by BrowserUk (Patriarch) on Feb 10, 2009 at 14:39 UTC
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. "Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."	[reply] [d/l]