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. Regards Rüdiger
