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

elmut19

@DocShoe
Danke für die Idee mit dem Smartpointer. Ich muss mich damit befassen.
Vielleicht hilft das ja.
Ob ich den Ringspeicher derart umschreiben kann oder das schon auf das Objekt anwenden kann, in dem der Ringspeicher drin ist (Zusammenfassung meiner Übertragungsdaten), muss ich auch überlegen.
Ich sehe das Problem nun hauptsächlich hierin, dass die "std::map" innerhalb ihrer Verwaltung diesen externen Speicher sieht, den sie an besagter Stelle nicht mehr kennt.
Und dieser Ringspeicher ist/war für mich bisher einfach eine Blackbox.
Ich sehe auch wenig Möglichkeiten, das Ding umzuprogrammieren.
Aber es wäre auch noch eine Idee.
Vielleicht kann ich mit Smartpointer auch sowas wie einen Wrapper konstruieren, damit die "map" das gar nicht sieht.

DocShoe

@elmut19

Das Problem scheint zu sein, dass irgendwo Memory Corruption stattfinded, weil an allen möglichen Stellen Resourcen angefordert und freigegeben werden. Ein doppeltes delete/free/HeapFree an einer Stelle kann dazu führen, dass dir an einer anderen Stelle alles um die Ohren fliegt. Diesen Wildwuchs solltest du erstmal zähmen, und da sind smart pointer ein starkes Werkzeug. Wenn dann natürlich wieder rohe Zeiger durch die Gegend gereicht werden helfen dir auch smart pointer nicht weiter, musst mal gucken, ob das mit euren Schnittstellen funktioniert.
Ein Memory Profiler sollte das eigentlich erkennen, aber wenn du schon cppCheck nicht installieren kannst hast du vermutlich auch keinen Profiler.

Th69

@elmut19. Warum kannst du cppcheck nicht installieren? Es muß ja nicht auf deinem Entwicklungsrechner sein - irgendein Rechner, auf dem du auf die Sourcen zugreifen kannst (bzw. kopieren kannst - oder per USB-Stick o.ä.)...

Quiche Lorraine

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

Es muß ja nicht auf deinem Entwicklungsrechner sein - irgendein Rechner, auf dem du auf die Sourcen zugreifen kannst (bzw. kopieren kannst - oder per USB-Stick o.ä.)...

Hmm, der Entwicklungsrechner sollte es schon sein.

Denn man könnte ja auch Tools ala Application Verifier oder Dr. Memory über das Programm laufen lassen.

Und Application Verifier funktioniert am besten unter dem Visual Studio Debugger.

SeppJ

Ist das überhaupt zielführend? Es wird rauskommen, dass es an der wilden manuellen Speicherverwaltung liegt. Das wissen wir auch jetzt schon. Es hilft ja nicht, dass dann spezifisch auf eine oder mehrere Stellen gezeigt wird, wegen denen es schief geht. Denn was will man dann machen? Nur diese korrigieren? Und vor allem: Wie genau? Dazu braucht man tiefgehendes Verständnis wie manuelle Speicherverwaltung richtig geht, das offensichtlich nicht vorhanden ist.

Das ganze manuelle Gefrickel gehört einfach komplett raus. Optimalerweise auch nicht nur indem man bloß alles durch Smartpointer ersetzt (auch wenn das wahrscheinlich schon viel helfen würde), sondern indem man mal gründlich über das Datenmodell nachdenkt, welche Ressourcen man wirklich braucht und wo die Verantwortlichkeiten liegen. Das braucht natürlich viel Wissen und auch einiges an Arbeit. Aber immer noch deutlich weniger Wissen und Arbeit als wenn man das gleiche manuell richtig machen würde.

Wenn man da jetzt mit wenig Wissen oberflächlich an den unmittelbaren Fehlern schnell herumpfuscht bis es irgendwie läuft, fällt die Bruchbude doch beim nächsten leisen Husten gleich wieder um.

*john 0

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

Der gezeigte Code ist grausig. Die Verantwortung für die Speicherverwaltung muss klar definiert sein, und ein paar Regel sind einzuhalten.

Rohe Zeiger werden nur als Referenz verwendet. D.h. wenn man diese aus einer Klasse heraus herumreicht, wird darüber niemals Speicherfreigabe, Reallokation oder Allokation gemacht.
Wenn es unbedingt notwendig ist, schreibt man Wrapper Klassen, die den Speicher verwalten. Das sollte eigentlich mit C++11 nicht mehr notwendig sein, weil …
Resourcen über SmartPointer alloziert und verwaltet werden. Man kann mit eigenen Funktionen Objekte in speziellem Speicher allozieren und die Verantwortung an den SmartPointer übertragen. Das betrifft auch das korrekte Löschen der Objekte mit einer speziellen Funktion. D.h. man kann Objekte im RingSpeicher allozieren, und der SamrtPointer räumt sie dort korrekt ab.
Falls notwendig schreibt man für Container der Standardlibrary einen CustomAllocator, der Speicher des Ringspeichers nutzt. Ja, auch das geht.

