[Assimp] Memory Leaks bei statischem Linken

[mOfl]

Hallo ihr,

das Animationsproblem aus dem anderen Thread ist zwar noch nicht gelöst, aber ich habe momentan nicht genug Zeit, einen ausführlichen Post mit meinem Code dazu zu erstellen... Bis dahin kümmere ich mich eben um andere Dinge, momentan das statische Linken von Assimp. Zuerst habe ich dynamisch gelinkt, das hat wunderbar funktioniert und hatte keine Memory Leaks (ich verwende VLD für das Tracking). Dann habe ich eine statische Bibliothek des Typs Multithreaded Debug für meine Debug-Konfiguration erstellt. Auch hier läuft alles ohne Probleme, beim Beenden meldet VLD allerdings einige Memory Leaks nach dem Muster:

Code: Alles auswählen

---------- Block 183709 at 0x061E88F8: 0 bytes ----------
  Call Stack:
    0x009EEF39 (File and line number not available): Assimp::XFileImporter::CreateAnimations
    0x009ECDDF (File and line number not available): Assimp::XFileImporter::CreateDataRepresentationFromImport
    0x009ECC5C (File and line number not available): Assimp::XFileImporter::InternReadFile
    0x009F2937 (File and line number not available): Assimp::BaseImporter::ReadFile
    0x007EEA0B (File and line number not available): Assimp::Importer::ReadFile
    0x007DA7DD (File and line number not available): aiImportFileEx
    0x007DA5CD (File and line number not available): aiImportFile
    c:\prog\src\modellib\model.cpp (306): Model::Init
    ...

  Data:

Ehrlich gesagt weiß ich nicht allzu viel mit dieser Information anzufangen, da für mich ein 0 byte großes Leak kein Leak ist. Die Zeile in Init(), auf die verwiesen wird, lautet

Code: Alles auswählen

g_pScene = aiImportFile(m_sModelPath.mb_str(), aiProcessPreset_TargetRealtime_MaxQuality);

Im Destruktor der Model-Klasse steht dann noch

Code: Alles auswählen

aiReleaseImport(g_pScene);

was auch aufgerufen wird. Ich bin bisher davon ausgegangen, dass aiReleaseImport() die einzige Funktion ist, die ich zum Aufräumen aufrufen muss.

Weiß einer, was hier passiert? Ist das ein Problem des statischen Linkens? Wie gesagt, mit der dynamischen Bibliothek wurden keine Leaks angezeigt. Ich verwende übrigens Visual Studio 2008 Professional und die Assimp-Version 2.0. Es ist ja nicht so, dass das jetzt die wahnsinnigen Löcher in den Speicher reißen würde, nur ist man doch immer bestrebt, alle Memory Leaks aus dem Code zu bekommen.

Ich hoffe, da kann einer helfen.

Gruß
mOfl



Edit: Neben den vielen gleichlautenden Leaks wird auch noch ein einziger gefunden:

Code: Alles auswählen

---------- Block 163491 at 0x061B3068: 4 bytes ----------
  Call Stack:
    0x007EA607 (File and line number not available): Assimp::Intern::AllocateFromAssimpHeap::operator new
    0x007EA797 (File and line number not available): Assimp::Importer::Importer
    0x007DA6E2 (File and line number not available): aiImportFileEx
    0x007DA5CD (File and line number not available): aiImportFile
    c:\prog\src\modellib\model.cpp (306): Model::Init
    ...
  Data:
    44 63 CC 00                                                  Dc...... ........

[Krishty]

Ehrlich gesagt weiß ich nicht allzu viel mit dieser Information anzufangen, da für mich ein 0 byte großes Leak kein Leak ist.

Auch ein 0 Byte großes Leak belegt mindestens ein Byte im Adressraum, weil new für alle Allokationen (inklusive der für 0 Bytes) eine einzigartige Adresse zurückgeben muss … zuzüglich Unkosten.

@Team: Ich pushe hier auch gleich mal mein Anliegen, die über 300 potentiellen Speicherlecks beim Wurf einer Exception zu entfernen: Lasst solche Konstruktionen wie if(objx && num_objx) { …; delete objx; }, wie sie zu Hauf vorkommen. Schreibt sie auch nicht um, indem ihr das delete aus dem if rauszieht. Lasst einfach was drüberlaufen, das jeden Zeiger durch einen scoped_ptr ersetzt oder so … der Grad an manueller Speicherverwaltung ist furchterregend hoch. (Ich würde hier jetzt eigentlich der Antwort, dass die Textbasis zu groß sei, vorweg nehmen, dass ihr dann zumindest im neuen Text (Exporter und so) verstärkt automatische Speicherverwaltung einsetzt. Da ich mir aber die letzten hundert Aktualisierungen nicht angesehen habe, weiß ich nicht, ob ihr das nicht schon tut und ich hier zu Unrecht meckere.)

