apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From M Joonas Pihlaja <jpihl...@cc.helsinki.fi>
Subject APR failing in low memory situations
Date Wed, 21 Feb 2007 20:25:15 GMT

Hi list,

I ran into a problem where a program I'm working on was
segfaulting when calling apr_hash_set() due to memory exhaustion.
So I was going to ask if we can have a version of apr_hash_set()
which could return a status code if it fails to add a value to a
hash.  Having a closer look at the source to APR, though, I
realised that almost none of the memory allocation calls inside
APR itself are checked for a NULL return value[1].

The thing is, there are 208 calls to apr_palloc() and 133 to
apr_pcalloc() in the source[2], so it would be quite a large job
to fix all of them.  On the up side, of all the cases I did look
at, they all seemed to be of the sort where it would be fairly
easy to add the extra checks to make them fail with APR_ENOMEM.
However, I fear the ripple effect of adding new failing states
would be much larger.  For example, all the calls to
apr_cleanup_register() would need to be changed too, since
currently that call is assumed to always succeed.

Anyway, the consistency with which memory allocations are not
checked makes me think that everyone else is using pool abort
functions in their programs.  Is this really true?  Isn't APR
supposed to be usable without them?

Best Regards,


[1] At least among the randomish sampling of
apr_palloc()/apr_pcalloc() calls within the library I looked at.

[2] From Debian's apache2-2.2.3 package.  Corresponds to APR
version 1.2.7.

View raw message