> "first the attacker has to find a way to reduce system memory to an
> almost oom condition"
> Say, by attacking several httpd threads and/or unrelated processes to
> get them to eat up memory.
>
> --
> Sent from my toaster.
>
If you know something why not share it ;) ?
imho Apache is pretty goo
> And if you can't illustrate a few explicit cases, further abstract arguments
> are likely to be politely, but firmly, ignored. There are good C language
> forums for folks to carry on such religious arguments.
>
> Or to put it another way, the dev@ group here is most certainly not worried
> abou
On 2 September 2010 13:29, William A. Rowe Jr. wrote:
> On 9/1/2010 10:17 PM, dave b wrote:
>>
>> Why not just fix it now and not worry? ...
>
> It will help if you can provide a specific use case for graceful failure.
>
> A segfault/dereference of NULL pointer provide
> 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 mat
>
> 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 fun
On 1 September 2010 22:08, Jeff Trawick wrote:
> On Wed, Sep 1, 2010 at 6:37 AM, Graham Dumpleton
> wrote:
>>
>> On 1 September 2010 20:15, Graham Leggett wrote:
>> > On 01 Sep 2010, at 6:07 AM, dave b wrote:
>> >
>> >> What is the
What is the rational behind not checking the return value of
apr_palloc and apr_pcalloc?
code memory/unix/apr_pools.c from apr-1.4.2
APR_DECLARE(void *) apr_pcalloc(apr_pool_t *pool, apr_size_t size);
APR_DECLARE(void *) apr_pcalloc(apr_pool_t *pool, apr_size_t size)
{
void *mem;
if ((me