Quiche Lorraine

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

Ist das überhaupt zielführend? Es wird rauskommen, dass es an der wilden manuellen Speicherverwaltung liegt. Das wissen wir auch jetzt schon.

Aber wissen dies die Verantwortlichen?

Wir wissen ja nicht ob das Programm in einer Gruppe entwickelt wird. Und wenn man da sagt, man benötigt ein Code Reengineering, so kommt schnell ein Argument ala "Es hat ja bisher funktioniert, warum sollte da also ein Fehler sein?".

Und ist dies der Fall, so benötigt @elmut19 erst einmal Argumente für ein umfassendes Code Reengineering. Wenn da ein namenhaftes Tool ala Application Verifier Probleme meldet, so ist dies ein Argument hierfür.

Ein weiteres Argument dürfte auch der neue Programmierstil (mehr STL, keine Pointer,...) sein, welcher per se weniger fehleranfällig ist.

Alles Dinge welche ich zuvor schon in diesem Thread sagte.

wob

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

Wenn da ein namenhaftes Tool ala Application Verifier Probleme meldet, so ist dies ein Argument hierfür.

So eine Argumentation finde ich echt immer furchtbar.

SeppJ

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

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

Wenn da ein namenhaftes Tool ala Application Verifier Probleme meldet, so ist dies ein Argument hierfür.

So eine Argumentation finde ich echt immer furchtbar.

Jupp. Lass uns einem Werkzeug mehr vertrauen als dem zuständigen Entwickler! Wenn der Entwickler so wenig Vertrauen genießt (was ja evtl. sogar gerechtfertigt sein kann, z.B. Neueinsteiger), sollte man ihn nicht alleine an den Code lassen. Wenn ein eventueller Chefentwickler diesen Code als okay befindet, dann ist das ein Problem des Chefentwicklers. Dies ist keine subtil versteckte Designschwäche im Code, über die Experten streiten würden. Dies ist ein Problem das man spätestens nach dem 5. Kapitel eines jeden Anfängerlehrbuchs besser wissen muss.

Aber auch mit einer dummen Managemententscheidung zum Festhalten an den Fehlern im Code gilt:

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

Denn was will man dann machen? Nur diese korrigieren? Und vor allem: Wie genau?

Den ganzen Thread lang versuchen wir schon das Problem einzugrenzen oder zu beheben und es gab keinen erkennbaren Fortschritt. Falsche Ressourcenverwaltung ist nun einmal eine Problemklasse, die man nicht so einfach beheben kann.

Quiche Lorraine

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

Jupp. Lass uns einem Werkzeug mehr vertrauen als dem zuständigen Entwickler! Wenn der Entwickler so wenig Vertrauen genießt (was ja evtl. sogar gerechtfertigt sein kann, z.B. Neueinsteiger), sollte man ihn nicht alleine an den Code lassen. Wenn ein eventueller Chefentwickler diesen Code als okay befindet, dann ist das ein Problem des Chefentwicklers. Dies ist keine subtil versteckte Designschwäche im Code, über die Experten streiten würden. Dies ist ein Problem das man spätestens nach dem 5. Kapitel eines jeden Anfängerlehrbuchs besser wissen muss.

Du versteht das Problem dahinter nicht. EIn Bilderbuch-Projekt habe ich in der Praxis noch nie gesehen. Folgende Dinge fallen mir an vielen Stellen auf:

Die Code-Base ist völlig veraltet.
Der Kenntniss-Stand der Entwickler ist veraltet, sofern sie überhaupt Entwickler sind.
Gute Entwickler findet man nicht oft.
Der Kenntniss-Stand des Projektleiters ist veraltet, sofern er überhaupt Entwickler ist.
Zeitdruck (TIme To Market) ist oftmals kontraproduktiv bezüglich dem Design.
"Nichts hält länger als ein Provisorium." Vorgehensweise (Issue: Code schöner machen sofern Zeit).
Wer fremden Code anfasst, muss mit Emotionalitäten rechnen.
Wer neue Tools einführen möchte, muss mit Emotionalitäten rechnen.
Outsourcing ist oftmals kontroproduktiv bezüglich der Qualität.

EIn fiktives Beispiel:

