httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dave b <db.pub.m...@gmail.com>
Subject Re: rational behind not checking the return value of apr_palloc and apr_pcalloc
Date Wed, 01 Sep 2010 20:09:40 GMT
>
> 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.
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"

Mime
View raw message