Uninitialised value was created by a heap allocation: Unordered_map - c++

SOLUTION: I can have huge strings, then I have to reserve memory for them. Instead of use string I use char pointer in hash table and therefore I reserve the appropriate memory for my hash table keys.
PROBLEM:
I'm sorry if the question already made, but I could not find any answer that helped me.
I've the following code:
EDIT (the main loop of the problematic function for Valgrind)
i = 0;
wordPos = 0;
for (; it != end; ++it,i++){
// I want to ignore this element on purpose
if (i == 1) continue;
bool isscript;
string tag(it->tagName());
convertToLower(tag);
if (it->isTag()==1){
if (tag=="script") isscript = true;
else isscript = false;
}
if (it->isComment()==0 && it->isTag()==0 && isscript==0){
wordlist.clear();
tokenize(it->text(),wordlist);
int ii = 0;
vector<string>::iterator it_palavras = wordlist.begin();
vector<string>::iterator it_words = wordlist.begin();
int ii = 0;
while(ii<wordlist.size()){
string word(wordlist[ii]);
convertToLower(word);
wordsPos++;
if (voc.find(word) == voc.end()){
voc[word] = countwords;
voc_inv[countwords] = words;
term_pos[countwords] = new vector<int>();
term_pos[countwords]->push_back(wordpos);
countwords++;
}else{
if (term_pos.find(voc[word]) == term_pos.end())
term_pos[voc[word]] = new vector<int>();
term_pos[voc[word]]->push_back(wordpos);
}
ii++;
}
}
The type of voc is unordered_map, but when I run valgrind in my code there is the following message:
EDIT Now I'm pasting the complete error with the flag --track-origins=yes.
EDIT 2 Now I'm pasting the complete error with the flag --—dsymutil=yes.
==21036== Use of uninitialised value of size 8
==21036== at 0x4201FF: _platform_memcmp (in /usr/lib/system/libsystem_platform.dylib)
==21036== by 0x10001F10D: std::__1::__hash_iterator<std::__1::__hash_node<std::__1::pair<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, int>, void*>*> std::__1::__hash_table<std::__1::pair<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, int>, std::__1::__unordered_map_hasher<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, int, std::__1::hash<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, true>, std::__1::__unordered_map_equal<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, int, std::__1::equal_to<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, true>, std::__1::allocator<std::__1::pair<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, int> > >::find<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) (string:642)
==21036== by 0x10000358F: Colecao::ler_arvore_dom(tree<htmlcxx::HTML::Node, std::__1::allocator<tree_node_<htmlcxx::HTML::Node> > >, int, std::__1::unordered_map<int, std::__1::vector<int, std::__1::allocator<int> >, std::__1::hash<int>, std::__1::equal_to<int>, std::__1::allocator<std::__1::pair<int const, std::__1::vector<int, std::__1::allocator<int> > > > >&) (colecao.cpp:135)
==21036== by 0x100002A19: Colecao::ler(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >) (colecao.cpp:73)
==21036== by 0x100001781: main (index.cpp:47)
==21036== Uninitialised value was created by a heap allocation
==21036== at 0x70AB: malloc (in /usr/local/Cellar/valgrind/HEAD/lib/valgrind/vgpreload_memcheck-amd64-darwin.so)
==21036== by 0x7528D: operator new(unsigned long) (in /usr/lib/libc++.1.dylib)
==21036== by 0x77E12: std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::__init(char const*, unsigned long) (in /usr/lib/libc++.1.dylib)
==21036== by 0x10001A0FF: std::__1::unordered_map<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, int, std::__1::hash<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, std::__1::equal_to<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, std::__1::allocator<std::__1::pair<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const, int> > >::__construct_node(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) (memory:1505)
==21036== by 0x10000838D: std::__1::unordered_map<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, int, std::__1::hash<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, std::__1::equal_to<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, std::__1::allocator<std::__1::pair<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const, int> > >::operator[](std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) (unordered_map:1209)
==21036== by 0x100003835: Colecao::ler_arvore_dom(tree<htmlcxx::HTML::Node, std::__1::allocator<tree_node_<htmlcxx::HTML::Node> > >, int, std::__1::unordered_map<int, std::__1::vector<int, std::__1::allocator<int> >, std::__1::hash<int>, std::__1::equal_to<int>, std::__1::allocator<std::__1::pair<int const, std::__1::vector<int, std::__1::allocator<int> > > > >&) (colecao.cpp:139)
==21036== by 0x100002A19: Colecao::ler(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >) (colecao.cpp:73)
==21036== by 0x100001781: main (index.cpp:47)
When I run the code in a huge amount of data I get segmentation fault, and I think it is because of this Valgrind error.
I don't think I need to reserve space for string in unordered_map, then I figured out that is something in word variable constructor. When I initialize word with a static string (for instance, word("test")), Valgrind stops to complain.
I don't know how to fix this string/unordered_map/memory issue.
EDIT: GDB didn't help me. The segmentation fault is only when I use huge amount of data and then huge amount of memory. The only thing GDB give me is Segmentation Fault and memory address nothing more. Valgrind gave me a more complete message.