"Ein Maschinenbauer schreibt ein Programm in C in einem katastrophalen Stil. Der Code wird seit Jahren erfolgreich eingesetzt und soll nun erweitert und in einem erweiterten Bereich eingesetzt werden.

Deswegen soll nun ein unerfahrerer Software-Entwickler diesen Code übernehmen. Und dieser kommt nach ein paar Tage wütend und sagt: Der Code ist scheiße und voller Fehler" Was glaubst du wird ein Projektleiter antworten?

"Komm beruhige dich. Aber der Code funktioniert seit Jahren problemlos bzw. fehlerfrei, also warum sollte dieser schlecht sein? Und außerdem, der letzte Software-Entwickler wollte dies auch schon ändern und hat dabei einen großen Bock geschossen."

Wenn du in einer solchen Situation bist, benötigst du eine Menge Erfahrung und eine gewisse Reputation um dagegen zu argumentieren. Und wenn du dann etwas unerfahren bist, musst du halt mittels Tools ala Application Verifier unterstützend argumentieren.

Und solche Situationen habe ich schon in einigen Bereichen/Firmen gesehen.

PS:
Gerade nutze ich das Nordic SDK, eine C SDK zur Ansteuerung von Funk-Chips. Das Merkmal dieser SDK ist das fehlen einer einheitlichen Schnittstelle. Neuere Versionen sind inkompatibel zu vorhergehenden Versionen. Konfiguriert wird das SDK mittels einer 500 kByte großen sdk_config.h Datei, in welchem nur #define Anweisungen stehen, Funktionalitäten sind stellenweise überdimensioniert, da die Hardware sehr limitiert ist (z.B. Programmgröße < 80 kByte),...

Was soll man da tun? Das potenzielle beheben der Fehler ist nicht einfach, da das SDK riesig ist und manche Funktionen, gerade in Bezug auf Bluetooth LE, nicht trivial sind.

*john 0

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

"Komm beruhige dich. Aber der Code funktioniert seit Jahren problemlos bzw. fehlerfrei, also warum sollte dieser schlecht sein? Und außerdem, der letzte Software-Entwickler wollte dies auch schon ändern und hat dabei einen großen Bock geschossen."

Das Problem bei solcher Software ist oftmals, dass der reine Softwareentwickler nicht weiß was da konkret gemacht wird. Das vergrößert die Wahrscheinlichkeit, dass Fehler bei Optimierungen oder Refactoring in den Code kommen, die jemand der von der Fachseite ist, sofort erkennen würde.

elmut19

Nochmal vielen Dank an alle.
Und ja, der Code ist sau alt. Er wurde (zumindest dieser Teil) schon von meinem Vorgänger aus einem vorherigen Projekt übernommen.
Und ich habe mich immer davor gegraut, diesen Teil jemals anfassen zu müssen.
Und nun wars eben soweit.
Ich habe hier ein paar grausige Code-Schnipsel reingestellte, mit denen ich rumexperimentiert habe, um zu sehen, was wann schief geht.
Und mein Programmierwissen bedarf sicherlich auch einer Auffrischung.
Aber bitte beurteilt es nicht nach diesen Codeschnipseln.
Und ja, ich bin auch der einzige, der an dem Ding arbeitet und bekomme die Wünsche zur Weiterentwicklung zugetragen.

Alles was ich gemacht habe, ist:

Ich habe zwei zentrale Objekte, so wie sie zuvor waren, hergenommen und sie in jeweils in eine "std::map" reingesetzt.
Dann habe ich einfach versucht, sie nach Gebrauch ordentlich zu bereinigen.
Auch habe ich das so versucht, wie hier vorgeschlagen, alles an möglichst wenig Stellen und am Ort ihrer Entstehung zu behandeln.

Und @Quiche-Lorraine So wie Du sagst ist es eben mal die Realität.
Man bekommt ein paar hunderttausend Codezeilen nicht mal so eben "reengineered".
Zumal ich noch nicht mal das Kommunikations-Protokoll und die darin immer noch versteckten Fehler alle verstanden habe.
Und diesen knapp 30 Jahre alten Ringspeicher (natürlich undokumentiert) schon gar nicht.
Aber über den läuft nun mal die Kommunikation, und er wird auch irgendwie noch ans HMI weitergereicht.

Beim Versuch die Objekte zu bereinigen sind an vielen Stellen solche Konstrukte zusammengekommen.
Und so wird aus einem anfänglich "einzigen und vermutlich kleinem" Problem eben ein Desaster.

elmut19

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

@elmut19. Warum kannst du cppcheck nicht installieren?

Tja, das wüsste ich auch gerne!
Ich gehe so vor, wie es mir vom System gesagt wird.
Download von der Website und auf "Ausführen" klicken.
Dann kommt halt diese Meldung. Mein VS2019 wird jedenfalls noch erkannt.
Und diesem wird die Zusammenarbeit verweigert

