As mentioned I encountered random crashes when doing around 104600 to 104700 queries with c client API.
I use Qt Creator on Ubuntu LTS 12.04.
I forked the c client 4.0.2 on github and compiled it on my local machine. With the deb package I got just few chunks of assembly, with the self compiled stuff i got crashes at aerospike code or assembly without a stack trace. But in common are the different locations and that i can run somewhat about 104k aerospike_key_get(). I installed signal handlers which work fine with ctrl+c or *(int*)0 = 42; but are unable to catch those SIGSEGV, even gdb crashed.
As anyone some ideas for me how to deal with it?
I figured a work around out: i count the API operation and when it reaches 100k then I throw as_config and aerospike away and create completely fresh ones, this avoids the crash
as_config is not designed to stick around. All of the as_config data is copied when aerospike_connect() is called, so as_config can go out of scope after that.
The first implementation was just a few lines within the main (the application just imports some data from files like csv) in that stage as_config lifed on stack for whole run time.
The latest version, which still contains the bug, throws it away after aerospike_init() and aerospike_connect().
My workaround is to throw everything, including aerospike* as; after 100k queries away, parse the int main(args) and create everything again, then go on with the import. If i instead just do aerospike_close and ‘aerospike_connect’ i get a AEROSPIKE_ERR_TIMEOUT afterwards.
uuid is not defined, but I assume its a C++ string. as_record_get_str() is returning a “char *”. Is this string really being constructed/destructed properly when assigned a “char *” in a loop? I’m not a C++ expert.
In general, the aerospike calls look okay. I don’t have any advice other than to check for memory leaks/stomps when interfacing between C and C++ types.
std::string line, dmpuid, data, timestamp, convertedData, uuid;
is written just before while (std::getline(std::cin, line)) so its propper assigned and copied.
Yes i guess its a deeper analysis in maybe clib, aslib and/or memroy…