![]() |
AW: MadExcept vorteile gegenüber FastMM4 bezogen auf Speicherleaks
Zitat:
|
AW: MadExcept vorteile gegenüber FastMM4 bezogen auf Speicherleaks
Zitat:
|
AW: MadExcept vorteile gegenüber FastMM4 bezogen auf Speicherleaks
Zitat:
|
AW: MadExcept vorteile gegenüber FastMM4 bezogen auf Speicherleaks
madExcept hat auch Handle Leak Erkennung, aber das hab ich damals in unserer großen Anwendung nicht richtig zum Laufen bekommen.
Wir benutzen madExcept, um unbehandelte Fehler abzufangen und anzuzeigen (auch in Release Builds) und FastMM mit FullDebug für Debug Builds während der Entwicklung. Außerdem werden unsere Unittests mit ![]() |
AW: MadExcept vorteile gegenüber FastMM4 bezogen auf Speicherleaks
Das erste Mal das ich auf MadExcept in freier Wildbahn gestoßen bin, war bei HeidiSQL. Da fand ich das schon sehr spannend, dass man bei einer Exception die Anwendung fortsetzen konnte. Das hat in ungefähr 80% aller Fälle geklappt, sodass man noch die Chance hatte das ein oder andere zu speichern bevor das Ganze dann doch final abgeraucht ist. Ich schätze ich werde mir MadExcept denn auch demnächst mal genauer anschauen. So denn Zeit ist :roll:
|
AW: MadExcept vorteile gegenüber FastMM4 bezogen auf Speicherleaks
Zitat:
Ich halte madExcpt für das Finden von Memory-Leaks für wesentlich besser. Der Punkt ist der, dass ich bei dem für jedes Leak einen kompletten Stacktrace der Erzeugung bekomme. Das ist extrem wichtig wenn eine Klasse oder String leakt die an meheren Stellen im Programm erzeugt werden. Bei FastMM bekommt man nur die Info was und wie oft leakt, nicht aber wo. Da nehme ich die Langsamkeit bei der Analyse gerne in kauf. Andererseits ist die Frage überflüssig, denn madExcept ist auch aus anderen Gründen einfach unverzichtbar. Und da man es schon hat, kann man es auch einfach mal ausprobieren. |
AW: MadExcept vorteile gegenüber FastMM4 bezogen auf Speicherleaks
Öhm...also...den Stack bekomm ich auch bei FastMM4
Auszug:
Code:
Aber wie meine Vorredner schon gesagt haben, bietet MadExcept noch einiges mehr, neben den Memoryleaks. Am besten beides einsetzen und gut. :)
A memory block has been leaked. The size is: 36
This block was allocated by thread 0x3230, and the stack trace (return addresses) at the time was: 4070DE [System][@GetMem$qqri] 40AB9F [System][@NewUnicodeString$qqri] 40BBEF [System][@UStrSetLength$qqrr20System.UnicodeStringi] 4103B7 [System][UTF8ToUnicodeString$qqrrx29System.%SmallString$uc$i255$%] 4FEE7E [Vcl.Graphics][Graphics.TFont.GetName] 6B42CE [VTEditors.Core.pas][VTEditors.Core][Core.TFontData.FromFont][255] 6D9646 [VTEditors.VTDialogs.pas][VTEditors.VTDialogs][Vtdialogs.TVTFontDialog.AfterCall][315] 6D92DF [VTEditors.VTDialogs.pas][VTEditors.VTDialogs][Vtdialogs.TVTDialogExtendedBase.Call][240] 6C9F6C [VTEditors.DialogsManager.pas][VTEditors.DialogsManager][Dialogsmanager.DialogManager.CallDialogEx][132] 6E08A8 [VTEditors.ButtonControl.pas][VTEditors.ButtonControl][Buttoncontrol.TVTButton.InternalClickHandler][232] 5246D5 [Vcl.Controls][Controls.TControl.Click] The block is currently used for an object of class: UnicodeString |
AW: MadExcept vorteile gegenüber FastMM4 bezogen auf Speicherleaks
Ich denke zusammenfassend kann man sagen, dass es sehr wohl funktionelle Überschneidungen gibt. Die Unterschiede liegen dann in der konzeptionellen Ausrichtung. FastMM4 entstand ja mit dem Ziel, den (damals) suboptimalen Speichermanager von Delphiprogrammen zu ersetzen. Das ist auch so gut gelungen, dass er sogar offiziell von (damals glaub ich noch) Inprise ersetzt wurde. MadExcept geht es mehr um das Abfangen von Exceptions u.ä. ohne dass ein Debugger hinten dran hängt, also in freier Wildbahn.
Zitat:
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 04:49 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz