Re: Pool Debug & Worker MPM compatibility

[Joshua Marantz <jm...@google.com>]

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 <jm...@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 <in...@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
>
>