> > 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 :) > > 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"
