David Glasser wrote:
> On Tue, May 27, 2008 at 8:55 AM, Troy Curtis Jr <troycurtisjr_at_gmail.com> wrote:
>> On Tue, May 27, 2008 at 10:39 AM, Karl Fogel <kfogel_at_red-bean.com> wrote:
>>> "Troy Curtis Jr" <troycurtisjr_at_gmail.com> writes:
>>>> I interpret his question as this: Is it possible that the pool the
>>>> returned array is in can be destroyed sometime after the dll
>>>> containing the static string is unloaded, and that a caller might try
>>>> to access the static string location after the dll is unloaded but
>>>> before the pool is destroyed.
>>>>
>>>> I still think the answer is likely that it doesn't matter, but I don't
>>>> know the details of the subversion dll loading/unloading procedures.
>>> I don't understand this line of questioning at all, I have to admit.
>>> What does the static string have to do with anything pool-related? Why
>>> is the static string even coming up as an issue in the same sentence
>>> with "pool"? :-) It's not allocated in the pool. It has nothing to do
>>> with the pool. We could allocate and destroy pools all day long and it
>>> would never affect that static string in the slightest...
>>>
>> Contrived illustration:
>>
>> - Caller loads dynamic library "libfoo"
>> - Caller calls a function in "libfoo" which returns an string which
>> the doc string (or his interpretation of it) claims is allocated in
>> the given pool (but it turns out it is a pointer to a static string,
>> as in our case)
>> - Now that caller is done with the function it needed in "libfoo", so
>> it unloads it (and presumably the static string memory location is
>> unmapped. This may not be the case as I don't really know much about
>> the way dynamic libraries work with static allocations)
>> - Now the caller is ready to use the returned string, but that memory
>> location is no longer mapped and you get a segfault (I think). It
>> does this because it thinks everything is in the pool it provided, and
>> it has not destroyed that pool yet, and so assumes the memory will
>> still be valid.
>>
>> Now I don't know too much about Subversion's use of it's libraries,
>> but I highly doubt that the caller of these libraries will unload the
>> libsvn_subr library and then try to process the returned string.
>>
>> All that said, I could be completely wrong on my interpretation of the
>> question, and on where the static locations are for DLLs.
>
> In practice, you just don't unload svn libraries.
There's a difference between "the API spec does not allow it"
and "it's allowed, but I don't think any user will do that".
As mentioned, in my experience, API users always do things you never expect.
>
> In any case, we're not going to go and add apr_pstrdup's around every
> single string constant in Subversion!
Its not about every constant string, its just about constant strings
directly returned by API functions.
Alternatively, you might just add one global sentence to the API spec
saying basically that the lifetime of returned strings is not only
limited by pool lifetimes, but also by library lifetimes.
Folker
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-05-28 08:42:42 CEST