This might actually be a problem between Valgrind and the memcmp() implementation of your platform (Mac OS X I suppose?).
The uninitialized value in your application supposedly comes from a malloc() call in std::string constructor, the latter of which is unlikely to "create" uninitialized memory on its own. So my guess would be that malloc() allocates a bit more memory than necessary (aligned to 8 bytes maybe), and _platform_memcmp() also takes these bytes into account. System libraries often have highly-optimized implementations of such functions (memcpy, memcmp, strcpy...). As Valgrind often has trouble with these optimizations, it provides own replacement functions (in mc_replace_strmem.c).
Maybe Valgrind lacks these replacements for OS X memcmp(), or your Valgrind version is too old? Also, there might be a setup problem with your system which prevents Valgrind from detecting the memcmp() function at runtime (I'm not familiar with OS X, but maybe you need some kind of debug info for your system libraries).
So, some questions:
are you running the latest Valgrind version? If not, upgrade it.
what OS X version are you using exactly?
does the problem disappear if you disable optimizations when compiling your application?
If this doesn't help, you might want to ask at the Valgrind users mailing list (http://valgrind.org/support/mailing_lists.html) for this specific problem.
Btw. it's pretty difficult to analyze the Valgrind backtraces without any line numbers. See Debugging Symbols Lost When Linking? for a suggestion to get line number info in the backtraces (in short: add "--dsymutil=yes" to Valgrind command line - but check out the notes for this option in http://valgrind.org/docs/manual/manual-core.html#manual-core.erropts first).

Related

xcode : undefined symbols when including headers

I recently started a project using swift and c++. So I installed Xcode and started using it. I first encountered some bugs, but fixed theme.
However, I still got some Undefined symbols for architecture x86_64:
I searched online and I can't find the solution for my problem (otherwise I would not have asked the question).
This is the whole error :
"parser(std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > >, Node*, int, int)", referenced from:
utilise_file(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, bool, bool, bool, bool, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >) in main.o
"recognize_paternes(Node*, bool)", referenced from:
utilise_file(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, bool, bool, bool, bool, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >) in main.o
"ast_t_rep(Node*, int)", referenced from:
utilise_file(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, bool, bool, bool, bool, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >) in main.o
"lex(char const*, std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > >&)", referenced from:
utilise_file(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, bool, bool, bool, bool, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >) in main.o
"visitor(std::__1::vector<Node*, std::__1::allocator<Node*> >, bool, bool, bool)", referenced from:
utilise_file(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, bool, bool, bool, bool, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >) in main.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
But I think we can just consider :
utilise_file(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, bool, bool, bool, bool, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >) in main.o
as this error seems to be redundant.
In my main.cpp file, I imported the header file (parser.h) where I declared Node *parser(vector<string>, Node *, int, int);.
In main.cpp>utilise_file(...), I call the function parser:
void utilise_file(){
...
vector<string> code_ref = vector<string>();
vector<string> lexeme = lex(source.c_str(), code_ref);
Node *ast_t = new Node();
ast_t->value = "main";
ast_t->type = "root";
Node *p = parser(lexeme, ast_t, 0, int(lexeme.size()));
...
}
So normally, I would not get this error.
It seems to me that it is a 'type' sort of problem, but I can't figure what.
I searched online for solutions, and I tried adding -Xlinker in Xcode>Linking>Other Liner Flags, but it didn't helped.
I also thought of adding the flags linking to the header in the compiling command line, but I think Xcode does that automatically. (Or not because many of my headers are not recognized in the file arborescence...)
Thank you for your help ;)
Edit : I found the problem, I had to manually add the previously written header files in Xcode (which did not do it automatically).
I found the problem.
When I imported the previously written header files in Xcode, Xcode did not attached them to the project.
I had to manually add theme, and now it works fine !

