Herzlich Willkommen, lieber Gast!
  Sie befinden sich hier:

  Forum » C / C++ (GNU/Linux, *NIX, *BSD und Co) » std::bad_alloc ?

Forum | Hilfe | Team | Links | Impressum | > Suche < | Mitglieder | Registrieren | Einloggen
  Quicklinks: MSDN-Online || STL || clib Reference Grundlagen || Literatur || E-Books || Zubehör || > F.A.Q. < || Downloads   

Autor Thread - Seiten: [ 1 ] [ 2 ] > 3 < [ 4 ] [ 5 ]
020
08.09.2006, 17:05 Uhr
Blubber2063



Hmmm, naja gdb ist doch eigentlich nicht schlecht. Wenn du da soviele Schleifenanweisungen hast solltest du vielleicht auch mal auf evtl. logische Fehler achten und auf den Speicherverbrauch deiner Applikation. Aber wenn du nen guten visuellen Debugger brauchst nimm den von Visual Studio.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
021
08.09.2006, 17:10 Uhr
Bruder Leif
dances with systems
(Operator)


Moin!

Wenns gar nicht anders geht, setz zwischen ALLE Befehle jeweils ein cout << [Zahl] << endl, für jedes Auftreten natürlich eine andere Zahl einsetzen. Dann das Programm laufen lassen und die letzte ausgegebene Zahl sagt Dir, wo der Fehler aufgetreten ist...

Das wäre die Arme-Leute-Alternative zu gdb und Co.
--
Mit 40 Fieber sitzt man nicht mehr vor dem PC.
Man liegt im Bett.
Mit dem Notebook.

Dieser Post wurde am 08.09.2006 um 17:11 Uhr von Bruder Leif editiert.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
022
08.09.2006, 17:18 Uhr
virtual
Sexiest Bit alive
(Operator)


Ich glaub ich versteh das Problem nicht? - Geht das denn nicht mit dem set_new_handler? - Dann siehst Du doch im gdb am Stacktrace sofort wo es geknallt hat, ganz ohne weitere Änderungen am Code?
--
Gruß, virtual
Quote of the Month
Ich eß' nur was ein Gesicht hat (Creme 21)
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
023
08.09.2006, 17:26 Uhr
Bruder Leif
dances with systems
(Operator)


Ich schätze mal, das eigentliche Problem liegt in der Bedienung des gdb, bzw. im Eben-das-noch-nicht-können...
--
Mit 40 Fieber sitzt man nicht mehr vor dem PC.
Man liegt im Bett.
Mit dem Notebook.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
024
11.09.2006, 11:42 Uhr
flappinski



Hallo Leute,
ich mal wieder....
Inzwisschen kann ich den gdb, bzw. ddd etwas bedienen und habe auch schon den set_new_handler implementiert. Nun kommt die Fehlermeldung bei verschiedenen Variablen, und bei diesen sehe ich eigentlich kein Probelm. Einmal ist es eine einfache Übergabe eines Streams an eine Datei (und zwar in Zeile 512):


C++:
506 void stream_to_file_app (string out_datei, stringstream &temp_stream) {
507     ofstream Out(out_datei.c_str(),ios::app);            // Datei oeffnen und Stream auf Out
508     if (!Out) {                                 // falls Datein nicht zu oeffnen, Abbruch
509         cout << STERNE << " Error while opening file "<< out_datei.c_str() << STERNE << "-> Abort\n\n\n";
510         exit(1);
511     }
512     Out << temp_stream.str();
513     Out.close();
514 }




einmal das aufsummieren bei eines vectors (hier Zeile 68):


C++:
  62  vector<double> sum_vec(const vector <double> &col1, const vector <double> &col2,  const vector <double> &col3){
  63    vector<double> result;
  64   result.clear();
  65   int size1=col1.size();
  66   int size2=col2.size();
  67   int size3=col3.size();
  68   result.reserve(size1+ size2 + size3);
  69   for (int zz=0; zz < size1 ; zz++){
  70     result.push_back(col1[zz]);
  71   }
  72   for (int zz=0; zz < size2 ; zz++){
  73     result.push_back(col2[zz]);
  74   }
  75   for (int zz=0; zz < size3 ; zz++){
  76     result.push_back(col3[zz]);
  77   }
  78   return result;
  79 }
  80



seht ihr hier direkt Fehlerquellen?
Vielen Dank,
ich muss ehrlich sagen, ich verliere langsam die Lust an der Suche....
Stephan

Dieser Post wurde am 11.09.2006 um 11:43 Uhr von flappinski editiert.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
025
11.09.2006, 11:46 Uhr
Bruder Leif
dances with systems
(Operator)


Kommt drauf an. Welche Werte haben die jeweils angesprochenen Variablen?
--
Mit 40 Fieber sitzt man nicht mehr vor dem PC.
Man liegt im Bett.
Mit dem Notebook.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
026
11.09.2006, 11:49 Uhr
flappinski



