Zugriffsfehler auf "std::map" in " _Orphan_ptr(const _Nodeptr _Ptr)"

[elmut19]

Bin zu dem Schluss gekommen, dass sich eine "std::map" nicht mit einer "struct", die selbst komplexe Objekte enthält, verträgt.
Auch wenn ich nur einen NULL-Pointer in meine "map" reinschreiben und vor Ende meines Basis-Objekts alles aus der "map" bereinigt wurde,
gehts schief. Und der Thread, der als einziger mit dieser "map" gearbeitet hat, ist auch schon ordentlich beendet und hat dabei sein "map"-Element gelöscht.

Ich werd wohl ne eigene "map" schreiben müssen.
Danke aber nochmals für Eure Hilfe.

[It0101]

@elmut19 sagte in Zugriffsfehler auf "std::map" in " _Orphan_ptr(const _Nodeptr _Ptr)":

Ich werd wohl ne eigene "map" schreiben müssen.

So hab ich auch mal gedacht, das ist aber eine Sackgasse. Container kann man mal zu Lernzwecken implementieren, aber nicht zur ernsthaften Verwendung. Die STL-Container sind für ihren jeweiligen Anwendungsfall das beste was du bekommen kannst.
Bei uns im Unternehmen gab es in der pre-C++11-Zeit auch viele selbstimplementierte Container, aber das war alles fürchterlich. Ich habe dann nach und nach nachgewiesen, dass die Performance der STL erheblich besser ist und die Usability auch. Seitdem kam keiner mehr auf die Idee sowas selber zu schreiben.

Wenn die Map nicht zu deinem restlichen Konzept passt, dann ist vermutlich dein restliches Konzept ungeeignet und nicht die Map.

Was das "struct" angeht, sehe ich das ähnlich. Das funktioniert zwar, aber ich vermeide das auch. "structs" sind bei mir entweder PODs oder befördere sie zu einer Klasse.

[Tyrdal]

@elmut19 sagte in Zugriffsfehler auf "std::map" in " _Orphan_ptr(const _Nodeptr _Ptr)":

Bin zu dem Schluss gekommen, dass sich eine "std::map" nicht mit einer "struct", die selbst komplexe Objekte enthält, verträgt.

Da liegst du völlig falsch.

Auch wenn ich nur einen NULL-Pointer in meine "map" reinschreiben und vor Ende meines Basis-Objekts alles aus der "map" bereinigt wurde,
gehts schief. Und der Thread, der als einziger mit dieser "map" gearbeitet hat, ist auch schon ordentlich beendet und hat dabei sein "map"-Element gelöscht.

Klingt als hättest du dir irgendwo den Speicher "versaut".

Ich werd wohl ne eigene "map" schreiben müssen.

Das halte ich wiederum für einen groben Feher.

[DocShoe]

@elmut19 sagte in Zugriffsfehler auf "std::map" in " _Orphan_ptr(const _Nodeptr _Ptr)":

Ich werd wohl ne eigene "map" schreiben müssen.

Da kann ich mich meinen Vorrednern nur anschließen, die STL oder vergleichbare boost-Container sind das Beste, was du bekommen kannst. Daran arbeiten Leute, die den ganzen Tag nichts anderes machen, was Selbstprogrammiertes wird an die Qualität wohl selten herankommen.
Das Problem ist aber nicht die map selbst, sondern etwas anderes (die Vermutung race condition steht immer noch im Raum). Und das wirst du auch mit einer selbstprogrammierten Map nicht lösen können.

Lass mal einen statischen Code Analyser über deinen Quelltext laufen (zB cppcheck), die finden oft Ungenauigkeiten/Fehler. Ansonsten führ´ dein Programm in einem Profiler aus, der Speicheranalysen durchführt (check auf double frees, Schreiben in nicht-initialisierten Speicher, etc.). Vielleicht hilft dir das weiter.

[DocShoe]

@It0101 sagte in Zugriffsfehler auf "std::map" in " _Orphan_ptr(const _Nodeptr _Ptr)":

