Bei Aufruf von new wird das Programm beendet

Xin

GolanT schrieb:

getMaxString() ist nur eine Zählfunktion. Die greift nicht auf "buffer" zu. "buffer" wird erst mit dem Konstruktor "Parser(int size)" initialisiert. Bei Objekten die über den Default-Konstruktor erzeugt werden, wird "buffer" nicht benötigt.

Ich sehe hier nicht genug Informationen.

Wenn Du keinen Debugger zur Verfügung hast, der Dir sagt, warum das Programm aussteigt, schreib Printfs rein und zähle damit. Also 1, 2, 3, 4 usw ausgeben.
Wenn Du 1 und 2 ausgegeben wirst, weißt Du, dass der Fehler zwischen 2 und 3 liegt und verkleinerst die Abstände. Sobald Du die Funktion gefunden hast, die abschmiert, gehst Du da rein und machst das gleiche.

Ist die Letzte Anweisung in einer Funktion ein printf und die erste nach dem Funktionsaufruf und das printf in der Funktion wird gerunfen, das printf nach der Funktion nicht, dann hast Du Dir in der Funktion den Stack zerschossen.
Prüfe also nach, ob Du beispielsweise über Arraygranzen hinausgegangen bist.

GolanT

Okay, noch mal zum Anfang meiner Frage...
Ich weiß wo der Fehler liegt. Ich habe bereits mit Ausgaben gearbeitet und dabei festgestellt, dass das Programm immer wenn ein new Irgendwas[size], wobei size zur Laufzeit bestimmt wird, aufgerufen wird, einfach beendet wird. Es gibt keine Fehlermeldung bei der Ausführung. Das Programm hört einfach auf. Der Compiler ist mit dem Code zufrieden. Das Programm lief auch schon mal ohne Probleme. Erst seit dem ich die Klassen in Basisklassen und Ableitungen unterteilt habe, macht das Programm macken. Das es an dem new liegt weiß ich außerdem daher, das ich das erste Auftreten von new auskommentiert habe und das Programm dann beim nächsten new in einer ganz anderen Funktion beendet wurde.
Mein Problem ist jetzt, dass ich null Ahnung habe, warum er jetzt bei dem new-Operator zur Laufzeit (aber nicht beim compilieren) Probleme hat. Es muss wohl an der Vererbung liegen, ich weiß nur nicht warum. An der Arraygröße kann es auch nicht liegen, da es ja schon lief und die Größe aus Erfahrung nicht über 400 geht. Es wird auch vor der Initialisierung nie auf das Array zugegriffen.

OhneName

Dann fang an dein Programm so weit auszukommentieren bis der Fehler nicht mehr kommt. Und zeig uns dann den kürzestmöglichen kompilierbaren Code bei dem der Fehler immer noch auftritt. Dann kann man vielleicht eher was sagen.

GolanT

Das sind 10 Klassen + Sourcefiles. Was soll ich euch da schicken??? Kompilierbar ist das Programm ja auch. Es hört nur einfach auf. Wenn ich alle Zeilen, in denen ich ein Array mit new anlege auskommentiere ist das Programm eh nicht mehr lauffähig, da die Arrays ja benötigt werden.
Aber mal was anderes. Ich habe gerade ein Backup des Programms geladen, das lief... vorher... jetzt schmiert es auch ab, wenn zur Laufzeit Speicher angelegt werden soll. Ich hab langsam das Gefühl, dass es gar nicht am Programm liegt... Nur voran dann... Bin echt verzweifelt...

camper

Ein Schuss ins Blaue: mach den Destruktor Parser::~Parser virtuell.

Xin

GolanT schrieb:

Okay, noch mal zum Anfang meiner Frage...
Ich weiß wo der Fehler liegt. Ich habe bereits mit Ausgaben gearbeitet und dabei festgestellt, dass das Programm immer wenn ein new Irgendwas[size], wobei size zur Laufzeit bestimmt wird, aufgerufen wird, einfach beendet wird. Es gibt keine Fehlermeldung bei der Ausführung.

Welche Fehlermeldungen könnten denn überhaupt erwartet werden?
Einfach beendet kann viele Ursachen haben, dann kommt halt noch die Frage, welche Fehlermeldungen Dein OS dazu meldet.
Hast Du size im kritischen Moment mal ausgegeben?

GolanT schrieb:

Das Programm hört einfach auf. Der Compiler ist mit dem Code zufrieden. Das Programm lief auch schon mal ohne Probleme.

Gleicher Compiler, gleiche Plattform?
Ist nachvollziehbar, was geändert wurde? (Existiert ein Repository?)

GolanT schrieb:

Erst seit dem ich die Klassen in Basisklassen und Ableitungen unterteilt habe, macht das Programm macken. Das es an dem new liegt weiß ich außerdem daher, das ich das erste Auftreten von new auskommentiert habe und das Programm dann beim nächsten new in einer ganz anderen Funktion beendet wurde.

Wenn Du Dein Hauptprogramm auf den new-Aufruf beschränkst... was passiert?

GolanT schrieb:

