httpd-modules-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joshua Marantz <jmara...@google.com>
Subject Re: po
Date Thu, 01 Sep 2011 13:05:04 GMT
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 <info@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message