Since a few days I'm getting a warning msg while debugging. I can't find where it comes from. I was googleing already and found things like it's because I have a static variable. But taking it out doesn't change anything.
This is the main
method:
int main(int argc, char* argv[]) {
if (argc != 2) {
cout << "ERROR: Wrong amount of arguments!...\n"
<< endl;
cout << "\n" << "Programm closed...\n\n" << endl;
cin.ignore();
exit(1);
return 0;
}
cout << "argv[1] " << argv[1] << endl;
GenericCommandConverter a(argv[1]);
a.getCommandsFromCSV();
cout << "\n" << "Programm finished...\n\n" << endl;
return 0;
}
The code where it occures first time:
void GenericCommandConverter::getATCommandsFromCSV() {
cout << "+++++++++++getCommandsFromCSV) started++++++++++++++" << endl;
string filename_csv = "test.csv";
string commands = "";
int pos_start = 0;
int pos_end = 0;
int substrLength = 0;
int separator_count = 0;
char c;
vector<string> lines;
vector<string> commandList;
vector<unsigned int> parameterPositionList;
vector<vector<string> > linesSeparated;
vector<vector<string> > part1_input;
vector<vector<string> > part2_output;
vector<map<vector<string> , vector<string> > > listedParameterMap;
ifstream csvFile;
csvFile.open(filename_csv.c_str(), ios_base::in);
cout << "i'm starting getCommandsFromCSV()...\n" << endl;
/**
* STEP 1
* Putting input text file into a string
*/
if (csvFile.is_open()) {
while (!csvFile.eof()) { // <------- warning occurs here!
csvFile.get(c);
commands += c;
}
...
}
Warning:
[New Thread 2000.0x11bc]
warning: can't find linker symbol for virtual table for
`std::less<std::vector<std::basic_string<char, std::char_traits<char>,
std::allocator<char> >, std::allocator<std::basic_string<char,
std::char_traits<char>, std::allocator<char> > > > >' value
Does anyone know why this is comming? It comes with each line until it started. It filles the console so much that it's not possible to debug. Another maybe important info on standalone mode this error is not displayed.
I really would appreciate some help!
EDIT: header file
#ifndef CommandConverter_H_
#define CommandConverter_H_
#include <stdio.h>
#include <stdlib.h>
#include <fstream>
#include <iostream>
#include <sstream>
#include <string>
#include <iosfwd>
#include <map>
#include <vector>
#include <cstdio>
using namespace std;
class CommandConverter {
public:
CommandConverter(char* file);
virtual ~CommandConverter();
void printConvertedTraceByPage(vector<string> lines);
map<string, vector<map<vector<string> , vector<string> > > > csvMap;
static const int MAX_SIZE = 5;
void getATCommandsFromCSV();
string readTxtFile();
vector<string> splitIntoLines(const char* trace);
vector<string> convert(vector<string> fileInLines);
bool commandAvailable(const char* l, int pos, const char* s);
void error(const char* p, const char* p2);
void printCSV();
// opened in constructor; closed in destructor
ifstream myfile;
string filename;
string trace_raw;
};
#endif /* CommandConverter_H_ */
Answering the question title, but not the OP's question (since a web search led me here): another source of this same message is that gdb can get confused by not-yet-initialized variables.
Naturally, you shouldn't have uninitialized variables, but in my case gdb attempts to show function local variables even before they are declared/initialized.
Today I'm stepping through another developer's gtest case and this message was getting dumped to output every time the debugger stopped. In this case, the variable in question was declared on ~line 245, but the function started on ~line 202. Every time I stopped the debugger between these lines, I received the message.
I worked around the issue by moving the variable declaration to the top of the function.
For reference, I am testing with gdb version 7.11.1 in QtCreator 4.1.0 and I compiled with g++ version 5.4.1
The message comes from this code in
gdb/gnu-v3-abi.c
:Now, I am fairly sure
std::less
isn't supposed to have a virtual table in the first place, so it's likely that GDB is confused.You'd need to verify that the problem exists with the latest GDB, and file a bug.
Since this only started recently, have you upgraded your GCC, GDB, or changed compilation flags?