malloc return checks about aerospike-client-c

[BrianNichols]

The C client assumes malloc failure is a terminal condition (not recoverable).

[bbulkow]

Lathakris - this is an interesting recent ( last 10 years ) debate among the C programmers I know. Linux ( the most used standard C library ) appears to literally never return null - it'll take out the process instead. While everyone agrees that malloc should be able to return 0 and continue, it seems more and more that returning 0 either doesn't happen, or could be considered a fatal error.

What library and platform are you using, and in what situation do you think that processing should continue in the face of being out of memory?

[lathakris]

Thank you so much for the response. I was just wondering if it returns null we can gracefully exit as opposed to the process crash, like the trace below.

__memcpy_sse2_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S:35
#1 0x00000000006a852f in memcpy (__len=21370660, __src=0x7f85f1b9c039, __dest=) at /usr/include/x86_64-linux-gnu/bits/string3.h:51
#2 as_command_parse_bins (rec=rec@entry=0x7f85f4047780, p=0x7f85f1b9c039 "\001", n_bins=, deserialize=)
at src/main/aerospike/as_command.c:1028
#3 0x00000000006a87a1 in as_command_parse_result (err=, sock=0x7f85f8ff6fe0, deadline_ms=, user_data=0x7f85f8ff7100)
at src/main/aerospike/as_command.c:1096
#4 0x00000000006a771a in as_command_execute (cluster=0x2881a60, err=err@entry=0x7f85f8ff73a0, cn=cn@entry=0x7f85f8ff7110, command=0x7f85f8ff7070 "\002\003",
command_len=command_len@entry=90, timeout_ms=1000, retry_on_timeout=false, max_retries=1,tui sleep_between_retries_ms=0,
parse_results_fn=0x6a8566 <as_command_parse_result>, parse_results_data=parse_results_data@entry=0x7f85f8ff7100) at src/main/aerospike/as_command.c:474
#5 0x00000000006a326f in aerospike_key_get (as=0xb07f00 , err=0x7f85f8ff73a0, policy=0xb07fe8 <as+232>, key=0x7f85f8ff72f0, rec=0x7f85f8ff7258)
at src/main/aerospike/aerospike_key.c:111
#6 0x0000000000439fcb in aeroKeyGet (as=0xb07f00 , err=0x7f85f8ff73a0, key=0x7f85f8ff72f0, rec=0x7f85f8ff7258) at libs/libaero/libaero.c:369

[BrianNichols]

We will start checking for null and recover gracefully in the critical sections of code. Your example case qualifies because the malloc size is determined by the protocol stream received from the server which definitely should be checked.

[lathakris]

Thanks once again!

[lathakris]

BTW we are using Linux ubuntu

[BrianNichols]

C client 4.1.4 has been released.

http://www.aerospike.com/download/client/c/4.1.4/