It0101

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

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

@elmut19. Warum kannst du cppcheck nicht installieren?

Tja, das wüsste ich auch gerne!
Ich gehe so vor, wie es mir vom System gesagt wird.
Download von der Website und auf "Ausführen" klicken.
Dann kommt halt diese Meldung. Mein VS2019 wird jedenfalls noch erkannt.
Und diesem wird die Zusammenarbeit verweigert

CppCheck ist eigentlich eine eigenständige Anwendung. Auf die Integration in VS bist du nicht unbedingt angwiesen.

elmut19

@It0101 Aha. Vielen Dank!
Ich habe ein gleichnamiges Paket als ".vsix"-Datei unter den Erweiterungen von VS2019 gefunden. Und das lies sich nicht installieren.

Das eigenständige cppcheck habe ich mal bei mir zuhause installiert.
Und da muss ich mich wohl einarbeiten.
Aber erstmal habe und brauche ich diese Woche mal Urlaub.

It0101

CPPCheck ist kein Hexenwerk. Neue Projektdatei erstellen und los gehts. Dann bekommst du die einzelnen Dateien mit auffälligen Codestellen aufgelistet. Etwas filtern kannst du auch noch.

CPPCheck ist kein Gesetzbuch, aber es macht Sinn sich die Meldungen zumindest mal anzusehen und dann individuell zu entscheiden ob es Sinn macht, den Code anzupassen.

elmut19

@It0101 Also CppCheck findet auch nix Relevantes.
Leider ist es nichtmal in der Lage, alle Dateien im Projekt einzulesen.

@DocShoe Smartpointer habe ich nur mal kurz, also ganz kurz angelesen.
Das scheint eher den Sinn zu haben, dass man auf ein "delete()" zum Abschluss verzichten kann.
Denke nicht, dass das mein Problem löst.

Habe nun sogar noch einen Trick versucht, um die "map" zu verarschen,
indem ich sie, statt des Pointers auf mein Objekt, mit einem "void*" pointer versehe.
NEIN! Die "map" lies sich nicht verarschen!

Tyrdal

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

@It0101 Also CppCheck findet auch nix Relevantes.
Leider ist es nichtmal in der Lage, alle Dateien im Projekt einzulesen.

@DocShoe Smartpointer habe ich nur mal kurz, also ganz kurz angelesen.
Das scheint eher den Sinn zu haben, dass man auf ein "delete()" zum Abschluss verzichten kann.
Denke nicht, dass das mein Problem löst.

Warum denkst du das? Memory management ist ja augenscheinlich die Ursache für deine Probleme. Warum also das Thema nicht radikal vereinfachen?

Habe nun sogar noch einen Trick versucht, um die "map" zu verarschen,

Ganz schlechte Idee. Die Map ist eh nicht das Problem.

indem ich sie, statt des Pointers auf mein Objekt, mit einem "void*" pointer versehe.
NEIN! Die "map" lies sich nicht verarschen!

Siehste.

elmut19

@Tyrdal
Klar Memorymanagement!
Aber das verstehe ich leider nicht an der Stelle, gerade das mit dem "Orphan".
Ich hatte ja schon alle erdenklichen Zugriffsfehler an dieser Stelle.
Aber alle, bis auf diesen, sind leicht erkennbar und lösbar.
Und hier ist die "map" sogar leer und alle Objekte, die darin waren, wurden ordentlich bereinigt!

Und noch eine kurze Korrektur zu einer vorherigen Aussage:
Wenn ich eine Release-Version baue, statt es im Debugger laufen zu lassen,
wird die Anwendung ohne eine Fehlermeldung beendet!

Tyrdal

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

@Tyrdal
Klar Memorymanagement!
Aber das verstehe ich leider nicht an der Stelle, gerade das mit dem "Orphan".
Ich hatte ja schon alle erdenklichen Zugriffsfehler an dieser Stelle.
Aber alle, bis auf diesen, sind leicht erkennbar und lösbar.
Und hier ist die "map" sogar leer und alle Objekte, die darin waren, wurden ordentlich bereinigt!

Da hat wohl vorher was den den Speichern durcheinandergebracht.

Und noch eine kurze Korrektur zu einer vorherigen Aussage:
Wenn ich eine Release-Version baue, statt es im Debugger laufen zu lassen,
wird die Anwendung ohne eine Fehlermeldung beendet!

Im Debugmode können zusätzliche Sachen laufen (Bounds check etc), die im Release so nicht passieren. Deshalb ist der Fehler aber nicht im Release verschwunden.