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. Cheers, Stefan