Mein Problem ist jetzt, dass ich null Ahnung habe, warum er jetzt bei dem new-Operator zur Laufzeit (aber nicht beim compilieren) Probleme hat. Es muss wohl an der Vererbung liegen, ich weiß nur nicht warum. An der Arraygröße kann es auch nicht liegen, da es ja schon lief und die Größe aus Erfahrung nicht über 400 geht. Es wird auch vor der Initialisierung nie auf das Array zugegriffen.

Kann es sein, dass Du eine Exception erhältst, die Du nicht behandelst?

Ob Du virtuelle Destruktoren verwendest lohnt sich immer zu checken, aber an dem Fehler kann er eigentlich nicht schuld sein - außer Du rufst delete in einem Deiner Konstruktoren auf.
Bei 10 Klassen kann ich bei Bedarf mal drüber schauen, solltest Du den Fehler noch nicht gefunden haben.

Winn

GolanT schrieb:

Okay, noch mal zum Anfang meiner Frage...
Ich weiß wo der Fehler liegt. Ich habe bereits mit Ausgaben gearbeitet und dabei festgestellt, dass das Programm immer wenn ein new Irgendwas[size]...

Ich hatte einen solchen Fehler schon ein paar Mal und es lag immer daran, das ein Speicherbereich überschrieben wurde, welcher nicht reserviert war... new quittiert Dir den Dienst, wobei dieser Fehler je nach Plattform (Win, Unix, Mac) unterschiedlich quittiert wird...

Suche mal nach "myString = new char[strlen(CopyString)+1]" - die "+1" ist extrem wichtig, weil sonst bei strcpy oder strcat trotzdem und unerlaubterweise eine "\0" angehängt wird und fertig ist Dein Pufferüberlauf.

GolanT

Danke für die vielen Anregungen!

Ich denke nicht mehr, dass es am Programm liegt.
Das Programm soll zwei Dateien miteinander vergleichen (wie is erstmal egal) und hat in der Rohfassung (also ohne übersichtliche Klassenaufteilung) immer super funktioniert. Dabei habe ich zum Test immer die gleichen beiden Dateien genutzt.
Aus einem mir unerfindlichen Grund, will das Programm (auch in seiner Rohfassung) diese Dateien nicht mehr bearbeiten. Es öffnet sie und macht auch die ersten Anweisungen, aber sobald halt eine Stelle kommt, an der mittels new-Operator Speicher reserviert werden soll, springt das Programm raus. Nehme ich zwei andere Dateien (gleichen Typs) geht's wieder.
Falls dazu noch jemand eine Idee hat, immer her damit. Allen anderen vielen Dank für die Antworten.

Simon2

schonmal versucht, irgendwelche exceptions zu fangen und auszugeben ?

Winn

GolanT schrieb:

Danke für die vielen Anregungen!
Falls dazu noch jemand eine Idee hat, immer her damit. Allen anderen vielen Dank für die Antworten.

Ich verweise nochmal auf meinen Beitrag... die daran anschließenden Fehler sind vielfältig, weil halt unerlaubt im Speicher geschrieben wird und der ist bekanntlich seltens gleich in Benutzung...

GolanT schrieb:

Ich denke nicht mehr, dass es am Programm liegt.

ich würde ja mein linkes bein darauf verwetten, dass es eben doch am programm liegt. du beschreibst typisches verhalten bei kaputtem heap, und den macht mit sicherheit dein programm kaputt.
erster schritt: reduziere das programm auf das allernotwendigste, bis der fehler nicht mehr auftritt. wenn du das nicht tun willst, kann dir hier keiner weiterhelfen.

Xin

wettkönig schrieb:

GolanT schrieb:

Ich denke nicht mehr, dass es am Programm liegt.

ich würde ja mein linkes bein darauf verwetten, dass es eben doch am programm liegt.

Ich verwette aus Prinzip keine Körperteile und aus Anstand keine Verwandten, aber wäre mit 50 Euro dabei.

GolanT

Hmmm... ich bin ja für alles offen und ein paar extra Gliedmaßen sind sicher nicht zu verachten :p

du beschreibst typisches verhalten bei kaputtem heap, und den macht mit sicherheit dein programm kaputt.

Dann erkläre mir bitte "kaputter Heap". Wie soll ich da was kaputt machen, wenn ich einen Char-Zeiger anlege und mit diesem zur Laufzeit ein Char-Array erzeuge. Das Programm endet ja immer, beim anlegen des Arrays. Wie kann ich da unerlaubt im Speicher schreiben. Ist die Vorgehensweise nicht dazu da, dynamisch Speicher anzulegen?!
Und wie gesagt, warum verhält sich das Programm nur bei zwei Dateien, die es vorher immer angenommen hat, so und bei anderen Dateien gleichen Formats läuft es?
Das Array ist mit 400 Byte auch nicht so wuchtig, dass es daran liegen kann.
Also warum sollte ich bei einer Datei Speicher anlegen dürfen und bei einer anderen nicht?
Und nu gebt's mir!

OhneName

Lad einfach mal deinen gesamten Quelltext bei irgendnem One-Click-Hoster wie z.B. Rapidshare hoch und gib uns den Link. Es wird sich schon jemand finden, der dein Programm mal ausprobiert und dir bei der Fehlersuche hilft.