@elmut19 sagte in Zugriffsfehler auf "std::map" in " _Orphan_ptr(const _Nodeptr _Ptr)":

Ich werd wohl ne eigene "map" schreiben müssen.

Bei uns im Unternehmen gab es in der pre-C++11-Zeit auch viele selbstimplementierte Container, aber das war alles fürchterlich. Ich habe dann nach und nach nachgewiesen, dass die Performance der STL erheblich besser ist und die Usability auch. Seitdem kam keiner mehr auf die Idee sowas selber zu schreiben.

Da habe ich ein Deja-Vue. An Teil 1 arbeite ich noch (also Überzeugung, nicht eigene Container), aber den Mythos "std::vector ist langsam" und "std::vector" ist für viele Elemente nicht geeignet" hält sich hartnäckig :(.

[Quiche Lorraine]

@Tyrdal sagte in Zugriffsfehler auf "std::map" in " _Orphan_ptr(const _Nodeptr _Ptr)":

Klingt als hättest du dir irgendwo den Speicher "versaut".

Das vermute ich schon ein wenig länger, weiß aber nicht so recht wie ich es schreiben soll.

Ich probiere es mal.

@elmut19

Du nutzt meiner Meinung nach zu viele Pointer (z.B. pCRing, PMRDATA, PMRCANIDSRAM, std::map<CString,PMRCANIDSRAM>, std::map<CString,PMRDATA>* m_pmapData) und dadurch könnten die Verantwortlichkeiten nicht sauber definiert sein.

So könnte es z.B. sein das MRDATA::pWriteRsp an irgenteine Stelle gelöscht wird und es einen Destruktor für MRDATA gibt, welche pWriteRsp nochmals löschen will.

Aus meiner Sicht müsste man deswegen den Code aufräumen und die Verantwortlichkeiten in Klassen packen. Warum z.B. muss pWriteRsp von Hand gelöscht werden? Warum kann das nicht die Klasse CRing bzw. MRDATA tun bzw. verantwortlich dafür sein?

Such dir bitte mal jede Stelle wo du einen Pointer nutzt und stelle dir die folgenden Fragen?

• Handelt es um einen Zeiger, welcher Ressourcen allokiert?
• Wenn ja, wer ist für das Löschen verantwortlich? Wer für das Allokieren?
• Sind Zugriffe auf den Zeiger immer sicher?
• Welche Querabhängigkeiten entstehen durch die Verwendung des Zeigers?
• Kann man anstatt des Zeigers auch eine Kopie nutzen?

Schau dir noch mal MRDATA::pWriteRsp an. Durch die Verwendung eines Zeiger ist die Lebenszeit von pWriteRsp nicht unbedingt an die Lebenszeit der MRDATA Instanz gebunden. Du hast in der UML Sprache hier eine Relation. Würdest du gegegen bei MRDATA::pWriteRsp keinen Zeiger nutzen, so wäre die Lebenszeit von pWriteRsp an die Lebenszeit der MRDATA Instanz gebunden. Du hättest in der UML Sprache eine Aggregation. Ähnliches gilt für std::map<CString,PMRDATA> m_mapData;.

[elmut19]

@Quiche-Lorraine
Ja. Ich halte die stl auch für genial!
Halte deshalb auch schon seit fünf Wochen an dem Konzept fest.
Habe auch schon an alle möglichen Stellen gedacht, wo noch mein Pointer manipuliert werden kann.

Ich habe das Ganze schon soweit manipuliert, dass ich in der "map" nur noch einen "NULL-Pointer" habe und meinen bisherigen Pointer für die Operationen verwende.
Von der "map" brauche ich dann nur den Key, damit ich weiss wer nach den Daten fragt. Und ich habe sichergestellt, dass auch nur der eine Kandidat mit dem "NULL-Pointer" etwas in die "map" geschrieben hat.

