Return-Path: Delivered-To: apmail-apr-dev-archive@www.apache.org Received: (qmail 45677 invoked from network); 17 Mar 2010 23:07:20 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 17 Mar 2010 23:07:20 -0000 Received: (qmail 55819 invoked by uid 500); 17 Mar 2010 23:07:19 -0000 Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 55758 invoked by uid 500); 17 Mar 2010 23:07:19 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Id: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 55750 invoked by uid 99); 17 Mar 2010 23:07:19 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 17 Mar 2010 23:07:19 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of inovick@greenplum.com designates 64.78.17.16 as permitted sender) Received: from [64.78.17.16] (HELO EXHUB018-1.exch018.msoutlookonline.net) (64.78.17.16) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 17 Mar 2010 23:07:11 +0000 Received: from EXVMBX018-10.exch018.msoutlookonline.net ([64.78.17.51]) by EXHUB018-1.exch018.msoutlookonline.net ([64.78.17.16]) with mapi; Wed, 17 Mar 2010 16:06:49 -0700 From: Ivan Novick To: Graham Leggett CC: "dev@apr.apache.org" Date: Wed, 17 Mar 2010 16:06:48 -0700 Subject: Re: apr_hash_set allocation failure behavior Thread-Topic: apr_hash_set allocation failure behavior Thread-Index: AcrGIrB2bhR4pWhjTq+hyHR72UOOvwAA9TJ/ Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C7C6AE981611inovickgreenplumcom_" MIME-Version: 1.0 X-Virus-Checked: Checked by ClamAV on apache.org --_000_C7C6AE981611inovickgreenplumcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On 3/17/10 3:39 PM, "Graham Leggett" wrote: >On 18 Mar 2010, at 12:18 AM, Ivan Novick wrote: >> I am doing some testing with APR version 1.2.12 >> >> When adding to a hash table using apr_hash_set ... If memory can not >> be >> allocated what is the expected behavior? >> >> I am seeing apr_hash_set calls expand_array. >> >> expand_array core dumps if memory can not be allocated. >> >> Is this expected? Is there a way to get an error code for a failed >> insert >> to a table rather than a coredump? >This is definitely wrong, APR should return APR_ENOMEM if memory >cannot be allocated. >More specifically, the APR pools code gives the caller (you) the >choice of behaviour when the memory allocation fails. You can choose >to have APR call a function of your choice, or you can choose APR to >return APR_ENOMEM. >httpd chooses to call a function that terminates the server child when >out of memory, and as a result httpd makes no attempt to cater for out >of memory conditions, but other callers of APR don't have to, and APR >itself should definitely respect APR_ENOMEM. When you say this wrong, do you mean the code is wrong or that the analysis= of what the code does is wrong? In the code below, if alloc_array returns NULL, this should core dump. In = fact this code returns void so I don't see how it could be passing back inf= ormation about failed memory allocation with a return code. Cheers, Ivan /* * Expanding a hash table */ static void expand_array(apr_hash_t *ht) { apr_hash_index_t *hi; apr_hash_entry_t **new_array; unsigned int new_max; new_max =3D ht->max * 2 + 1; new_array =3D alloc_array(ht, new_max); for (hi =3D apr_hash_first(NULL, ht); hi; hi =3D apr_hash_next(hi)) { unsigned int i =3D hi->this->hash & new_max; hi->this->next =3D new_array[i]; new_array[i] =3D hi->this; } ht->array =3D new_array; ht->max =3D new_max; } --_000_C7C6AE981611inovickgreenplumcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: apr_hash_set  allocation failure behavior On 3/17/10 3:39 PM, "Graham Leggett" <minfrin@sharp.fm> wrote:

>On 18 Mar 2010, at 12:18 AM, Ivan Novic= k wrote:

>> I am doing some testing with APR version 1.2.12
>>
>> When adding to a hash table using apr_hash_set ... If memory can n= ot
>> be
>> allocated what is the expected behavior?
>>
>> I am seeing apr_hash_set calls expand_array.
>>
>> expand_array core dumps if memory can not be allocated.
>>
>> Is this expected?  Is there a way to get an error code for a = failed
>> insert
>> to a table rather than a coredump?

>This is definitely wrong, APR should return APR_ENOMEM if memory
>cannot be allocated.

>More specifically, the APR pools code gives the caller (you) the
>choice of behaviour when the memory allocation fails. You can choose >to have APR call a function of your choice, or you can choose APR to >return APR_ENOMEM.

>httpd chooses to call a function that terminates the server child when =
>out of memory, and as a result httpd makes no attempt to cater for out =
>of memory conditions, but other callers of APR don't have to, and APR <= BR> >itself should definitely respect APR_ENOMEM.


When you say this wrong, do you mean the code is wrong or that the analysis= of what the code does is wrong?

In the code below, if alloc_array returns NULL, this should core dump. &nbs= p;In fact this code returns void so I don’t see how it could be passi= ng back information about failed memory allocation with a return code.

Cheers,
Ivan

/*
 * Expanding a hash table
 */

static void expand_array(apr_hash_t *ht)
{
    apr_hash_index_t *hi;
    apr_hash_entry_t **new_array;
    unsigned int new_max;

    new_max =3D ht->max * 2 + 1;
    new_array =3D alloc_array(ht, new_max);
    for (hi =3D apr_hash_first(NULL, ht); hi; hi =3D ap= r_hash_next(hi)) {
        unsigned int i =3D hi->t= his->hash & new_max;
        hi->this->next =3D ne= w_array[i];
        new_array[i] =3D hi->thi= s;
    }   
    ht->array =3D new_array;
    ht->max =3D new_max;
}

--_000_C7C6AE981611inovickgreenplumcom_--