QString-Fehler beim Kopieren in qmap.Umfangsausgabe?

Question

Ich bin derzeit in Bezug auf Segfaults (manchmal Sigabrts wegen schlechter Mallocs) festgefahren, wenn ich es versuche, ein QString zu einem QMAP als Schlüssel im Destruktor der Qwidget-Klasse zu fügen, den ich habe Modell und Umfang teilen.

Ich habe ein Qwidget, das als Unterfenster in einem MDI als Unterfenster fungiert, dieses QWIDget verfügt über ein paar qggwidget abgeleitete ViewPort-Instanzen als Kinder. Im Unterfenster befindet sich ein qmap Wrapper-Class, das die Einstellungen der Projektdatei enthält, wenn das Unterfenster geschlossen ist, der Zerstörungsdestruktor nennt Qwidget :: deletechildren (), der jedes der Ansichtsfenster löscht. Im Ansichtsfenster Destructor werden die aktuellen Einstellungen in den Einstellungen des Unterfensters gespeichert, zB: generasacodicetagpre.

Der SWIN.SETSETTING () wird für jede der Eigenschaften aufgerufen, die ich speichern möchte, 'SWIN' ist ein Verweis auf die QMAP-Wrapper-Klasse, die am Ende des Unterfenstendestillusters gelöscht wird. Alles ist in Ordnung, bis der Setsetting () anrufen, was gerade ist: generasacodicetagpre.

Dieses Setup funktioniert feines für den ersten Ansichtsfenster , am ersten Sollsetting () -Anruf des zweiten, ein Segfault auf: generasacodicetagpre.

Ich sehe eine tiefe Kopie fehl, wenn meine QString-Referenz an das QMAP übergeben wird? Wenn ja warum? Das angesetzte QString, das ich erstellt habe, ist noch nicht aus dem Umfang gegangen, da der Destruktor nicht zurückgekehrt ist. Und warum sollte dies auf dem zweiten Ansichtsfenster fehlschlagen und nicht das erste?

Gelegentlich bekomme ich einen Sigabrt malloc (): Speicherbeschädigung in Operator + in der Setsetting-Zeile des ersten Codebeispiels. Aber wieder, zu Beginn der Zerstörung des zweiten Ansichtsfensters, nicht der erste.

Ich entschuldige mich für die sehr wortreiche Frage, aber es besteht ein großer Teil an Code, der sich über viele Übersetzungseinheiten erstreckt. Alle Hinweise für dieses Problem wären eine große Hilfe!

Vielen Dank im Voraus. Cam

---

update

Ich habe mein erstes Codeprobe geändert an: generasacodicetagpre.

als Test für Geltungsfragen. Und es manchmal funktioniert, und andere Zeiten gibt genau den gleichen Fehler an; Vermutlich wird der Haufen-QString zerstört, es hängt nur davon ab, ob der Speicherort des Speicherplatzes überschrieben wurde oder nicht. Dies macht jedoch auch keinen Sinn, da ich nicht daraus lösche, noch schließe ich die Anwendung (nur ein MDI-Subfenster)!

---

mehr Code

SWIN erstellt auf dem Haufen, wenn ein neues Unterfenster instanziiert ist. Es wird als Referenz von einer Methode aus meinem Subfenster in den Zerstörer der ViewPort-Klasse gebracht: generasacodicetagpre.

sy_project ist (derzeit) eine einfache Wrapper-Klasse für QMAP. Meine komplette ViewPort-Basisklasse-Destruktor ist dies (er schlägt hier nicht in der abgeleiteten Klasse): generasacodicetagpre.

---

valgrind

Nach der Verwendung von Valgrinds Memcheck entdeckte ich zahlreiche Einträge, die meinem Stacktrace ähnlich aussahen. Nachdem ich es noch nie benutzt habe, entschleife ich immer noch, sondern sagt, dass meine SY_PROJECT-Klasse (Wrapper für QMAP) nicht gelöscht wurde nach den Setsetseting-Anruf, der QMAP mit einem ungültigen Referenz verließ? generasacodicetagpre.

Answer 1

I think the Sy_project object your pointer and therefore references are pointing to is already destroyed by the time the destructor of Sy_abstractGLViewport is called. If you look into the valgrind listing, the destructor of Sy_project is called before the destructor of Sy_abstractGLViewport.

So when you call inline Sy_project& getProject() { return *project_; } within the Sy_abstractGLViewport destructor, you're dereferencing a dangling pointer.

Answer 2

Hum... What happens if you change your code for something like this:

dir.append("/Projection");
sWin.setSetting(dir, static_cast<int>(camera_->getProjectionType()));

In the way you are doing a temporary copy is create and then bound to a reference-to-const, which should be ok. Afterwards, from this reference QMap will attempt to copy the argument, in this case, going through the implicit sharing mechanism of QString. I'm just wondering what could go wrong in there...