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";
The problem seems only to arise when it's the external library that allocates the memory.
Cheers,
Rob | [reply]
[d/l]
[select] |
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
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]
[select] |
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] |