[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH] ISSUE #3193 Fix peg revision parsing for CLI repository root relative urls.

From: Folker Schamel <schamel23_at_spinor.com>
Date: Wed, 28 May 2008 08:38:38 +0200

Troy Curtis Jr 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.

Yes, this is exactly what I ment.

>
> 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.

Very unlikely, right - but who really knows?
Especially in context of plugins of complex applications,
(which crash often enough)?

I mentioned it just because in my experience, users always do things
you never expect as API developer. And therefore I think that API
specifications should be 100% correct.
Never assume "no user will do that anyway...".

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:39:09 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.