Oh also I should not that when I do my load-test with pool-debugging off, all is well. The error_log has zero signals/aborts. The main reason I was using pool-debug in the first place was to get better valgrind leak-checks. But if this is just not compatible with Worker MPM I can stay with pool debug off.
-Josh On Thu, Sep 1, 2011 at 9:05 AM, Joshua Marantz <jmara...@google.com> wrote: > Hi Ben, > > Hmmm...don't know what happened to that subject line "po". Not what I > meant to type, obviously! > > On Thu, Sep 1, 2011 at 8:14 AM, Ben Noordhuis <i...@bnoordhuis.nl> wrote: >> >> That assertion is triggered when you add a string from pool A to a >> table in pool B where A is a child of B (adding headers from the >> request_rec to a conn_rec table, for example). It's a lifecycle issue. >> > > OK given the stack-trace above it's hard for me to figure out a path back > from my module. Of course a random memory stomp could make any weird thing > happen, but only this one specific thing always happens. And we try to > avoid memory-stomps via valgrind etc though it's impossible to prove that > none exist under load. > > > But I think I've found 2 potential problems in httpd: > 1. protocol.c calls apr_table_addn using a char* value that is offset > from a pool-allocated string. It's not obvious that it's doing > this safely but it makes sense this code has to run crazy fast and > has lots of mileage on it. And it's probably OK for the pool-find > algorithm appears to do a pointer-range check in apr_pools.c:1908, > function pool_find(). For the moment I'll assume this is not > the actual problem. > 2. there are a bunch of ifdefs in apr_pools.c for POOL_DEBUG and there's > a some mutexing for APR_HAS_THREADS, e.g. in > apr_allocator_max_free_set. But I suspect the debug structures for > POOL_DEBUG are not adequately mutexed. > > Has anyone specifically used pool-debug and worker-mpm together under heavy > load? > > Thanks! > -Josh > >