Google Filament rendering engine segmentation fault

I am attempting to compile the sample app "Suzanne" from the Filament library, by statically linking to the appropriate libraries. Both the sample app and libraries have been compiled from the latest source code. I am compiling with clang++.
However, when I compile and run the app, I get a segmentation fault. valgrind gives the following output:
==31202== Process terminating with default action of signal 11 (SIGSEGV)
==31202== Access not within mapped region at address 0x8
==31202== at 0x46A485: size (__hash_table:809)
==31202== by 0x46A485: bucket_count (__hash_table:1197)
==31202== by 0x46A485: std::__1::__hash_iterator<std::__1::__hash_node<std::__1::__hash_value_type<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, void*>*> std::__1::__hash_table<std::__1::__hash_value_type<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, std::__1::__unordered_map_hasher<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::__hash_value_type<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, std::__1::hash<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, true>, std::__1::__unordered_map_equal<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::__hash_value_type<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, std::__1::equal_to<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, true>, std::__1::allocator<std::__1::__hash_value_type<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > >::find<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) (__hash_table:2334)
==31202== by 0x461CA7: find (unordered_map:1205)
==31202== by 0x461CA7: image::KtxBundle::getMetadata(char const*, unsigned long*) const (KtxBundle.cpp:274)
==31202== by 0x463D26: image::KtxBundle::getSphericalHarmonics(filament::math::details::TVec3<float>*) (KtxBundle.cpp:290)
==31202== by 0x420E69: IBL::loadFromKtx(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) (in /home/joel/Documents/KiwiTest/filament-suzanne/out/suzanne)
==31202== by 0x42162D: IBL::loadFromDirectory(utils::Path const&) (in /home/joel/Documents/KiwiTest/filament-suzanne/out/suzanne)
==31202== by 0x41A41C: FilamentApp::loadIBL(Config const&) (in /home/joel/Documents/KiwiTest/filament-suzanne/out/suzanne)
==31202== by 0x415D19: FilamentApp::run(Config const&, std::__1::function<void (filament::Engine*, filament::View*, filament::Scene*)>, std::__1::function<void (filament::Engine*, filament::View*, filament::Scene*)>, std::__1::function<void (filament::Engine*, filament::View*)>, std::__1::function<void (filament::Engine*, filament::View*, filament::Scene*, filament::Renderer*)>, std::__1::function<void (filament::Engine*, filament::View*, filament::Scene*, filament::Renderer*)>, unsigned long, unsigned long) (in /home/joel/Documents/KiwiTest/filament-suzanne/out/suzanne)
==31202== by 0x40A1D4: main (in /home/joel/Documents/KiwiTest/filament-suzanne/out/suzanne)
==31202== If you believe this happened as a result of a stack
==31202== overflow in your program's main thread (unlikely but
==31202== possible), you can try to increase the size of the
==31202== main thread stack using the --main-stacksize= flag.
==31202== The main thread stack size used in this run was 8388608.
Any thoughts on what could be causing this and what I could do to resolve this would be greatly appreciated.
Error resolved (courtesy of TheGoldKnight23): The header files in use were outdated.

Error reading a Trajectory File using Chemfiles library

