On Wed, Jul 13, 2016 at 05:37:36PM +0000, Bailey, Aaron wrote: > This is an update to the reported issue below. > > It appears that calling the pre-processor macro svn_pool_create with an > argument of NULL is done a lot in the Subversion code base. The comments in > the APR function apr_pool_create_ex in module memory/unix/apr_pools.c seems > to imply you shouldn't do this. However, as long as you've made a call to > either the APR function apr_pool_initialize in the module > memory/unix/apr_pools.c or apr_initialize in one of the OS appropriate APR > modules then you're ok as it initializes the global pool which is used when > the parent argument is NULL. However, the stack flow listed below from the > mod_dav_svn subversion module never makes a call to any of the initialization > functions. Ensuring that the APR module has been correctly initialized > resolves this issue. That being said the APR code should probably handle > being called before initialization gracefully rather than just causing a > segmentation fault. > > I will note that while I didn't test it, the same issue appears to be present > in the Subversion 1.8.16 code base via code inspection. Since Subversion 1.8, > and probably 1.9, are widely in use maybe something about how I configure / > build the code is causing this issue. That being said, I cannot get the > Subversion Apache module to work correctly without first patching the code to > explicitly initialize the APR module (and patching APR to check if it's been > initialized and return an appropriate apr_status_t for good measure). > > Thanks, > > Aaron >
It seems odd that you'd be the only person on the planet running into this. It's such a fundamental problem. Nothing will work if pools don't work. Shouldn't Apache HTTPD be intializing the process-global APR state? Perhaps, somehow, there's a problem with the HTTPD that's loading mod_dav_svn?
