apr_table_overlap and pool ancestor assumption

[Jeff Trawick <tr...@attglobal.net>]

What will happen if keys and values in b are NOT from an ancestor of
a's pool but b has sufficient lifetime?

I'm debugging a segfault in hash_overlap() when driven by a 3rd party
Apache module.  Clearly the 3rd party module is misusing
apr_table_overlap() because a is from the request pool and b is from
pconf, which is in essence a storage leak because pconf shouldn't
grow.

I can't explain the actual segfault, though.  In the segfaulting
scenario, which is very intermittent, some pointers (tree_parent,
merge_left) in the hash table created in apr_table_overlap are
actually literal strings from the table.  These could also be hashes
of the strings.

Does anybody understand this code well enough to describe what bad
will happen besides a storage leak in this scenario?  pconf isn't
going away, so there doesn't seem to be a storage lifetime problem.

-- 
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...

Re: apr_table_overlap and pool ancestor assumption

[Jeff Trawick <tr...@attglobal.net>]

The segfault problem was that the pool code occasionally handed out
the same buffer twice because it doesn't handle more than one thread
allocating from the same pool.  That is what essentially was happening
since more than one thread was passing the same table as the second
parm to apr_table_overlap().  That explains why the bad pointers in
the hash table were non-pointers that the overlap operation would need
to store somewhere.

So fixing the storage leak fixed the segfault.

Have fun,

-- 
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...

Re: apr_table_overlap and pool ancestor assumption

[Jeff Trawick <tr...@attglobal.net>]

Brian Pane <br...@cnet.com> writes:

> The worst thing that should happen in that scenario is a storage leak.
> If you can isolate a test case that triggers the problem, please let
> me know and I'll work on debugging it.

Thanks.  The next step I'll take is to look for a thread safety issue
with multiple threads doing an overlap using the same table for table
b.  If that doesn't explain the mangling and subsequent segfault, then
I'll build a testcase with the same tables and see if I can make the
overlap segfault. 

I changed the module to do an overlay operation and the storage leak
and segfault are gone, but I hate not knowing what caused the
segfault.

-- 
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...

Re: apr_table_overlap and pool ancestor assumption

[Brian Pane <br...@cnet.com>]

Jeff Trawick wrote:

>What will happen if keys and values in b are NOT from an ancestor of
>a's pool but b has sufficient lifetime?
>
>I'm debugging a segfault in hash_overlap() when driven by a 3rd party
>Apache module.  Clearly the 3rd party module is misusing
>apr_table_overlap() because a is from the request pool and b is from
>pconf, which is in essence a storage leak because pconf shouldn't
>grow.
>
>I can't explain the actual segfault, though.  In the segfaulting
>scenario, which is very intermittent, some pointers (tree_parent,
>merge_left) in the hash table created in apr_table_overlap are
>actually literal strings from the table.  These could also be hashes
>of the strings.
>
>Does anybody understand this code well enough to describe what bad
>will happen besides a storage leak in this scenario?  pconf isn't
>going away, so there doesn't seem to be a storage lifetime problem.
>  
>

The worst thing that should happen in that scenario is a storage leak.
If you can isolate a test case that triggers the problem, please let
me know and I'll work on debugging it.

Thanks,
Brian