… und ein Moderator verschiebt das Thema ggf. nach Programmiersprachen, Quelltext & Bibliotheken. Nachtrag: Okay, disregard that – alles Assimp-mäßige scheint in Grafikprogrammierung zu landen

[Schrompf]

Das erste Leck könnte mein Fehler sein - ich weiß nicht, was der XFileImporter da genau tut, aber ich schau mal nach. Was das Importer-Leck angeht... hm. Keine Ahnung. Die Lecks bei Exceptions sind aber wirklich seltsam. Wir benutzen eine Menge manueller Allokationen per new, aber doch nur für alles in der aiScene, was halt Plain Arrays sein müssen. Für alles andere nimmt man doch eh immer std::vector und Konsorten, oder?

[Krishty]

Für alles andere nimmt man doch eh immer std::vector und Konsorten, oder?

Sollte man nehmen ;) Die 300 Lecks sind noch von letztem Jahr, als ich die statische Code-Analyse des VCpp10-RCs habe drüberlaufen lassen. Momentan kommt „new“ 1200× in Assimp vor – die Hälfte sind Kommentare und vom Rest wird nochmal ein großer Teil direkt Datenstrukturen zugewiesen; die Größenordnung kommt also in etwa hin.

[mOfl]

Hallo und vielen Dank erst mal für eure Antworten!

Ich sollte vielleicht noch dazu sagen, dass ich FastSTL nicht verwenden kann, weil es sonst Fehler beim Linken gibt, sprich ich habe das Sheet .\shared\FastSTL.vsprops aus der Build-Konfiguration entfernt, bevor ich die Libs erstellt habe. Ich habe das auch noch einmal gegengetestet mit vielen anderen Kombinationen mit FastSTL, ohne, Debug, Release, statisch, dynamisch, immer mit dem gleichen Ergebnis: Wenn es linkbar ist, gibt es mit statischen Linken beim Beenden Memory Leaks, bei dynamischem Linken nicht.

Also zum Reproduzieren:
Konfiguration "debug", kein FastSTL-Sheet, Statische Bibliothek, Multithreaded-Debug (/MTd) -> Memory Leaks in meiner Anwendung
Konfiguration "release-dll", FastSTL-Sheet ist dabei, Dynamische Bibliothek, Multithreaded-DLL (/MD) -> keine Memory Leaks in meiner Anwendung

Vielleicht hilft das ja.

Gruß

mOfl

[Krishty]

Wenn es linkbar ist, gibt es mit statischen Linken beim Beenden Memory Leaks, bei dynamischem Linken nicht.

Auch nicht, wenn du bei dynamischer Bindung ein Speicherleck erzwingst?

[mOfl]

Auch nicht, wenn du bei dynamischer Bindung ein Speicherleck erzwingst?

Wie würde ich das anstellen? Auch wenn ich aiReleaseImport(g_pScene); beim Beenden auskommentiere, werden mit dynamischen Linken keine Leaks gefunden.

[Krishty]

Schreib mal irgendwo in die DLL new int[256]; und guck, ob er was meldet … ich habe nämlich den Verdacht, dass in Laufzeitbibliotheken nicht deshalb keine Lecks gefunden werden weil keine auftreten, sondern weil das Tool nur mit einem einzigen Modul was anfangen kann (z.B., weil jedes Modul einen eigenen Heap benutzt.)

[Schrompf]

Exakt. Alle Allokationen in der DLL passieren im dll-eigenen Heap - die wird der VLD einfach nicht erfassen. Die Leaks werden da genauso da sein. Ich gehe der Sache mal nach - ich linke ja immer statisch, und der VLD müsste in absehbarer Zeit eingerichtet sein.

[mOfl]

Ja, du hast recht. Auch, wenn ich in der DLL allerlei Zeug anlege, ohne es wieder freizugeben, werden in meiner Anwendung keine Memory Leaks gefunden. Hm, nicht sehr beruhigend.

[mOfl]

Ich hab die Lib jetzt nochmal erstellt mit allen Debug-Informationen, dann werden die Leaks angezeigt (ich importiere ein .x-File):

Code: Alles auswählen

---------- Block 183732 at 0x08F34630: 0 bytes ----------
  Call Stack:
    c:\users\dani\desktop\assimp--2.0.863-sdk\code\xfileimporter.cpp (516): Assimp::XFileImporter::CreateAnimations
    c:\users\dani\desktop\assimp--2.0.863-sdk\code\xfileimporter.cpp (133): Assimp::XFileImporter::CreateDataRepresentationFromImport
    c:\users\dani\desktop\assimp--2.0.863-sdk\code\xfileimporter.cpp (115): Assimp::XFileImporter::InternReadFile
    c:\users\dani\desktop\assimp--2.0.863-sdk\code\baseimporter.cpp (86): Assimp::BaseImporter::ReadFile
    c:\users\dani\desktop\assimp--2.0.863-sdk\code\importer.cpp (1010): Assimp::Importer::ReadFile
    c:\users\dani\desktop\assimp--2.0.863-sdk\code\assimp.cpp (295): aiImportFileEx
    c:\users\dani\desktop\assimp--2.0.863-sdk\code\assimp.cpp (262): aiImportFile
    c:\prog\src\modellib\model.cpp (343): Model::Init

