Zugriffsverletzung bei ..
-
Danke!
Und wo genau sehe ich diesen Nptr?
-
Die Frage ist eher, wieso du versucht etwas in einer IDE auszuführen, von dem du keine Ahnung hast, da du es auch nicht selber geschrieben hast.
Kann das keiner machen, der das auch gelernt hat? Mit deinem Wissenstand wird das leider nie was. Spar dir die Zeit.
-
Jede einzelne Zeile habe ich selber geschreiben...
-
Komisch123 schrieb:
das Programm ist mittlerweile zu groß um zu erklären worum es genau geht.
Dann entferne solange Teile von deinem Programm, die den Fehler nicht verschwinden lassen, bis es nicht mehr zu gross ist.
-
^ Das ist ja eben das Problem... das geht so nicht.
Ich hab zwei Klassen die eine Klasse ist für die Kommunikation zuständig die andere Klasse dafür die ganzen Sachen auf die Festplatte zu schreiben. Und es gibt mehrer Threads für jede Verbindung einen.
Dafür übergibt man dem Konstruktor der Klasse "auf Festplatte" schreiben die Daten und der soll die Daten in ein File schreiben.
Was an sich im Grundgerüst alles gut funktioniert hat.Nun habe ich ein Protokol geschrieben mit 3 Wege Handshake, wie die Header aussehen usw..
Wenn ich den Konstruktor zum Daten schreiben nun aufrufen zb. ganz am Anfang der Komunikationsklasse zum testen, so bricht das Programm beim Empfangen des zweiten Packates nach dem Handshake ab
.Wird der Konstruktor zum schreiben der Daten, an richtiger Stelle aufgerufen so tritt der Fehler auf bei file.open in der "auf Festplatte" Klasse auf.
Naja tolle Fehler eben
-
TGGC schrieb:
Komisch123 schrieb:
das Programm ist mittlerweile zu groß um zu erklären worum es genau geht.
Dann entferne solange Teile von deinem Programm, die den Fehler nicht verschwinden lassen, bis es nicht mehr zu gross ist.
Ok, da musste ich kurz schmunzeln aber mal zurück zum Thema.
Du weißt was ein Nullpointer ist?Du hast irgendwo eine Pointer der auf keine "Resource" zeigt und den du mit * dereferenzierst wie manni schon gesagt hat.
Die IDE sagt Dir für gewöhnlich wo genau ansonsten kannst du auch in den Funktionen die gerade ausgeführt werden breakpoints setzen bis zu dem Punkt an dem das Problem auftritt.
-
Zugriffsverletzung beim Lesen an Position 0x00000000
Hieran sieht man schon mal ganz deutlich, dass Du einen Nullzeiger dereferenzierst.
Gehe mit dem Debugger durch und prüfe, ob die Zeiger alle gültige Werte haben.
Und vermeide Zeiger wo es geht
-
wenn Du Dein Programm in der IDE im Debugger laufen laesst und es stuerzt ab, kannst Du am callstack ("Aufrufstapel") sehen, in welcher Funktion/Methode das passiert ist. Doppelklick darauf bringt Dich an die Zeile wo es passiert.
2. Tip: Du solltest vielleicht mal probieren die einzelnen Threads erst mal single threaded fehlerfrei zum Laufen zu bringen.
-
Ruvi schrieb:
TGGC schrieb:
Komisch123 schrieb:
das Programm ist mittlerweile zu groß um zu erklären worum es genau geht.
Dann entferne solange Teile von deinem Programm, die den Fehler nicht verschwinden lassen, bis es nicht mehr zu gross ist.
Ok, da musste ich kurz schmunzeln aber mal zurück zum Thema.
Du weißt was ein Nullpointer ist?Du hast irgendwo eine Pointer der auf keine "Resource" zeigt und den du mit * dereferenzierst wie manni schon gesagt hat.
Die IDE sagt Dir für gewöhnlich wo genau ansonsten kannst du auch in den Funktionen die gerade ausgeführt werden breakpoints setzen bis zu dem Punkt an dem das Problem auftritt.
P.S.: Wie kannst Du das alles geschrieben haben ohne zu wissen wie man so einen Fehler ordentlich debuggt?
Nee so einfach ist der Fehler nicht zu finden.
Fehler tritt zb. hier auf:
file.open(label_file,ios::out | ios::in | ios::app);label_file ist aber gültig, und wenn man in die Fkt. reingeht ist _MyFile eben NULL. Aber darauf habe ich keinen Einfluss ?!
-
... Dann verfolg dein Programm-Fluss und schau, wo label_file NULL wird? Die wird nicht auf magische Art und Weise auf einmal ungültig.
-
Zudem funktioniert die Funktion mal schon mal nicht. Auch wenn ich lable_file hardcodiere geht es einmal und eben jetzt nicht mehr.
-
Komisch123 schrieb:
Nee so einfach ist der Fehler nicht zu finden.
Fehler tritt zb. hier auf:
file.open(label_file,ios::out | ios::in | ios::app);label_file ist aber gültig, und wenn man in die Fkt. reingeht ist _MyFile eben NULL. Aber darauf habe ich keinen Einfluss ?!
label_file ist ein std::string?! und wenn du einen breakpoint auf diese Zeile setzt: file.open(label_file,ios::out | ios::in | ios::app); siehst du im debugger, dass label_file noch gültig ist?
Bist Du dir da sicher?
-
Oh Man schrieb:
... Dann verfolg dein Programm-Fluss und schau, wo label_file NULL wird? Die wird nicht auf magische Art und Weise auf einmal ungültig.
Das hat nichts mit label_file zutun weil der Fehler mal hier mal da auftaucht auch wenn label_file hardcodiert wird ist es egal. Auch wenn ich gar keine var.. Die Fehler tretten in Fkts auf die ich aufrufe und absolut keinen Zugriff habe.
-
Die Behauptung, dass eine Funktion der Standardbibliothek nicht funktioniert halte ich bestenfalls für gewagt.
EDIT:
Solche Fehler passieren bei undefiniertem Verhalten. Höchstwahrscheinlich hast Du irgendwo in der nähe des Objekts file Speicher kaputtgeschrieben.
-
Ruvi schrieb:
Komisch123 schrieb:
Nee so einfach ist der Fehler nicht zu finden.
Fehler tritt zb. hier auf:
file.open(label_file,ios::out | ios::in | ios::app);label_file ist aber gültig, und wenn man in die Fkt. reingeht ist _MyFile eben NULL. Aber darauf habe ich keinen Einfluss ?!
label_file ist ein std::string?! und wenn du einen breakpoint auf diese Zeile setzt: file.open(label_file,ios::out | ios::in | ios::app); siehst du im debugger, dass label_file noch gültig ist?
Bist Du dir da sicher?
Eigentlich schon:
http://www.pic-upload.de/view-26753197/1.jpg.html
http://www.pic-upload.de/view-26753196/2.jpg.html
-
LordJaxom schrieb:
Die Behauptung, dass eine Funktion der Standardbibliothek nicht funktioniert halte ich bestenfalls für gewagt.
EDIT:
Solche Fehler passieren bei undefiniertem Verhalten. Höchstwahrscheinlich hast Du irgendwo in der nähe des Objekts file Speicher kaputtgeschrieben.
Da hast du mich falsch verstanden! Die Funktioniert zu 1000% irgendwas stimmt mit meinem Code nicht und das mit dem Speicher Kaputt schreiben kann sehr gut sein! Nur wie kriege ich raus wo ich ihn kaputtschreibe?!
-
Komisch123 schrieb:
Das hat nichts mit label_file zutun weil der Fehler mal hier mal da auftaucht auch wenn label_file hardcodiert wird ist es egal. Auch wenn ich gar keine var.. Die Fehler tretten in Fkts auf die ich aufrufe und absolut keinen Zugriff habe.
Ok, interessant.
Was treiben denn deine anderen Threads die da noch so unterwegs sind?
Hast Du irgendwo native C-Arrays als Buffer die unter Umständen "überlaufen" könnten?
-
Das Bild ist entstanden bevor er in die Fkt file.open springt und den Fehler ausgibt. Springt er in die Fkt kommt es zum runtime Err wird jedoch trotzdem das File erzeugt sieht man unten im Bild 13_10.txt.
-
Ruvi schrieb:
Komisch123 schrieb:
Das hat nichts mit label_file zutun weil der Fehler mal hier mal da auftaucht auch wenn label_file hardcodiert wird ist es egal. Auch wenn ich gar keine var.. Die Fehler tretten in Fkts auf die ich aufrufe und absolut keinen Zugriff habe.
Ok, interessant.
Was treiben denn deine anderen Threads die da noch so unterwegs sind?
Hast Du irgendwo native C-Arrays als Buffer die unter Umständen "überlaufen" könnten?Naja also die Idee vom Programm ist, ich habe mehrer Server auf die ich mich verbinden muss. Dafür erzeuge ich jeweils einen Client in einem Thread diese sollen "parallel" auf die Server zugreifen Kommunizieren und Daten auf die Festplatte schreiben die sie von den Servern erhalten.
Das ich irgendwo Buffer überläufe haben kann ist durchaus möglich! Wie such ich am besten solche Fehler?!Danke vielmals!!
Gruß
-
Moment, ich glaube fstream ist nicht thread-safe.
Ich bin mir jetzt nicht 100% sicher aber es kann sein, dass du es mit einem Mutex schützen musst.Wenn mehrere deiner Threads gleichzeitig versuchen auf die Platte zu schreiben und das Fstream Object nicht durch ein Mutex geschützt ist könnte es zu Problemen kommen.
Concurrent access to a stream object (27.8, 27.9), stream buffer object (27.6), or C Library stream (27.9.2) by multiple threads may result in a data race (1.10) unless otherwise specified (27.4). [ Note: Data races result in undefined behavior (1.10). —end note ]
