Zugriffsverletzung bei ..

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/