Delphi-PRAXiS
Seite 2 von 2     12   

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Sonstige Werkzeuge (https://www.delphipraxis.net/63-sonstige-werkzeuge/)
-   -   MadExcept vorteile gegenüber FastMM4 bezogen auf Speicherleaks (https://www.delphipraxis.net/197712-madexcept-vorteile-gegenueber-fastmm4-bezogen-auf-speicherleaks.html)

Whookie 30. Aug 2018 09:40

AW: MadExcept vorteile gegenüber FastMM4 bezogen auf Speicherleaks
 
Zitat:

Zitat von Codehunter (Beitrag 1411995)
@Uwe: Nutzt du die gleichzeitig einkompiliert? So wie ich das obige Zitat verstehe müsste das ja sogar gehen.

Ja, funktioniert problemlos.

Lemmy 30. Aug 2018 10:57

AW: MadExcept vorteile gegenüber FastMM4 bezogen auf Speicherleaks
 
Zitat:

Zitat von Codehunter (Beitrag 1411995)
@Uwe: Nutzt du die gleichzeitig einkompiliert? So wie ich das obige Zitat verstehe müsste das ja sogar gehen.

ich hatte damit noch nie ein Problem...

Uwe Raabe 30. Aug 2018 11:42

AW: MadExcept vorteile gegenüber FastMM4 bezogen auf Speicherleaks
 
Zitat:

Zitat von Codehunter (Beitrag 1411995)
@Uwe: Nutzt du die gleichzeitig einkompiliert? So wie ich das obige Zitat verstehe müsste das ja sogar gehen.

Ja, das geht ohne Probleme. Wie gesagt aktiviere ich den madExcept Leak-Check aber nicht. Damit wird dann auch kein zweiter Memory-Manager eingebunden.

Stevie 30. Aug 2018 12:07

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 Leakcheck laufen gelassen, was eine noch genauere Diagnose bietet als FastMM (z.B. graphische Darstellung von zirkulären Abhängigkeiten).

Codehunter 30. Aug 2018 13:09

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:

freimatz 4. Sep 2018 17:23

AW: MadExcept vorteile gegenüber FastMM4 bezogen auf Speicherleaks
 
Zitat:

Zitat von ngott2 (Beitrag 1411939)
Hallo,
gibt es neben den Vorteil, das man bei MadExcept direkt zur Zeile springen kann weitere Vorteile, die für Madexcept sprechen? Oder gibt es sogar Nachteile? Wichtig nur Vorteile, die auf das finden und fixen von Speicher Leaks bezogen sind. Gerne auch eventuelle Nachteile.

Danke und Gruß.

Auch wenn meine Vorredner überwiegend richtiges schreiben halte ich die Schlussfolgerung für falsch, dass madexcept für die Suche nach Memory Leaks nicht so gut ist.
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.

Ghostwalker 5. Sep 2018 05:17

AW: MadExcept vorteile gegenüber FastMM4 bezogen auf Speicherleaks
 
Öhm...also...den Stack bekomm ich auch bei FastMM4

Auszug:
Code:
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
Aber wie meine Vorredner schon gesagt haben, bietet MadExcept noch einiges mehr, neben den Memoryleaks. Am besten beides einsetzen und gut. :)

Codehunter 5. Sep 2018 07:17

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:

Zitat von Ghostwalker (Beitrag 1412461)
Öhm...also...den Stack bekomm ich auch bei FastMM4

Ja bei FastMM4, IMHO aber nicht bei seinem kleinen Bruder FastMM der bei Delphi mitgeliefert wird.


Alle Zeitangaben in WEZ +1. Es ist jetzt 12:54 Uhr.
Seite 2 von 2     12   

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz