>Sorry I have a habit of measuring things twice and cutting once ;)
> 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.)
It doesn't sound rude. It sounds like you want me to do the work for you.
> 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
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 :) ).
I would need to do a lot more testing and I don't have much time for
> 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.
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.
ah there is a -v !
>> 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 :)
> email@example.com, but first try gdb or testall -v or anything else that
> you need to find exactly what/where the failure is
The ripest fruit falls first. -- William Shakespeare, "Richard II"