size1 bis 3 sind zwischen 0 und ca 100 gross, soll ich da mal ein assert reinsetzten?
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
027
11.09.2006, 12:49 Uhr
virtual
Sexiest Bit alive
(Operator)


In Zeile 506:
Da solltest Du den ersten Parameter als const string&, nicht als string übergeben. Sonst wird eben ne copy angelegt, was auch nicht ganz so dolle ist. (Immerhin hast Du ja ein Speicherproblem). Wenn Du das öfters machst, also an verschiedenen Stellen, dann kann schon was zusammen kommen.

Zeile 512:
Im ungünstigesten Fall hast Du durch den Aufrug der .str() Method den gesamten Dateiinhalt temp. zweimal im Speicher. Speicherschonender wäre:

C++:
std::copy(std::istream_iterator<char>(temp_stream),
    std::istream_iterator<char>(),
    std::ostream_iterator<char>(Out));




Zeile 62-80:
Wenn der Compiler nicht ausreichend optimiert, dann hast Du hier auch ein Problem mit temp. doppelt gehaltenen Objekten. Das kannst Du zb so umgehen:


C++:
void sum_vec(vector <double>& result, const vector <double> &col1, const vector <double> &col2,  const vector <double> &col3){
  65   int size1=col1.size();
  66   int size2=col2.size();
  67   int size3=col3.size();
  68   result.reserve(size1+ size2 + size3);
        std::copy(col1.begin, col1.end(), std::back_inserter(result)); // Alternative zur Schleife
        std::copy(col2.begin, col2.end(), std::back_inserter(result)); // Alternative zur Schleife
        std::copy(col3.begin, col3.end(), std::back_inserter(result)); // Alternative zur Schleife
  79 }


Die Aufrufe der Funktion sind entsprechend anzupassen.

Bei der sum_vec Routine finde ich, daß bereits schon davor irgendwo ne Menge Speicher "verloren" gegangen sein muß. Selbst wenn size1 - size3 jeweils 1000 Groß wären, reden wir hier über Speicher von 24-30 KB der zur Rede steht, also eigentlich ein Witz.

Anders sieht es bei stream_to_file_app Routine aus, welche - wenn Die Datei hinreichend groß ist - auch hinreichend Probleme machen kann.

Ich würde mal das Programm mit valgrind checken, vor allem mit kleineren Datenmengen, welche es nicht direkt zum Absturz bringen: vielleicht hast Du ja nette Speicherlöcher drin.
--
Gruß, virtual
Quote of the Month
Ich eß' nur was ein Gesicht hat (Creme 21)
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
028
11.09.2006, 13:35 Uhr
flappinski



@virtual:
Vielen Dank, das ist ja sehr ausführlich, ich werde mich mal an die Ausarbeitung Deiner Vorschläge machen.
Nur soviel zur Vorinfo: Der Abbruch scheint zwar immer mit diesen beiden Funktionen zusmammenzuhängen, aber tritt nach unterschiedlich weitem Programmdruchlauf auf. Der Unterschied ist zwar minimal (zwischen 180000 und 190000 besrbeiteten Zeilen, aber spürbar, und zwar bei haargenau gleichem Datensatz, und ich habe keinerlei parallel laufende Prozesse laufen. Gibt es denn noch irgendwelche Limits, die ich bei der Programmausführung habe?
Ausgabe von ulimit -a:

core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
file size (blocks, -f) unlimited
max locked memory (kbytes, -l) 32
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
stack size (kbytes, -s) unlimited
cpu time (seconds, -t) unlimited
max user processes (-u) 262144
virtual memory (kbytes, -v) unlimited

2) Die datei in stream_to_file_app ist tatsächlich riesig (bis zu 5 GB). Aber gerade deshlab schreibe ich sie sequenziell, versuche also, die Information NICHT im Speicher zu behalten. Was macht denn die Dateigrösse so problematisch?
Naja, ich berichte, wenn ich die anderen Sachen umgesetzt habe, danke,
Stephan

p.s. auf jeden Fall schon mal vielen Dank, dass ich endlich verstanden habe, warum so viele immer mit const übergeben..... (ich dachte immer, solange ich nicht die Variable verändere, ist das egal)

Dieser Post wurde am 11.09.2006 um 13:38 Uhr von flappinski editiert.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
029
11.09.2006, 16:57 Uhr
virtual
Sexiest Bit alive
(Operator)


Hast du das Programm denn schon mal mit kleineren Daten gefüttert, so daß es nicht aus dem Speicher läuft? - Wenn Du entsprechende Daten hast, dann starte es doch mal mit valgrind.
--
Gruß, virtual
Quote of the Month
Ich eß' nur was ein Gesicht hat (Creme 21)
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
Seiten: [ 1 ] [ 2 ] > 3 < [ 4 ] [ 5 ]     [ C / C++ (GNU/Linux, *NIX, *BSD und Co) ]  


ThWBoard 2.73 FloSoft-Edition
© by Paul Baecher & Felix Gonschorek (www.thwboard.de)

Anpassungen des Forums
© by Flo-Soft (www.flo-soft.de)

Sie sind Besucher: