gracefully respond to allocation failures

[GoogleCodeExporter]

protobuf-c uses a flexible pluggable allocator scheme to permit clients of
the library to adapt it to any kind of memory allocator. There is also a
hook allowing the standard allocator's response to allocation failure to be
customized. Unfortunately, this flexibility is of limited use because the
uses of the allocator in the protobuf-c library don't check for allocation
failure, meaning that the default behavior of aborting when out of memory
is pretty much the only available option.

For my project I needed robustness against alloc failure, and aborting the
program is not acceptable. The attached patch tries to make it so that all
calls into the protobuf-c lib either complete all allocations successfully,
or unwind all partial allocations and return NULL. Please consider it for
inclusion in the standard protobuf-c distribution.

Two unit tests were added to test the new behavior, but they don't yet
cover all allocation code paths in library.

Original issue reported on code.google.com by jason.l...@gmail.com on 17 Feb 2009 at 10:05

Attachments:

• protobuf-c-alloc-fail.patch

[GoogleCodeExporter]

your patch is generally good -- i will probably apply it -- except that i will
replace "sz" with "size".

i've gotta say though, i'm skeptical of claims that handling each allocation 
failure
is really a viable strategy in a memory-cramped device.  i'd suggest instead
replacing the allocator with one that has a fixed pool and uses setjmp/longjmp 
instead.

Original comment by lahike...@gmail.com on 19 Feb 2009 at 5:19

[GoogleCodeExporter]

In userspace on a memory-cramped device, that would make sense. I did look for 
a way
to use setjmp/longjmp, but in the kernel context where I want to use protobuf-c
nothing like that is readily available. In any case, I'm glad you're amenable to
carrying the patch.

Original comment by jason.l...@gmail.com on 19 Feb 2009 at 6:15

[GoogleCodeExporter]

Alright, thanks for your patch again.  I hadn't noticed the test code before.
I REALLY appreciate that since adding a bunch of untested (and hard to cover 
with
test code too..) code to protobuf-c wasn't exactly appealing.

(I did use a cheesy macro instead of the more classic approach in your patch, 
but I
think the result should be identical, at least if you disregard the exact 
details of
the error messages.)

subversion rev 173.

Original comment by lahike...@gmail.com on 5 Mar 2009 at 4:02

[GoogleCodeExporter]

Original comment by lahike...@gmail.com on 5 Mar 2009 at 4:02

• Changed state: Fixed