When running valgrind on code that uses LDT (in our case map), there is an occurrence of an initialised read on an as_error struct.
The error itself seems to be fairly harmless (caused by not initialising the message member of the struct to 0), but causes our valgrind tests to fail:
==12284== Memcheck, a memory error detector
==12284== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==12284== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==12284== Command: ./test
==12284==
==12284== Conditional jump or move depends on uninitialised value(s)
==12284== at 0x4E4D4CE: ldt_parse_error (_ldt.c:23)
==12284== by 0x4E521DE: aerospike_lmap_put (aerospike_lmap.c:88)
==12284== by 0x41EDAF: AsEngine::addToSet(std::string const&, std::string const&, std::map<std::string, std::string, std::less<std::string>, std::allocator<std::pair<std::string const, std::string> > > const&) (AsEngine.cpp:316)
==12284== by 0x41F740: AsEngine::addRef(std::string const&, std::string const&, std::string const&) (AsEngine.cpp:376)
==12284== by 0x416F15: AsSet::storeKeyRef(std::string const&) (AsSet.cpp:125)
==12284== by 0x416A2F: AsSet::putString(std::string const&, std::string const&) (AsSet.cpp:63)
==12284== by 0x414FB2: main (main.cpp:32)
==12284==
==12284== Conditional jump or move depends on uninitialised value(s)
==12284== at 0x4E4D4CE: ldt_parse_error (_ldt.c:23)
==12284== by 0x4E51349: aerospike_lmap_destroy (aerospike_lmap.c:462)
==12284== by 0x41F02F: AsEngine::addToSet(std::string const&, std::string const&, std::map<std::string, std::string, std::less<std::string>, std::allocator<std::pair<std::string const, std::string> > > const&) (AsEngine.cpp:327)
==12284== by 0x41F740: AsEngine::addRef(std::string const&, std::string const&, std::string const&) (AsEngine.cpp:376)
==12284== by 0x416F15: AsSet::storeKeyRef(std::string const&) (AsSet.cpp:125)
==12284== by 0x416A2F: AsSet::putString(std::string const&, std::string const&) (AsSet.cpp:63)
==12284== by 0x414FB2: main (main.cpp:32)
==12284==
We have a workaround by using as_error err = {}; in our code, but we prefer to have this fixed to the LDT in the library.
When running valgrind on code that uses LDT (in our case map), there is an occurrence of an initialised read on an
as_error
struct.The error itself seems to be fairly harmless (caused by not initialising the
message
member of the struct to 0), but causes our valgrind tests to fail:We have a workaround by using
as_error err = {};
in our code, but we prefer to have this fixed to the LDT in the library.