On Mon, Jan 14, 2019 at 03:26:41PM +0100, Stefan Eissing wrote:
> Dear APR devs,
> I need help regarding apr pools and the assumptions they make, especially in 
> debug mode.
> Background: there are reports of read after free and failed assertions when 
> httpd's HTTP/2 implementation is used with pool debugging. 
> From scanning the code, I can see two issues at least:
> 1. pool debugging will on certain events traverse the pool tree. This seems 
> not a good idea as h2 may have child pools active in several threads. And 
> there is no global mutex for all pools - that is unwanted.
> 2. The thread creating the pool is checked against the current thread in 
> apr_pool_check_integrity() which is certainly not true all the time in h2. 
> Pools are created in one thread and then passed to another.
> Now, I am not asking for revolutionary changes in apr pools to cope with my 
> implementation. But to change my implementation to work in pool debugging, I 
> need to understand the restrictions and underlying assumptions clearly. 
> Before dumping the h2 pool usage description on the list here, maybe there is 
> someone willing to work with me on this closely? If the list prefers a 
> detailed discussion here, I can of course also do that.
> Please advise.
> Cheers, Stefan

FYI, the reason APR pool debugging is enabled in production on OpenBSD
is because, after Heartbleed, OpenBSD decided to force 3rd party software
to use the operating system's malloc/free implementation instead of custom
allocators, where possible.

If there was another way to make APR pools map directly to malloc/free
I would like to know about it. As far as I undestand, APR pools will
cache freed memory unless pool debugging is enabled.


Reply via email to