"zu viele Pointer (z.B. pCRing, PMRDATA, PMRCANIDSRAM, st"
Hierfür sorry. PMRDATA ist identisch mit PMRCANIDSRAM.
Ich hab es anfangs im Text nur umbenannt. In Fehlerausgabe ist das Original.
Es ist der Datentyp der "struct", die als Element in der "map" ist.
Und "pCRing" ist Datentyp von drei gleichartigen Elementen in dieser "struct"

Diese "struct" ist das zentrale Kommunikations-Objekt,
über das das HMI über den TCP-Client-Thread mit der Anlage kommuniziert.
Die "map" vervielfacht diese "struct", damit die Daten auf mehrere HMI´s verteilt werden können.
Das war auch die Idee zu dem gewünschten Feature, aus einer einzigen Client-App einen Verteiler zu basteln,
über den die Anlage nur noch eine TCP-Verbindung für mehrere Clients halten muss.
Genaugenommen ist das schon die einzige Änderung.
Soweit habe ich zumindest alles reduziert. Also sogar ohne zusätzliche Clients.

Damit sollte doch eigentlich alles was ausserhalb noch so allokiert wird ausgeschlossen sein.
An das rechtzeitige Beenden der Threads, einschliesslich Aufräumen der Objekte habe ich auch gedacht.
Und ja, normalerweise wird auch allokiert (CRing).

Aus der "struct" eine "class" zu machen, habe ich auch schon gedacht und damit angefangen.
Hat nicht auf Anhieb geklappt. Hängt viel anderes Zeug mit dran.
Wäre evtl. wieder einen Versuch wert.

[Quiche Lorraine]

@elmut19 sagte in Zugriffsfehler auf "std::map" in " _Orphan_ptr(const _Nodeptr _Ptr)":

Hierfür sorry. PMRDATA ist identisch mit PMRCANIDSRAM.

Das P... ist doch ein Windows spezifischer Präfix für einen Pointer. Deswegen mein Hinweis und die Frage: Funktioniert nicht hier auch ein MRDATA bzw. MRCANIDSRAM.

Versuche mal bitte das Problem dahinter zu verstehen. Wenn man Zeiger nutzt, so kann dies unerwartete Seiteneffekte haben, weil da eben eine Relation ist.

Genau deswegen gefallen mir Klassen. Man kann diese so entwickeln das sie Problem kapseln, einfach zu benutzen und schwer falsch zu benutzen sind.

Deswegen wäre mein erster Schritt MRDATA folgendermaßen uumzubauen

class MRDATA_2
private:
public:
	bool				bInUse;
	CRing				ReadRsp;
	CRing				WriteRsp;
	CRing				ErrorRsp;
	long				lWritePos;
	DWORD				lWriteRspPos;
	bool				bWriteToCan;
	bool				bDataInWRITE;
	HANDLE			hTimerThreadRspSleep;
	CRITICAL_SECTION	m_csRspCriticalSection;  // evt. C++ Äqauivalent
};

Ein MRDATA besteht so ReadRsp, WriteRsp und ErrorRsp Ringpuffer,...

Ferner würde CRing sich eigenständig um die Ressourcenverwaltung kümmern. Ich habe hierzu mal ein std::array benutzt als ich ein Ringpuffer-Template geschrieben habe.

Und dann versuche doch mal einen Fehler in MRDATA_2 zu verursachen und danach mit MRDATA.

[elmut19]

@Quiche-Lorraine
Hallo Quiche-Lorrain,
Vielen Dank noch für den Hinweis.
Aber hier auch ja, ich habe es probiert. Vielleicht habe ich nicht alle Optionen
mit dieser Variante durchgespielt, aber es endete mit dem gleichen Fehler.
Ich sehe es aber weiterhin noch als Option, da nochmal dran zu arbeiten.

Ich bin aber momentan noch bei der Variante, die "struct" in eine "echte" Klasse umzubauen.
Bisher habe ich nur mal das "struct" gegen "class" getauscht, ohne irgendwelche Konstruktoren oder Destruktoren einzubauen.
Vielleicht verliert der Compiler durch das "struct" den Bezug zu internen
Destruktoren der Elemente und vermutet daher dort vergessenen Objekte,
weshalb dann der Fehler ausgelöst wird.

