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 <[email protected]> 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