I need to write a piece of cpp code that will read a trajectory file (.pdb or .dcd files). I have followed the steps on the homepage of chemfiles library to read in the file. I am getting an error about undefined symbols for architecture x86_64 (please see a piece of the error log below).
What I want: Able to read the .dcd/.pdb file using the chemfiles library (or any other suitable library to do so) - I need to access the coordinates of the atoms listed in the file.
Code that reproduces the error when compiled using the command below:
#include "/usr/local/include/chemfiles.hpp" //path to library on my mac
int main(int argc, char *argv[]) {
chemfiles::Trajectory testfile("test.dcd");
return 1;
}
Code that compiles successfully in CLI using the command below:
#include "/usr/local/include/chemfiles.hpp" //path to library on my mac
int main(int argc, char *argv[]) {
// chemfiles::Trajectory testfile("test.dcd");
return 1;
}
Command to compile program:
g++-8 -fopenmp trial.cpp -o trial -lchemfiles -L /usr/local/lib
// I am using openmp because my original code is about parallelisation with openmp
Error:
Undefined symbols for architecture x86_64:
"chemfiles::Trajectory::Trajectory(std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >, char,
std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> > const&)", referenced from:
_main in ccnk7agz.o
"std::__1::basic_string<char, std::__1::char_traits<char>,
std::__1::allocator<char> >::find(char, unsigned long) const",
referenced from:
file_open_info::parse(std::__1::basic_string<char,
std::__1::char_traits<char>, std::__1::allocator<char> > const&,
std::__1::basic_string<char, std::__1::char_traits<char>,
std::__1::allocator<char> > const&) in libchemfiles.a(Trajectory.cpp.o)
split_comment(std::__1::basic_string<char,
std::__1::char_traits<char>, std::__1::allocator<char> >&) in
libchemfiles.a(LAMMPSData.cpp.o)
"std::__1::basic_string<char, std::__1::char_traits<char>,
std::__1::allocator<char> >::rfind(char, unsigned long) const",
referenced from:
file_open_info::parse(std::__1::basic_string<char,
std::__1::char_traits<char>, std::__1::allocator<char> > const&,
std::__1::basic_string<char, std::__1::char_traits<char>,
std::__1::allocator<char> > const&) in libchemfiles.a(Trajectory.cpp.o)
chemfiles::SDFFormat::read(chemfiles::Frame&) in
libchemfiles.a(SDF.cpp.o)
"std::__1::basic_string<char, std::__1::char_traits<char>,
std::__1::allocator<char> >::compare(unsigned long, unsigned long, char
const*, unsigned long) const", referenced from:
file_open_info::parse(std::__1::basic_string<char,
std::__1::char_traits<char>, std::__1::allocator<char> > const&,
std::__1::basic_string<char, std::__1::char_traits<char>,
std::__1::allocator<char> > const&) in libchemfiles.a(Trajectory.cpp.o)
chemfiles::Trajectory::Trajectory(std::__1::basic_string<char,
std::__1::char_traits<char>, std::__1::allocator<char> >, char,
std::__1::basic_string<char, std::__1::char_traits<char>,
std::__1::allocator<char> > const&) in libchemfiles.a(Trajectory.cpp.o)
chemfiles::FormatFactory::register_format(chemfiles::FormatInfo,
std::__1::function<std::__1::unique_ptr<chemfiles::Format,
std::__1::default_delete<chemfiles::Format> >
(std::__1::basic_string<char, std::__1::char_traits<char>,
std::__1::allocator<char> >, chemfiles::File::Mode,
chemfiles::File::Compression)>) in libchemfiles.a(FormatFactory.cpp.o)
chemfiles::Frame::guess_bonds() in
libchemfiles.a(Frame.cpp.o)
chemfiles::FormatInfo::FormatInfo(std::__1::basic_string<char,
std::__1::char_traits<char>, std::__1::allocator<char> >) in
libchemfiles.a(CSSR.cpp.o)
chemfiles::FormatInfo::FormatInfo(std::__1::basic_string<char,
std::__1::char_traits<char>, std::__1::allocator<char> >) in
libchemfiles.a(MMTF.cpp.o)
chemfiles::MOL2Format::read(chemfiles::Frame&) in
libchemfiles.a(MOL2.cpp.o)
...

C++: Classic undefined symbols for architecture error

