Here is the stack trace of a memory leak reported by xcode leak profiler: 0 libsystem_c.dylib malloc 1 libstdc++.6.dylib operator new(unsigned long) 2 libstdc++.6.dylib operator new[](unsigned long) 3 Diagnostics ibis::util::strnewdup(char const*) ./FastBit/src/util.cpp:1383 4 Diagnostics ibis::math::variable::variable(char const*) ./FastBit/src/qExpr.h:789 5 Diagnostics ibis::selectParser::parse() ./FastBit/selectParser.cc:252 6 Diagnostics ibis::selectClause::parse(char const*) ./FastBit/src/selectClause.cpp:107 7 Diagnostics ibis::selectClause::selectClause(char const*) ./FastBit/src/selectClause.cpp:17 8 Diagnostics ibis::table::select(std::vector<ibis::part const*, std::allocator<ibis::part const*> > const&, char const*, char const*) ./FastBit/src/filter.cpp:2659 9 Diagnostics ibis::mensa::select(char const*, char const*) const ./FastBit/src/mensa.cpp:566
The line number selectParser.cc:252 doesn't seem correct for me which doesn't make much sense, but the rest seem to line up fine. Digging into it a little, I fear that the bug is actually in the parser generator, but I'm not terribly familiar with how all of that is put together. Let me know if I can help at all. Thanks, Michael _______________________________________________ FastBit-users mailing list [email protected] https://hpcrdm.lbl.gov/cgi-bin/mailman/listinfo/fastbit-users
