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?
Received on 2016-07-14 10:06:54 CEST