On Wed, Sep 1, 2010 at 4:09 PM, dave b <db.pub.m...@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 :) > > > > d...@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...
