[PATCH] solib_open, memory leak

[msnyder@sonic.net]

>
> msnyder@sonic.net writes:
>> I hope it's not getting to be too late at night for me to do this
>> stuff...
>>
>> If I'm not spacy, solib_open is leaking memory, because openp passes
>> back
>> a malloc buffer for temp_pathname.  In order to free it, it has to
>> always
>> be a malloc buffer (hence no alloca etc).
>
> I think you were a little bit spacy.  :)
>
> Even if you've made sure that temp_pathname is malloc'd by the time we
> reach the 'open', any later 'openp' call will throw away its value.
> openp is careful to store *something* in the pointer referred to by
> its last argument, even on error.

Uhhh, yeah, you're right.


> I think the invariant should be that, when found_file becomes >= 0,
> then temp_pathname is malloc'd, and not before.  The 'openp' clauses
> will preserve that.  So I think you need:
>
>   if (found_file >= 0)
>     temp_pathname = xstrdup (temp_pathname);
>
> after the 'open'.
>
> And then there's no need for the xstrdup at the bottom; just return
> temp_pathname, or xfree it if the caller doesn't want it.

That sounds great, except for one thing (which I had also not addressed).

If openp receives an xmalloc'd temp_pathname, it will clobber it
without freeing it.


I'm thinking that openp will never use the buffer, only the pointer.
So rather than what you suggest, what if we AVOID xmalloc before
openp and just make sure that we pass openp a null pointer or a pointer
to memory that does not need to be freed (such as alloca).

Umm, thus:

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: solib_open.txt
URL: <http://sourceware.org/pipermail/gdb-patches/attachments/20070808/f1ae7080/attachment.txt>