[Th69]

Nein, ein struct X ist nichts anderes als

class X
{
public:
   // ...
}

(also public als Standardzugriffsmodifizierer - als auch beim Ableiten, aber das nutzt du ja nicht).
Du kannst dort ebenfalls Konstruktoren, Destruktoren sowie Memberfunktionen implementieren.

Mit "Umbau zur Klasse" ist nur gemeint, daß du nicht nur eine reine Datenstruktur hast, welche von außen manipuliert wird, sondern auch Memberfunktionen, welche sich um den internen Zustand kümmern (Validierung, De-/Allokationen, ...).

Und deine Problembeschreibung im Eingangsbeitrag deutet wirklich darauf hin, daß der Speicher der Anlage-Klasse irgendwie überschrieben wurde, so daß die map-Objekte falsche Zeiger beinhalten. Gerade das Crashen auch bei einem leeren map zeigt ja, daß es nicht an den enthaltenen Daten liegen kann.
Verschieb doch mal diese map-Objekte an den Anfang oder Ende deiner Anlage-Klasse (ich nehme mal an, du hast noch mehr als diese zwei Member).

Oder zeige mal die Member der Anlage-Klasse, sowie dessen Destruktor.

PS: Du kannst es auch mal mit einem Datenhaltepunkt (data breakpoint) auf das map-Objekt versuchen, um Schreibänderungen zu finden: Verwenden von Breakpoints im Visual Studio-Debugger: Festlegen von Datenbreakpoints (nur nativer C++-Code)

[DocShoe]

Ich kann mich da nur wiederholen:

• mach eine statische Codeanalyse, zB mit cppCheck, um Fehler im Programm zu finden
• benutz einen Profiler, um ungültige Schreibzugriffe in Speicher zu finden.

Undefined Behaviour zu finden und zu beseitigen ist so das Unangenehmste, was man machen muss.

[It0101]

@DocShoe sagte in Zugriffsfehler auf "std::map" in " _Orphan_ptr(const _Nodeptr _Ptr)":

@It0101 sagte in Zugriffsfehler auf "std::map" in " _Orphan_ptr(const _Nodeptr _Ptr)":

@elmut19 sagte in Zugriffsfehler auf "std::map" in " _Orphan_ptr(const _Nodeptr _Ptr)":

Ich werd wohl ne eigene "map" schreiben müssen.

Bei uns im Unternehmen gab es in der pre-C++11-Zeit auch viele selbstimplementierte Container, aber das war alles fürchterlich. Ich habe dann nach und nach nachgewiesen, dass die Performance der STL erheblich besser ist und die Usability auch. Seitdem kam keiner mehr auf die Idee sowas selber zu schreiben.

Da habe ich ein Deja-Vue. An Teil 1 arbeite ich noch (also Überzeugung, nicht eigene Container), aber den Mythos "std::vector ist langsam" und "std::vector" ist für viele Elemente nicht geeignet" hält sich hartnäckig :(.

Ich habe solche Diskussionen immer damit erstickt:
https://i.stack.imgur.com/G70oT.png

Manch einer verwendet nachwievor den falschen Container für den falschen Anwendungsfall.

[It0101]

@Quiche-Lorraine sagte in [Zugriffsfehler auf "std::map" in " _Orphan_ptr(const _Nodeptr _Ptr)"]

Genau deswegen gefallen mir Klassen. Man kann diese so entwickeln das sie Problem kapseln, einfach zu benutzen und schwer falsch zu benutzen sind.

Insbesondere, wenn man ihre Kopierfähigkeit/Bewegungsfähigkeit einschränkt. Auf die Art hab ich schon so manches Ei gefunden, weil manche Dinge dann unerwartet doch irgendwie kopiert wurden.

[Quiche Lorraine]

@Th69 sagte in Zugriffsfehler auf "std::map" in " _Orphan_ptr(const _Nodeptr _Ptr)":

Mit "Umbau zur Klasse" ist nur gemeint, daß du nicht nur eine reine Datenstruktur hast, welche von außen manipuliert wird, sondern auch Memberfunktionen, welche sich um den internen Zustand kümmern (Validierung, De-/Allokationen, ...).

Genau.

Denn mit einer gut designten Klasse reduziert man einiges an Code-Komplexität.

Und das versuche ich @elmut19 zu erklären. Viel C Code ist offener Natur und funktioniert nur deswegen gut, weil man sich sehr diszipliniert an Regeln hält.

Mit C++ wird das wesentlich einfacher, da man dank RAII/STL sich fast nicht mehr um Ressourcenverwaltung kümmern muss und dank den Klassen Kapselungen besser implementieren kann.

So richtig verstanden habe ich dies aber erst, als ich jede Menge C Code nach C++ portierte.

PS:
@elmut19

Warum nicht so?

// Democode, nicht lauffähig
class MRDATA_2
private:
  bool				bInUse;
  CRing				ReadRsp;
  CRing				WriteRsp;
  CRing				ErrorRsp;
  long				lWritePos;
  DWORD				lWriteRspPos;
  bool				bWriteToCan;
  bool				bDataInWRITE;
  HANDLE			hTimerThreadRspSleep;
  CRITICAL_SECTION	m_csRspCriticalSection;  // evt. C++ Äqauivalent

public:
  void GetReadRsp(CRing& ReadResponse)
  {
    // EnterCriticalSection 
    // ReadResponse = this.ReadRsp
    // LeaveCriticalSection
  }

  // ...
};

Deine ganzen Daten sind private. Du kommst also außerhalb der Klasse nicht mehr an deine Daten ran. Also musst du z.B. die Funktion GetReadRsp() nutzen und diese nutzt automatisch deine CRITICAL_SECTION Instanz. Sofern deine Klasse korrekt implementiert ist, zwingst du dich also automatisch zur Thread Safety.

[elmut19]

@Quiche-Lorraine
Vielen Dank nochmal für Eure Vorschläge.
Ich brauch nun eine Weile, um mir das alles nochmal durch den Kopf gehen zu lassen.
Ich werd mal mit einer vollständigen Klasse statt der "struct" (bzw. einfach nur "class" zu schreiben) weitermachen.
Und dann noch die Sache ohne Pointer. Davon hab ich schon ne Version als "struct".
Das ganze Anlage-Objekt ist wirklich ein Mega-Teil und kaum zu überblicken.
Vorerst halte ich noch Abstand, das hier abzudrucken.
Habe zudem noch ein ganz anders Problem reinbekommen, um das ich mich auch noch kümmern muss

[Th69]

Der Fehler liegt nicht an der MRDATA-Datenstruktur!
Das ganze sollte doch mit ein paar Minuten Debugging gelöst sein...

Oder generell, wie schon von @DocShoe vorgeschlagen, CppCheck benutzen - für VS das passende CppCheck Add-In.

[Schlangenmensch]

Mal ne blöde Frage, hältst du irgendwo Iteratoren auf Map Elemente und durch eine erase oder so ist die Position nicht mehr dereferenzierbar? Sowas ist mir vor nicht all zu langer Zeit mal passiert.

[elmut19]

@Schlangenmensch
Hallo Schlangenmensch,
das ist mir zwischendurch natürlich auch passiert.
Da stürzt es natürlich gleich ab. Gibt dann ne andere Fehlermeldung.
Habe diverse Sachen eingebaut, um sicherzustellen, dass auch der jeweilige Thread weg ist, bevor das map-Element gelöscht wird.
Ich setze die Iteratoren möglichst auf "end()", wenn ich sie nicht mehr brauche.
Das Programm läuft auch schon mal übers Wochenende und sammelt dabei Daten.
Auch kann ich Verbindungen Trennen und wieder aktivieren, wobei natürlich die zugehörigen Threads auch eliminiert werden.
Also für die Dauer des Betriebs habe ich das alles ja hinbekommen,
abgesehen,
wenns bei diversen anderen Versuchen dann da auch gekracht hat.
Nur, wenns beim beenden des Programms aus dem Destruktor des Basis-Objekts raus geht, dann krachts immer.
Daher denke ich, dass die Destruktoren nochmals alle aufgerufen werden
und es in der "map" eben stecken bleibt, weil die Aufruf-Schlange durch die "struct" unterbrochen wird.
@Th69 Ja, die Datenstruktur ("struct") funktioniert ja schon lange.
Es ist die "map" drum rum, die versagt. Aus der "struct" wird auch irgendwie der HMI Teil angesprochen ("irgendwie", ja stammt noch vom Vorgänger).
Ich sehe daher auch meine Umbaumöglichkeiten eingeschränkt.
@DocShoe Den cppCheck hatte ich auch schon mehrfach angedacht, bin aber bisher immer im Versuch stecken geblieben, weils dann anders auch ging.

[Th69]

Rufst du etwa irgendwo (aus dem anderen Thread heraus) explizit delete für diese map auf?
Oder meinst du nur map.clear(), wenn du von

..., dass auch der jeweilige Thread weg ist, bevor das map-Element gelöscht wird.

bzw. aus deinem Eingangsbeitrag

Innerhalb des Threads, der die Daten in die "std::map" geschrieben hat,
kann das map-Element auch wieder gelöscht werden, sowie auch die Daten darin bereinigt werden können.

schreibst?

Ansonsten mußt du uns wirklich mal den Code der betreffenden Stellen zeigen.

[elmut19]

@Th69
Ich versuche sogar alles.
In erster Linie bereinige ich die "map"-Elemente in dem Thread, in dem ich sie reingeschrieben habe, genauer das eine Element, das dieser Thread geschrieben hat.
Da benutze ich auch das "delete()" auf die "Objekte" (Ringspeicher) innerhalb der "map".
In den Objekten, die ihren Thread aufrufen (zu jedem Thread gehört eins für die "open()" und "close()" Methoden z.B.), warte ich, bis explizit der Thread über ein Flag sein Ende angezeigt hat, bis ich das auch beende, versuche aber auch zusätzlich zu bereinigen.
An solchen und auch anderen Stellen bin ich damit auch immer wieder auf die Nase gefallen, da auch diese Probleme ("_Orphan_ptr") auftraten und dann auch teils im Betrieb.
Da habe ich auch immer wieder zu viel des Guten versucht.

Mein Basis-ClientThread, der die ganzen Nachrichten an die aufgeschalteten ServerThreads verteilt, ist natürlich drauf angewiesen,
dass sein Iterator auch immer auf Daten zeigt (Thread beendet und seine Daten aus "map" gelöscht).
Sollte aber eines dieser Elemente gelöscht worden sein, ohne dass dieser das rechtzeitig merkt,
dann steht dieser Iterator auf "end()". Der Crash zeigt dann aber auch einen anderen Grund. Und der ist dann eigentlich von der Ursache her trivial, also erklärbar.

Aber am Ende des Anlage-Objekts kommt dann immer dieser "Orphan" Fehler.
Da gibt es dann auch zwei Möglichkeiten:

1. Die "maps" sind schon alle ordentlich bereinigt und leer.
   Dann kommt die eine "Orphan" Methode.
2. Es ist noch ein Element drin, das ich im Destruktor des Anlage-Objekts, explizit und auch mit "delete()" auf die Ringspeicher, löschen möchte,
   dann kommt im "erase()" eine andere "Orphan" Methode.
   Also die Objekte in der "struct" (Ringspeicher) kann ich da sogar bereinigen.
   Nur dann das "map"-Element mit "erase()" auch noch löschen, nein.

Habe schon alle Codefragmente hin und her geschoben.
Teils haben sie dort dann funktioniert, teils auch nicht. Dann wieder dort raus.
Nur das Programm beenden klappt nie!
Und da verabschiedet es sich auch nicht mit einer Fehlermeldung und ist dann weg.
In der Regel muss ich sogar den Taskmanager zuhilfe nehmen.