apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ruediger Pluem <rpl...@apache.org>
Subject Re: Problems with DSOs and Pools
Date Mon, 14 Aug 2006 20:07:09 GMT

On 08/11/2006 06:42 PM, Garrett Rooney wrote:
> We've been fighting with some DSO/Pool related bugs in Subversion
> lately, and have basically come to the conclusion that there's no good
> solution, or at least no good solution that doesn't involve patching
> APR itself.
> The problem, in short, is that when you use a pool to load a DSO you
> need to make sure that the pool lives longer than any code that might
> call a function within the DSO.  This is simple enough with most
> things, but when the code inside the DSO makes use of pools,

But there are still some other pitfalls. I faced one with an older subversion
version (1.2.3). Destroying the pool used to load the dso causes the dso to be
unloaded. But during the usage of the dso pointers to string literals inside the dso
had been saved. These pointers got used later and caused the subversion client to
SIGSEGV. To make things even more weird: This happened only on Linux not on Solaris and
during the usage of these pointers the dso was already loaded again.
The solution: On a modern Linux distribution with additional security features
loading a dso a second time does not guarantee that it is loaded to the
same address (in contrast to Solaris). So the pointers to the literals where
invalid. Ouch.
In order to fix this I did what you proposed: I used a global pool to load the dso.



View raw message