2009-08-12 16 views
2

Ich bemerkte einen sehr interessanten Befund. Ich habe meine Anwendung getestet, bei der ein benutzerdefiniertes GUI-Element verwendet wurde, das durch Daten aktualisiert wurde, die von einer externen Quelle kamen. Die Aktualisierung der GUI erfolgte unter Verwendung einer Slot-Funktion (Qt-spezifisches Detail), wenn Daten auf dem seriellen Port eintrafen. Jetzt kamen die Daten mit einer Rate von 10 Paketen pro Sekunde, d. H. Die Aktualisierungs-GUI-Funktion wurde 10 Pakete pro Sekunde aufgerufen. Dies verlangsamte die Anwendung und führte zu einer ständigen Vergrößerung des Speicherbedarfs. Es begann bei 60 MB und stieg in ein paar Stunden auf 65 MB.C++/Qt-Speicher Leck?

Meine Schlussfolgerung war, dass die Aktualisierung der GUI langsam ist und wenn ein Steckplatz für die Aktualisierung 10 Mal pro Sekunde aufgerufen wird, die Steckplatzaufrufe auf lange Sicht in die Warteschlange gestellt werden und somit die Reaktionszeit der Anwendung beeinträchtigen.

Ich löste dieses Problem durch Zwischenspeichern des eingehenden Werts und Aktualisieren der GUI, wenn der eingehende Wert geändert wurde.

Ich habe verschiedene kostenlose Tools wie valgrind-memcheck, Leak-Checker ausprobiert, aber die Ergebnisse sind nicht hilfreich, in der Tat Leck-Checker findet das Leck nicht, aber meine Programme Speichergröße steigt ständig. Bedeutet dies, dass es wegen der Schlange der Signalschlitzverbindung ist, weil GUI Aktualisierung von sich aus langsam ist?

Jetzt hier liegt das Problem. Das Aufspüren von Speicherlecks ist hart genug und wenn Qt involviert ist, wie kann ein glückloser Programmierer sich des Problems sicher sein, d. H. Ob es tatsächlich ein Speicherleck oder eine Schlange von Signalschlitzverbindungen ist?

+0

Mögliche dupe von http://stackoverflow.com/questions/1186379/detecting-memory-leaks-in-c-qt-combine von demselben Benutzer –

+0

Es ist anders Neil, die frühere Frage war eigentlich eine De-facto-Erinnerung Dieses Posting sollte dieses Problem hervorheben, da viele Leute wie ich nicht wissen werden, dass die Erhöhung der Speichergröße durch das Einreihen von Signal-Slot-Verbindungen verursacht werden kann. – rocknroll

+0

Valgrinds Massiv gibt nichts? –

Antwort

0

Bedeutet das, dass es wegen der Warteschlangen von Signalschlitzverbindung ist als GUI-Update von Natur aus langsam ist?

Ja ...

Stoppen Sie die incomming Ereignisse und Erinnerung muss nach einer gewissen Zeit freigegeben werden.

+0

@Tim In Qt haben wir nur einen GUI-Thread pro Anwendung. Wenn wir nun die Handhabung der Datenerfassung mit diesem Thread für eine externe Geräteschnittstelle vereinigen, würde dies zu einer stetigen Zunahme der Speichergröße führen oder nicht? Weil ich ein solches Szenario in einer Anwendung sehe, die nicht von meinem Team entwickelt wurde. Eine externe Geräteschnittstelle ist mit dem Haupt-GUI-Thread verknüpft. Die Haupt-GUI wird auch aktualisiert, wenn andere externe Geräte Daten zusätzlich zu der Geräteschnittstelle senden, die darauf huckepack ist. Ich vermute, dass dieser Entwurf der Schuldige ist, aber habe keine zuverlässige Quelle gefunden, um meinen Punkt zu untermauern. – rocknroll

+0

Ist es eine direkte oder eingereihte Signalsteckplatzverbindung? – TimW

+0

Ich habe die Standard-Signal-Slot-Einstellungen bis jetzt nicht geändert, also ist es die Standardeinstellung (von der ich nichts weiß, vielleicht sind es Warteschlangen-Verbindungen). – rocknroll

1

Der Speicher ist möglicherweise fragmentiert. AFAIK-Speicher wird nur dann an das Betriebssystem zurückgegeben, wenn es Seitenausrichtung und ein Vielfaches einer Seitengröße aufweist. Einige Speicherzuteiler geben nie Speicher zurück, googles malloc kommt in den Sinn.

Also, wenn Qt oder Ihre App ständig mallocs und kleine Blöcke von zufällig unterschiedlichen Größen freigibt, kann der Speicher gehalten werden. Die Zunahme des Speicherbedarfs sollte sich jedoch im Laufe der Zeit verlangsamen.

Wenn Sie ein QWidget-ähnliches Objekt aktualisieren, stellen Sie sicher, dass Sie update() verwenden und nicht repaint().