Zugriffsverletzung bei ..

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?!

Ruvi

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.

http://www.pic-upload.de/view-26753255/12.jpg.html

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ß

Ruvi

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 ]

Danke für die Antwort Ruvi, läuft aber grade nur mit einem Single Thread. Aber wie gesagt ich glaube NICHT das es an der Fstream fkt. liegt. Weil der gleiche Fehler (bei anderer Konstellation im Prog.) zb. bei der recv. Fkt. auftritt. Weshalb ich mir relative sicher bin das ich irgendwo buffer overflows oder sonsitges habe das mir den Speicher zerschießt. Hat jemand ne Idee wie man nach sowas suchen kann?
Gruß

Ruvi

Komisch123 schrieb:

Danke für die Antwort Ruvi, läuft aber grade nur mit einem Single Thread.

Ich muss einfach nochmal Fragen, bist Du dir da sicher?
Weil wenn die Variable bei Dir im Debugger beim Aufruf der Funktion (wie du gesagt hast) noch richtig ist und erst in der fstream Funktion "geklaut" wird und wirklich nur ein Thread am Laufen ist fände ich das äußerst merkwürdig.

Ruvi schrieb:

Komisch123 schrieb:

Danke für die Antwort Ruvi, läuft aber grade nur mit einem Single Thread.

Ich muss einfach nochmal Fragen, bist Du dir da sicher?
Weil wenn die Variable bei Dir im Debugger beim Aufruf der Funktion (wie du gesagt hast) noch richtig ist und erst in der fstream Funktion "geklaut" wird und wirklich nur ein Thread am Laufen ist fände ich das äußerst merkwürdig.

Ich würde meinen ja, so sieht meine main aus:

std::vector<std::array<std::string, TWO>> socket;
	//socket.push_back({ { "198.12.012.122", "12" } });
	socket.push_back({ { "127.0.0.1", "1234" } });
	std::vector<com> com_vec (begin(socket), end(socket)); 

	vector<thread> c_threads; 
	for (auto &a_com_vec : com_vec) 
	{
		c_threads.emplace_back(std::thread(&com::run, &a_com_vec)); 
	}

	for (auto &a_thread : c_threads)
	{
		a_thread.join(); 
	}

TGGC

Komisch123 schrieb:

Weshalb ich mir relative sicher bin das ich irgendwo buffer overflows oder sonsitges habe das mir den Speicher zerschießt. Hat jemand ne Idee wie man nach sowas suchen kann?

Also ich haette da eine Idee: Entferne solange Teile von deinem Programm, die den Fehler nicht verschwinden lassen, bis du den Fehler gefunden hast.

Ruvi

Wenn du sonst nirgends mehr einen thread launched dann musst Du halt wirklich alle in Frage kommenden Stellen durchgehen.

Ich würde mir alle Stellen anschauen die ausgeführt werden bevor du die File Funktion aufrufst und in denen Du ein C-Array als Buffer benutzt.

Ich versteh nicht genau wo die zwei Screenshots zeigen, dass irgendwas in .open() falsch gelaufen oder "geklaut" wurde??

Der übergebene String ist noch so da und __Myfile soll laut dem Code ja = NULL Sein

( if __Myfile != 0 ... ) {
             ... // KOMMENTIER HIER: file open >failed<
          }

An welcher _konkreten_ Stelle fliegt denn der Nullpointer??

Mhhhh jetzt wirds richtig lustig nun tritt der Fehler nach dem Handshake etz. auf bei der "NÄCHSTEN" printf Anweisung sprich lösche ich eine tritt der Fehler erst bei der nächsten prinft auf.
http://www.pic-upload.de/view-26754333/11.jpg.html

hustbaer

Ein paar Stichwörter, die beim Suchen von Access Violations bzw. "Speicher zerschossen" Fehlern unter Windows hilfreich sein könnten:
Application Verifier
GFlags
Page Heap

Und natürlich DEBUG Build testen und die ganzen Debugging Features von VS einschalten (falls sie nicht schon sind, was bei DEBUG Default sein sollte).

weicher

Versuch mal die "first Chance Exceptions" oder "(Erste Chance) Exeptions" zu ignorieren.

In den meisten Fällen sind diese "first Chance Exceptions" Meldungen an die Windows Runtime. Wenn die Exeption ernst gemeint ist, dann wird sie nochmals als endgültige Exception geworfen.

hustbaer

weicher schrieb:

Wenn die Exeption ernst gemeint ist, dann wird sie nochmals als endgültige Exception geworfen.

Die Exceptions sind immer "ernst gemeint" und sind auch immer "echt".
Wenn ausser der "first change exception" Meldung weiter nix passiert, dann heisst das bloss dass die Exception irgendwo gefangen wurde.

weicher

hustbaer schrieb:

Die Exceptions sind immer "ernst gemeint" und sind auch immer "echt".
Wenn ausser der "first change exception" Meldung weiter nix passiert, dann heisst das bloss dass die Exception irgendwo gefangen wurde.

Du hast natürlich Recht

Aber jetzt traut sich Komisch123 ganz sicher nicht die "first chance" exception mal probeweise zu ignorieren. Was aber nach meiner Erfahrung in 99% der Fälle zum Erfolg führt.

Scheinbar werden im entsprechenden "first chance" exception handler irgendwelche Datenstrukturen aufgebaut und initialisiert.

siehe auch:
http://mfctips.com/2013/01/30/ignore-first-chance-exceptions/