On Wed, Sep 1, 2010 at 4:09 PM, dave b <db.pub.mail@gmail.com> wrote:
> My 2 cents:
> I doubt that any of the core devs are going to match you for devotion to
> this topic, but I'm sure we will review patches to trunk to fix somewhat
> practical scenarios, such as ensuring that memory allocation failures during
> request processing go through the common abort function, if the existing
> code doesn't already handle that.  (OTOH, I wouldn't think many would find
> addressing un-aborted alloc failures during initialization so interesting.)

Sorry I have a habit of measuring things twice and cutting once ;)

> That requires some investigation/understanding of the context of the code
> that passes NULL for the parent pool, which hopefully you can make an
> attempt at without dumping the grep output and selected source code to the
> mailing list ;)
> (I know that sounds rude, but its my best advice to pursuing that thread of
> investigation.)

It doesn't sound rude. It sounds like you want me to do the work for you.

no, I don't want you to do anything for me; I'm just sharing my educated guess at what it takes to make progress on this topic you're apparently very interested in

with a little luck you'll be able to find somebody here to analyze the code you pointed out to see which cases actually matter, and to what extent

The code dump and grep was to give some examples.
I think without the code dump some would have problems following  that
the global_pool abort_fn is not to abort when it would otherwise
return NULL ( I believe this to be the case atm at least :) ).

> What's the big picture here from your standpoint?  Why is 2.2 noticeably
> impaired without such changes?  Are there really many users who need that
> abort function to tell them that httpd can't alloc more heap?  Anyway, if
> 2.3 doesn't really have this suitably addressed it would be better to get
> that finished first.

I would need to do a lot more testing and I don't have much time for
that presently. I will have a poke around later in a vm after making
some modifications to the code base to try and trigger somethings :)
IMHO the apr init function, which inits the global_pool, could take in
an argument for the default abort_fn.

>> Also, note I hit that code path via apr testdir (in one of the tests
>> ;) ) - and I was not out of memory - I haven't checked which test it
>> is yet (it would be nice if the apr tests told me this...).
>> If the caller has hit that code path and they haven't defined an
>> abort_fn, I think it best to exit / abort for them - If a user wants
>> not to have that happen then they can just simply ensure they are
>> providing their own abort_fn :)
> dev@apr.apache.org, but first try gdb or testall -v or anything else that
> you need to find exactly what/where the failure is

ah there is a -v !

The ripest fruit falls first.           -- William Shakespeare, "Richard II"

Born in Roswell... married an alien...