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

[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.

[elmut19]

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

Deshalb ist der Fehler aber nicht im Release verschwunden.

Deshalb versuche ich ja das Zeug verzweifelt zu verstehen und auch zu korrigieren.

[Tyrdal]

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

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

Deshalb ist der Fehler aber nicht im Release verschwunden.

Deshalb versuche ich ja das Zeug verzweifelt zu verstehen und auch zu korrigieren.

Sicher? Die Hinweise nimmst du nicht besonders ernst.

[elmut19]

@Tyrdal natürlich nehme ich sie ernst.
Aber alles Ernstnehmen hilft nix, wenn ich das Problem nicht finde.

Mein Vorgänger hat nun mal eine äusserst verschachtelte Struktur aufgebaut,
die ich nicht ohne Neubau der ganzen Anwendung umformen kann,
und die ich leider auch nur oberflächlich verstehe.

Mir scheint langsam, dass ich um ein persönliches Coaching nicht rumkomme.

[SeppJ]

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

Mein Vorgänger hat nun mal eine äusserst verschachtelte Struktur aufgebaut,
die ich nicht ohne Neubau der ganzen Anwendung umformen kann,
und die ich leider auch nur oberflächlich verstehe.

Das ist natürlich ein Problem, aber was sollen wir da sonst noch empfehlen? Es gibt einen Fehler in einem hochkomplexen System, sprich das System ist fehlerhaft gebaut. Was hast du für Optionen, diesen Fehler zu beheben, außer

a) Das hochkomplexe System komplett zu verstehen und damit auch den Fehler (und das Schlimmste: Verstehen garantiert nicht einmal, dass man den Fehler dann auch beheben kann)
b) Ein neues System ohne Fehler zu bauen

?

Ist doch klar, dass wir da Option b empfehlen werden, zumal es ziemlich offensichtlich ist, dass die Komplexität nicht nötig ist. Option a kannst nur du alleine machen, außer du stellst jemanden von uns ein. Und eine andere Option gibt es halt nicht wirklich. Es gibt keinen magischen "mach den Fehler weg" Knopf in der Programmierung.

[elmut19]

@SeppJ so siehts wohl aus ....
Hatte gehofft, es gäbe für das "Orphan" eine überschaubare Eingrenzungsmöglichkeit der Fehlerart.
Vielen Dank nochmals an alle.

[It0101]

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

Leider ist es nichtmal in der Lage, alle Dateien im Projekt einzulesen.

Da würde ich dir raten, der Sache mal nachzugehen. Er liest eigentlich alles ein.
Andererseits klingt das Projekt, als wären auch, in Macros versteckte, Klassen zu erwarten, oder irgendwelche Schutzschilde um Qualitätskontrolle zu verhindern.

#ifdef CPPCHECK
     #define HIDE_SOURCECODE
#endif

[It0101]

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

Mir scheint langsam, dass ich um ein persönliches Coaching nicht rumkomme.

Du kommst um ein Redesign dieser Komponenten nicht herum. Aber ich verstehe dich gut. Man bekommt uralten Quellcode vorgeworfen, aber vom Chef nicht die Zeit dafür, den ganzen Misthaufen mal neu zu machen. Man kennt es...

[elmut19]

@It0101 Mein Vorgänger war sehr verliebt in Makros.

[It0101]

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

@It0101 Mein Vorgänger war sehr verliebt in Makros.

Noch ein Punkt mehr für das Redesign.

Du kannst jetzt hier noch 10 Seiten schreiben, aber ich lese da nur:

Redesign Redesign Redesign Redesign Redesign Redesign Redesign Redesign Redesign Redesign

[Swordfish]

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

Redesign Redesign Redesign Redesign Redesign Redesign Redesign Redesign Redesign Redesign

https://www.youtube.com/watch?v=xCGu5Z_vaps

[Schlangenmensch]

@elmut19 Da ich jetzt an einem Problem saß, dass eine ähnliche Symptomatik aufwies musste ich an den Thread hier denken. Ich bin z.B. auch irgendwie mal in so 'nem _Orphan_ptr gelandet (leider nicht deterministisch), aber nicht erst beim Beenden, sondern auch zur Laufzeit.

Bei mir lag das Problem daran, dass wir Referenzen auf Vektor Elemente gehalten haben. Das hat auch soweit funktioniert, bis der Vektor vergrößert wurde und mehr Kapazität benötigte. Damit waren dann natürlich die Referenzen ungültig und haben ins Nirvana gezeigt.

Das ganze ist entweder mit 'nem Orpahn_ptr, oder mit 'ner Heap Corruption mir um die Ohren geflogen. Vlt hast du ja eine ähnliche Problematik, nur als Idee, wodran sowas liegen kann.

[elmut19]

@Schlangenmensch
Vielen Dank Schlangenmensch für die Info.
In der Zwischenzeit musste ich mich erstmal einer anderen Sache widmen.
Nun muss ich wieder zum alten Thema zurück.
Ich werd in der Richtung weitermachen und mir dieses merkwürdige RSP-Objekt näher ansehen.
Bei einem "erase()" auf die "map", an der falschen Stelle, passierts bei mir ja auch.

[Quiche Lorraine]

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

Ich werd in der Richtung weitermachen und mir dieses merkwürdige RSP-Objekt näher ansehen.
Bei einem "erase()" auf die "map", an der falschen Stelle, passierts bei mir ja auch.

Versuche auch mal deinen Code einzuengen.

Hierzu kannst du im ersten Schritt assert() Anweisungen in deinen Code einfügen, welche Dinge zusichern. Ist z.B. die Variable n immer größer 0, aber als int definiert, so kannst du dies mittels assert(n > 0) prüfen.

Zusätzlich kannst du auch C++ zur Fehlersuche nutzen. So hatte ich beispielsweise alle memset Aufrufe durch eine von mir selbst geschriebene Template memset Funktion ersetzt, welche überprüft ob der Datentyp ein POD ist bzw. ob std::is_standard_layout<T>::value und std::is_trivially_copyable<T> gilt. So entdeckte ich einige memset() Aufrufe auf Klasseninstanzen. Auch eine Anweisung bool operator==(std::wstring&, char* s) = delete;liefert mir schon den ein oder anderen Fehler.

Ferner musst du versuchen eine Testreihe aufzubauen. Das ganze hat nämlich den Charme dass du Änderungen leicht überprüfen kannst. Hast du eine Änderung vorgenommen, aber deine Testreihe schlägt an, so ist da ein Fehler. Das ist natürlich keine Lösung zu 100%, aber es hilft ungemein beim portieren.

PS:
Habe auch mal vor der Aufgabe gestanden 30k C Code nach C++ zu portieren.