httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@gmail.com>
Subject Re: rational behind not checking the return value of apr_palloc and apr_pcalloc
Date Wed, 01 Sep 2010 21:06:38 GMT
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...

Mime
View raw message