On Mon, Jan 14, 2019 at 8:26 AM Stefan Eissing <stefan.eiss...@greenbytes.de> 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. > APR pools in general are safe here, provided the correct thread allocator is used and lifetimes are correctly observed. APR pool debugging may not be observing the same boundaries as the release code. By thread-allocator, that isn't insisting the pool stays on the same thread, but that all palloc calls by threads sharing that allocator are always serialized. Any application passing pools across threads becomes responsible to ensure that serialization. > 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. > That's an error within some of the APR pool "debugging" diagnostic design, it is overly protective. In the Apache httpd example, earlier implementation of the 'event' MPM would have illustrated the lie underlying this assertion. > 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. > APR pool debugging needs changes to work in free-threaded applications; again to the httpd example, the creators only considered the 'worker' mpm model, one long lived thread that outlived any child threads. > 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. > I'm happy to spend cycles looking at any mis-assumptions by the APR pool debugging logic and proposed corrections with you.
