On 8/8/07, via RT chromatic <[EMAIL PROTECTED]> wrote:
> # New Ticket Created by chromatic
> # Please include the string: [perl #44499]
> # in the subject line of all future correspondence about this issue.
> # <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=44499 >
>
>
> The string_from_cstring() function has a slight flaw, in that it has to
> allocate a piece of memory and create a C-style string from a nice happy
> STRING. It's the responsibility of the caller to discard the C string
> appropriately.
>
> This is tricky if that string immediately gets passed to real_exception() or
> some other C function which does not return control; there's no chance to
> free the string with string_cstring_free().
>
> One solution is to use pointer tagging to mark pointers passed to
> real_exception() and the like as freeable. However, that means scanning them
> and getting their types right with regard to varargs and ow the hurting.
>
> Another option is to cache the C string in the STRING structure itself in the
> same way that Perl 5 caches IVs and NVs and PVs in the SV structure. (If
> that doesn't mean anything to you, congratulations. I have this little
> throbbing right behind my left eyeball just typing that.)
>
> In other words, pin the lifetime of the malloced memory to the lifetime of a
> garbage collected entity.
>
> Obviously it's necessary to free the C string when destroying the string
> (that's the point!) and it's necessary to free it and NULL out the pointer
> when the string's contents change, but this would get rid of a memory leak
> and, in the case of strings often converted to C strings, could improve
> performance. (It also simplifies a problem in certain NCI calls that I
> really don't want to get into.)
>
> Though I hate to admit it, I think one of the pointers in the the PObj union
> might work for this.
>
> -- c
What about a real_exception variant that accepts STRING*'s as arguments?
On the other hand, as you said, there will be other functions which
don't return control (functions that call real_exception etc.). But
then char* is not the only problem, any malloced data can leak.
void f() {
void* leaked = malloc(n);
do_something(leaked); // does not come back
free(leaked);
}
void do_something(void*) {
something_else();
}
void something_else() {
if(condition) real_exception();
}
--
Mehmet
