On 12 February 2015 at 16:48, Branko Čibej <br...@wandisco.com> wrote:
> On 12.02.2015 14:17, Philip Martin wrote:
>> Ivan Zhakov <i...@visualsvn.com> writes:
>>
>>> Multi-threaded application that didn't call svn_dso_initialize2()
>>> before creating any other pools will fail anyway under some
>>> circumstances. The problem with cleanup handles, not with concurrent
>>> initialization.
>> Perhaps we could fix the problem (for recent APR) by using an unmanged
>> pool. I'm not sure how we would arrange for such a pool to be cleaned
>> up, would an atexit handler work? Or perhaps we just accept the leak?
>
> A planned leak at process exit isn't really a leak. DSOs should never be
> unloaded anyway, there are too many intertwined dependencies to try to
> unravel them all.
>
Currently, svn_dso_load() loads all modules in DSO_POOL which is
created in svn_dso_initialize2(). DSO modules will be unloaded once
DSO_POOL is destroyed: the apr_dso_load() requires POOL argument to
load DSO module.
Than imagine the following pretty valid use case:
1. Application creates some root pool (POOL1)
2. Calls svn_fs_open("repos", POOL1)
2.1 svn_fs_open() implementation calls svn_dso_load() to load DSO
module with FS-library implementation.
2.2. svn_dso_load() calls svn_dso_intialize2() since it is not
intialized yet
2.3 svn_dso_initialize2 creates second root pool (DSO_POOL) and
uses this pool to load DSO module
3. Application uses FS
4. Application exits, without destroying it's root pool (POOL1).
Instead it calls apr_terminate() which destroy root pools in reverse
order:
4.1. DSO_POOL destroyed and all DSO modules are unloaded.
** At this point the code with FS-implementation is unloaded
from address space **
4.2. Then POOL1 is destroyed and some cleanup handlers registered
by FS-library is called: BOOM -- the code is already unloaded at 4.1
(in the multi-threaded application situation become worse, but harder
to reproduce. Heisenbugs guaranteed)
Please understand my correctly: I'll be glad see Subversion doesn't
require single-thread initialize functions, but I don't see how is it
possible in reliable way. Currently the only reliable solution is to
call svn_dso_initialize2() as first call after apr_initialize().
--
Ivan Zhakov
