000
20.09.2006, 17:07 Uhr
flappinski
|
Hallo Leute,
ich bin weiter auf der Suche nach Speicherlecks. Mein Programm läuft zwar sauber, aber valgrind findet noch, und ich habe das dumpfe Gefühl, dass es mit mehr Daten wieder zu Problemen kommen wird.
Die meisten Lecks finde und korrigiere ich selber. Hier eine Funktion, bei der ich allerdings das Problem nicht erkenne. Virtual, Du brauchst wahrscheinlich wieder nur einen Blick:
| C++: |
void read_file_exact (string inf_datei, vector<string> &line_vec) {
stringstream log_stream("\n");
ifstream In(inf_datei.c_str(),ios::binary); // Datei oeffnen und Stream auf In
if (!In) { // falls Datein nicht zu oeffnen, Abbruch
log_stream << STERNE << "Error while opening "<< inf_datei.c_str() << STERNE << " -> Abort\n\n\n";
abbruch(log_stream);
}
log_stream << "\nread " << inf_datei << "..." << endl;
print_stream(log_stream);
string line;
int tabzz=0,anz13=0;
bool first=0;
while(getline(In, line)){
if (!first) { // check TABs
tabzz= count(line.begin(),line.end(),9);
first=1;
}
else if (tabzz!=count(line.begin(),line.end(),9)) {
log_stream << "bad fieldnumber on "
<< inf_datei.c_str() << ", row: " << line_vec.size()
<< " -> Abort" << endl;
abbruch(log_stream);
}
if (line.find(13,0)!=string::npos){
line.erase(remove(line.begin(),line.end(),13),line.end()); //entferne ASCII 13
anz13++;
}
line_vec.push_back(line); // Add the line to vector ***********************************
}
if (anz13!=0) {
log_stream << anz13 << " ASCII 13-Signs (Windows-Line_Feed) found and deleted. "<< endl;
print_stream(log_stream);
}
log_stream << "\nfinished." << endl;
print_stream(log_stream);
In.close();
}
|
hier die Ausgabe von valgrind:
| Code: |
==17362== 172992 bytes in 152 blocks are definitely lost in loss record 3 of 5
==17362== at 0x1B8FFC42: operator new(unsigned) (in /usr/lib/valgrind/vgpreload_memcheck.so)
==17362== by 0x1B9B364A: std::string::_Rep::_S_create(unsigned, unsigned, std::allocator<char> const&) (new_allocator.h:88)
==17362== by 0x1B9B4707: std::string::_Rep::_M_clone(std::allocator<char> const&, unsigned) (basic_string.tcc:602)
==17362== by 0x1B9B5016: std::string::string(std::string const&) (basic_string.h:222)
==17362== by 0x804FCDC: __gnu_cxx::new_allocator<std::string>::construct(std::string*, std::string const&) (new_allocator.h:104)
==17362== by 0x8050B9C: std::vector<std::string, std::allocator<std::string> >::_M_insert_aux(__gnu_cxx::__normal_iterator<std::string*, std::vector<std::string, std::allocator<std::string> > >, std::string const&) (vector.tcc:279)
==17362== by 0x8050DFA: std::vector<std::string, std::allocator<std::string> >::push_back(std::string const&) (stl_vector.h:605)
==17362== by 0x804C231: read_file_exact(std::string, std::vector<std::string, std::allocator<std::string> >&) (Filefunc.cpp:331)
==17362== by 0x8069A98: turn_ptgt(NSwitch&) (NTurn.cpp:84)
==17362== by 0x8071155: main (WG_Permer_main.cpp:515)
==17362==
|
Ich habe die Zeile 331 aus Filefunc.cpp ("line_vec.push_back(line);") mit Sternen markiert, dann kann man sich besser zurechtfinden. Die 152 Blocks passen zu den 152 Zeilen der Datei. Wenn diese jedoch wirklich "verloren" gehen, kann das bei anderen Daten zu jeder Menge Holz führen....
Viele Grüsse und danke im Vorraus,
Stephan
Dieser Post wurde am 20.09.2006 um 17:08 Uhr von flappinski editiert. |