und

Code: Alles auswählen

---------- Block 163578 at 0x068B3100: 4 bytes ----------
  Call Stack:
    c:\users\dani\desktop\assimp--2.0.863-sdk\code\importer.cpp (271): Assimp::Intern::AllocateFromAssimpHeap::operator new
    c:\users\dani\desktop\assimp--2.0.863-sdk\code\importer.cpp (319): Assimp::Importer::Importer
    c:\users\dani\desktop\assimp--2.0.863-sdk\code\assimp.cpp (275): aiImportFileEx
    c:\users\dani\desktop\assimp--2.0.863-sdk\code\assimp.cpp (262): aiImportFile
    c:\prog\src\modellib\model.cpp (343): Model::Init

Ich hoffe, die genauen Zeilenangaben helfen bei der Fehlersuche :)

Gruß
mOfl

[Schrompf]

Ja, das hilft. Vielen Dank. Ich habe am Montag selbst versucht, den VLD zum Laufen zu bekommen, aber der hat trotz artiger Ausgabe beim Start selbst ein plumpes new int[200] nicht als Leck gemeldet... tja. Und meine eigenen Versuche, einen schnellen Speicherlogger hinzulegen, sind an diversen Altgurken in Assimp gescheitert. Irgendwer damals hatte diese großartige Idee, den Logger als Singleton zu gestalten und diverse Helferobjekte in den Besitz der Lib übergehen zu lassen. Damit muss man dann natürlich eine Menge Aufwand mit überladenem new betreiben, damit das über DLL-Grenzen hinweg nicht scherbelt. Und das überladene new hat dann meine hastigen Versuche ruiniert, selbst new zu überladen.

Es gibt angeblich irgendwo in Visual C++ auch eine eingebaute Leak Detection - aber wo?

[joggel]

Es gibt angeblich irgendwo in Visual C++ auch eine eingebaute Leak Detection - aber wo?

Ja, davon habe ich auch mal gehört.
Hab mal gegoogelt und das hier gefunden:
http://msdn.microsoft.com/en-us/library ... 80%29.aspx
Vlt. hilft das.

[kimmi]

Die Idee mit dem Singleton hatte ich. Vielleicht kann man das ja glattziehen, wenn du mir erklärst, was genau du brauchst. Also was man wie ändern sollte, damit man nicht in die von dir aufgezeigten Probleme läuft. Dein etwas spöttischer Hinweis allein reicht mir bedauerlicherweise nicht als Bugreport ;).

Womit hattest du wann und aus welchen Gründen Probleme? Welche Helferobjekte leaken wo oder beschreib mal, was kaputt war. Daraus können wir gern einen neuen Thread machen, aber bitte etwas sachlicher als "Da hat damals wer ganz viel Schxxx gebaut und deswegen kriege ich hier nur Ärger!" nützt niemanden beim Lösen des von dir aufgedeckten Problemes.

Und wenn du wissen willst, wie man mit der VS-Leakdetection umzugehen hat: http://sir-kimmi.de/blog/?p=14

Gruß Kimmi

[Schrompf]

Das war auch kein Bugreport. Wir hatten damals eine längliche Architektur zum Thema Logger, die halt so ausgegangen ist. Ohne groben Umbau ist daran jetzt nichts mehr zu ändern. Mein Geschimpfe war einfach nur Teil einer Frustbewältigung, weil ich einen Abend meiner Freizeit ergebnisfrei auf die Assimp-Speicherlecks verwendet hatte.

Ich werde jetzt mit der VS-LeakDetection suchen gehen. Dann gibt es zwar keinen Callstack zu jedem Leak, aber damit kann ich leben.

[kimmi]

Zu dem Logger:
Na, ja, dann packen wir den Logger-Umbau halt auf die ToDo. Wenn er soviel Ärger gemacht hat, scheint sicht das zu lohnen, dort zu drehen.

Zu den Leaks:
hat jemand ein funktionierendes Linux vorliegen? Wir könnten dort mit Valgrind versuchen, das Ganze zu debuggen. Ansonsten kann man auch mit AppVerifier oder umdh versuchen, die Leaks zu finden. Am besten wäre es wohl, alles mal zu probieren. Die Tools haben alle ihre verschiedenen Stärken und Schwächen.

Gruß Kimmi