MFK

GolanT schrieb:

Dann erkläre mir bitte "kaputter Heap". Wie soll ich da was kaputt machen, wenn ich einen Char-Zeiger anlege und mit diesem zur Laufzeit ein Char-Array erzeuge. Das Programm endet ja immer, beim anlegen des Arrays. Wie kann ich da unerlaubt im Speicher schreiben. Ist die Vorgehensweise nicht dazu da, dynamisch Speicher anzulegen?!

Der Fehler liegt nicht an der Stelle, an der dein Programm abstürzt. Wenn der Rest deines Programms so unsauber ist wie das, was du gezeigt hast, hast du mit hoher Wahrscheinlichkeit irgendwo mindestens einen Fehler, der das auslösen kann.

Und wie gesagt, warum verhält sich das Programm nur bei zwei Dateien, die es vorher immer angenommen hat, so und bei anderen Dateien gleichen Formats läuft es?

Tja, so ist das bei undefiniertem Verhalten. Du kannst dich auf nichts verlassen, nicht mal darauf, dass es nicht manchmal funktioniert.

asc

GolanT schrieb:

Dann erkläre mir bitte "kaputter Heap". Wie soll ich da was kaputt machen, wenn ich einen Char-Zeiger anlege und mit diesem zur Laufzeit ein Char-Array erzeuge. Das Programm endet ja immer, beim anlegen des Arrays.

Das mag sein das es erst dort abstürzt, wenn du aber vorher schon wild mit Zeigern um dich schießt und dir ggf. den Aufrufstack oder ähnliches durcheinander bringst kann auch ein solches Verhalten eintreten.

Aber mit den paar Information die du bislang rausgerückt hast, kommt mir eine Fehlersuche in etwa genauso schwer vor wie als ob man eine Arztdiagnose über ein Foto haben will (Und nur wenige Krankheiten lassen sich so eingrenzen)...

Entweder du willst mit deinem Problem alleine bleiben, oder wir benötigen mehr "Input" (z.B. mehr Code) oder du versuchst schlicht und ergreifend erstmal das was schon vorgeschlagen wurde: Ausdokumentieren und nach und nach wieder aktivieren um den Fehler besser einzugrenzen.

cu André

pumuckl

Nunja, es gilt immernoch: wenn du geizig mit deinem Code bleibst und uns nicht etwas mehr Kontext gibst (aus dem aktuellen kann man keine Fehlerursache erkennen) bleibt uns nur, ins Blaue zu raten (Vielleicht hat jemand an deinem Compiler rumgespielt und unter ganz bestimten Bedingungen new mit[] exit ersetzt, man kann ja nie wissen).
Wie schon gesagt wurde, wenn du wirklich Hilfe suchst, ist es am Besten, wenn du deinen Code so weit wie moeglich reduzierst, so dass er aber trotzdem das Problem noch reproduzieren kann. Dann kannst du ihn hier posten, die Rahmenbedingungen angeben (Compiler, Plattform, beutzte Eingabe/Dateien etc.), und wir koennen schauen ob sich das Problem bei usn reproduzieren laesst udn evtl rausfinden wo der Fehler steckt.

GolanT

Natürlich bin ich für jede Hilfe offen. Deswegen bin ich ja hier.
Okay, ich werd mal versuchen den Code hoch zu laden und gebe euch dann den Link.

Bis gleich

GolanT

Okay, der Code ist oben.
Im Ordner ist noch eine kleine Infodatei zum Thema Compiler, Programmaufruf, etc.
Hier der Link: http://hometown.aol.de/BerlinHunters/index.htm

OhneName

Ich konnte deine Beobachtungen bei mir nachvollziehen. Mit version1 und version2 funktionierts, mit version1ESB und version2ESB nicht. Einen Fehler bei dem du recht früh in unerlaubte Speicherbereiche schreibst habe ich recht schnell gefunden. Nachdem ich ihn behoben habe lief das Programm auch mit version1ESB und version2ESB korrekt zu Ende. Es geht um die markierten Stellen.

char* createFilenameTXT(string &file){
      string txtfile, txt = ".txt";
      int namesize;
      char* txtfilename;

      txtfile=file;
      txtfile.append(txt);
      namesize=txtfile.length();
      txtfilename=new char[namesize + 1]; // <-- hier + 1
      for(int i=0; i<namesize; i++){
         txtfilename[i]=txtfile[i];
      }//end for
      txtfilename[namesize]='\0'; // <-- sonst schreibst du hier über den bereich hinaus
      return txtfilename;
}//end createFilenameTXT

char* createFilenameREC(string &file){
      string recfile, rec = ".srec";
      int namesize;
      char* recfilename;

      recfile=file;
      recfile.append(rec);
      namesize=recfile.length();
      recfilename=new char[namesize + 1]; // <-- hier das selbe
      for(int i=0; i<namesize; i++){
         recfilename[i]=recfile[i];
      }//end for
      recfilename[namesize]='\0'; // <-- und hier auch wieder
      return recfilename;
}//end createFilenameREC