Learning C++ lately, and I'm having trouble to compile my classes. I am currently getting the following obscure template error:
Undefined symbols for architecture x86_64:
"SmallWorld::AJV::validate(nlohmann::basic_json<std::__1::map, std::__1::vector, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, bool, long long, unsigned long long, double, std::__1::allocator, nlohmann::adl_serializer>*, nlohmann::basic_json<std::__1::map, std::__1::vector, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, bool, long long, unsigned long long, double, std::__1::allocator, nlohmann::adl_serializer>*)", referenced from:
SmallWorld::Map::(anonymous namespace)::readMap(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) in map.test.cpp.o
"std::__1::function<unsigned long (SmallWorld::Map::Graph<SmallWorld::Region>)> SmallWorld::Map::algorithm::dfs<SmallWorld::Region>(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, std::__1::function<bool (std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, std::__1::set<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::less<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > >&, std::__1::unordered_map<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::pair<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, std::__1::hash<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, std::__1::equal_to<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, std::__1::allocator<std::__1::pair<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const, std::__1::pair<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > > > const&)> const&)", referenced from:
creates_a_connected_graph_small_world_map_Test::TestBody() in map.test.cpp.o
"SmallWorld::Region::Region(nlohmann::basic_json<std::__1::map, std::__1::vector, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, bool, long long, unsigned long long, double, std::__1::allocator, nlohmann::adl_serializer>)", referenced from:
std::__1::shared_ptr<SmallWorld::Region> std::__1::shared_ptr<SmallWorld::Region>::make_shared<nlohmann::basic_json<std::__1::map, std::__1::vector, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, bool, long long, unsigned long long, double, std::__1::allocator, nlohmann::adl_serializer> const&>(nlohmann::basic_json<std::__1::map, std::__1::vector, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, bool, long long, unsigned long long, double, std::__1::allocator, nlohmann::adl_serializer> const&&&) in map.test.cpp.o
ld: symbol(s) not found for architecture x86_64
which can be simplified to:
Undefined symbols for architecture x86_64:
"SmallWorld::AJV::validate(nlohmann::json*, nlohmann::json*)", referenced from:
SmallWorld::Map::(anonymous namespace)::readMap(string const&, string const&) in map.test.cpp.o
"std::function<size_t(Graph<Region>)> SmallWorld::Map::algorithm::dfs<SmallWorld::Region>(string const&, std::function<bool (string const&, std::set<string> const&, std::unordered_map<string, string> const&)", referenced from:
creates_a_connected_graph_small_world_map_Test::TestBody() in map.test.cpp.o
"SmallWorld::Region::Region(nlohmann::json)", referenced from:
std::shared_ptr<SmallWorld::Region> std::shared_ptr<SmallWorld::Region>::make_shared<nlohmann::json const&&&) in map.test.cpp.o
ld: symbol(s) not found for architecture x86_64
Which to me seems like it is saying that the method bool AJV::validate(json* schema, json* data) does not exist on type AJV. However I have verified the common mistakes (different implementation from header declaration, different invocation from implementation), to no avail.
Here is the definition and implementation of the AJV class:
// AJV.h
#ifndef SMALLWORLD_AJV_H
#define SMALLWORLD_AJV_H
#include <nlohmann/json.hpp>
using nlohmann::json;
namespace SmallWorld {
class AJV {
public:
std::function<bool(json*)> compile(json* schema);
bool validate(json* schema, json* data);
json errors;
private:
json m_schema;
std::function<bool(json*)> m_validator;
};
};
#endif // SMALLWORLD_AJV_H
// AJV.cpp
#include <nlohmann/json.hpp>
#include "AJV.h"
using nlohmann::json;
namespace SmallWorld {
std::function<bool(json*)> AJV::compile(json* schema) {
return [](json* data){ return true; };
};
bool AJV::validate(json* schema, json* data){ return true; };
};
And here is the invocation:
//loader.cpp
json* readMap(const string& map_path, const string& schema_path) {
AJV ajv;
json* schema = readJSONFile(schema_path);
json* jmap = readJSONFile(map_path);
if(ajv.validate(schema, jmap)){
delete schema;
return jmap;
}else{
delete schema;
throw ajv.errors;
}
};
Setup:
OS: MacOS 10.13.3
C++ Version: 14
Compiler: g++ => Apple LLVM version 9.0.0 (clang-900.0.39.2)
Build manager: CMake 3.5.1
IDE: Atom IDE w/ linter-clang for linting (not really an IDE XD)
Additional Details
Compilation is done via command line: mkdirp build && cd build && cmake .. && make
File AJV.h is within source tree at the specified include path.
How can I solve this problem?
Cheers ☀️
When you register a project in CMake, you list both headers and source files. It will then deal with these as best it can for the respective IDE / build system that you tell it to use.
If you always have one header and one cpp file (there's no requirement to; you may find some objects are complex/large enough that you want to split it into multiple cpp files for your sanity) then you could list all your file names with no extension in the cmake and have it append the .cxx and .h to the end for you. This will leave you with just half the typing.
As an alternative there is a non-recommended route which is to to use the file command to scan the directory for files - but this is done only when cmake is run; and as such will not auto-update; leaving it possible to have a source tree that's building fine on one system; while not on another.

Memory leak when passing polymorphic unique_ptr as argument

Edit: To anyone reading this question for future use: the error had not to do with unique_ptr by any means. It was simply, as JoergB justly says in his answer, a mistake on my part to forget a virtual destructor for a base class.
After the occasional run-time crash, I figured my code was suffering from a severe case of memory-leak-itis. I ran my program with Valgrind and the doctor seems to agree: bytes are definitely lost. I can't for the life of me figure out where it goes wrong, though.
I managed to pin the leak down into happening in these three lines:
std::unique_ptr<Operator> pointer(new Operator{"left", "right"});
NodeSpace space; // The node space takes ownership over the operator
// When I comment out the following line, Valgrind reports nothing:
space.setNode("key", move(pointer));
In the first line a unique_pointer is created, holding an instance of the Operator class. The Operator internally looks like this:
class Operator : public Node {
public:
Operator(std::initializer_list<std::string> input_keys) {
input_nodes_.reserve(input_keys.size());
for_each(begin(input_keys), end(input_keys), [this](const string& key) {
input_nodes_[key] = nullptr;
});
}
// ...
private:
std::unordered_map<std::string, Node*> input_nodes_;
};
I pass in the unique_ptr r-value reference to the following function:
void NodeSpace::setNode(const std::string& key, std::unique_ptr<Node> node);
Because the node space takes over ownership of the passed-in node, it takes a unique_ptr by value (move semantics). Internally it stores the pointer in an std::map, but even if the function body is commented out, the memory leak still happens (which leads me to believe the problem is the node argument of the function call).
Anyone know remotely where the problem could be?
Sidenote: I'm not using shared_ptr, because the nodes can refer to each other in a cyclic manner. weak_ptr could be an option, but by construction of the system it is impossible for a node to exist when its owning nodespace does not anymore.
Valgrind output:
==83791== 112 (16 direct, 96 indirect) bytes in 1 blocks are definitely lost in loss record 606 of 794
==83791== at 0x100060ABD: malloc (vg_replace_malloc.c:274)
==83791== by 0x1000C9147: operator new(unsigned long) (in /usr/lib/libc++.1.dylib)
==83791== by 0x10000CB0F: std::__1::__hash_table<std::__1::pair<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, mimi::Node*>, std::__1::__unordered_map_hasher<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, mimi::Node*, std::__1::hash<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, true>, std::__1::__unordered_map_equal<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, mimi::Node*, std::__1::equal_to<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, true>, std::__1::allocator<std::__1::pair<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, mimi::Node*> > >::__rehash(unsigned long) (in ./test/mimi)
==83791== by 0x10000C684: std::__1::__hash_table<std::__1::pair<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, mimi::Node*>, std::__1::__unordered_map_hasher<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, mimi::Node*, std::__1::hash<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, true>, std::__1::__unordered_map_equal<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, mimi::Node*, std::__1::equal_to<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, true>, std::__1::allocator<std::__1::pair<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, mimi::Node*> > >::rehash(unsigned long) (in ./test/mimi)
==83791== by 0x100005D5A: mimi::Operator::Operator(std::initializer_list<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >) (in ./test/mimi)
==83791== by 0x100005984: mimi::Operator::Operator(std::initializer_list<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >) (in ./test/mimi)
==83791== by 0x10002E940: main (in ./test/mimi)
I also don't get why Valgrind seems to tell me the leak happens in the Operator constructor, even though the operator has already been constructed by the time NodeSpace::setNode() is called.
You don't show us key pieces of the code - the declaration of Node, in particular its destructor, parts of NodeSpace, in particular how it deletes Nodes, etc. But from your comment "Neither Node nor Operator have any destructor and copy/move constructor/assignment-operator", it appears that that is the problem.
If you maintain ownership of an Operator through a Node * or a unique_ptr<Node>, i.e. if you delete any derived objects through a Node *, Node must have a virtual destructor. If you don't declare and define one, it doesn't.
While the resulting behavior is undefined, the outcome typically is, that destructors of members of the derived class are not called. That matches your error message.