[SVN-3289] --enable-runtime-module-search: apr cleanup unloads libraries too early

• Type: Bug
• Status: Open
• Priority: Major
• Resolution: Unresolved
• Affects Version/s: 1.5.x
• Fix Version/s: unscheduled
• Component/s: unknown
• Assignee: Arfrever Frehtes Taifersar Arahesis
• Reporter: Martin von Gagern
• Created: 23/Sep/08 19:29
• Updated: 15/Mar/13 21:45

Description

This issue here hase come up on the mailing lists at least twice now:
http://subversion.tigris.org/servlets/BrowseList?list=dev&by=thread&from=653919
http://subversion.tigris.org/servlets/BrowseList?list=dev&by=thread&from=656592

To summarize:

The problem is that if svn has been configured with
--enable-runtime-module-search, in some cases (running git-svn) when the APR
cleanup (apr_terminate) cleans its pools (apr_pool_destroy), it will unload
shared libraries (libsvn_ra_neon-1.so.0) while there are still neon objects
around. When the cleanup tries to clean those, their cleanup function
(cleanup_session) is no longer available, which causes a segmentation fault.

I see two possible solutions. One is to have the APR cleanup code ensure that
libraries get unloaded only after all other objects from the current part of the
pool hierarchy have been cleaned. The other would be to have subversion pool
management restructured in some way, such that the DSO pool gets cleared after
the other objects.

I realize that fixing the issue properly might be a really hard thing to do, and
might probably involve major changes on the APR part as well. In that case, as
the issue had even been named a "showstopper" for 1.5.0 release in one of the
above threads, I suggest to mark the --enable-runtime-module-search
configuration flag as unsupported, experimental and known to break things.

http://subversion.tigris.org/servlets/BrowseList?list=dev&by=thread&from=656592