AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Sprachen und Entwicklungsumgebungen Sonstige Werkzeuge MadExcept vorteile gegenüber FastMM4 bezogen auf Speicherleaks
Thema durchsuchen
Ansicht
Themen-Optionen

MadExcept vorteile gegenüber FastMM4 bezogen auf Speicherleaks

Ein Thema von ngott2 · begonnen am 29. Aug 2018 · letzter Beitrag vom 5. Sep 2018
Antwort Antwort
Seite 2 von 2     12   
Whookie

Registriert seit: 3. Mai 2006
Ort: Graz
445 Beiträge
 
Delphi 10.3 Rio
 
#11

AW: MadExcept vorteile gegenüber FastMM4 bezogen auf Speicherleaks

  Alt 30. Aug 2018, 10:40
@Uwe: Nutzt du die gleichzeitig einkompiliert? So wie ich das obige Zitat verstehe müsste das ja sogar gehen.
Ja, funktioniert problemlos.
Whookie

Software isn't released ... it is allowed to escape!
  Mit Zitat antworten Zitat
Lemmy

Registriert seit: 8. Jun 2002
Ort: Berglen
2.381 Beiträge
 
Delphi 10.4 Sydney
 
#12

AW: MadExcept vorteile gegenüber FastMM4 bezogen auf Speicherleaks

  Alt 30. Aug 2018, 11:57
@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...
  Mit Zitat antworten Zitat
Benutzerbild von Uwe Raabe
Uwe Raabe
Online

Registriert seit: 20. Jan 2006
Ort: Lübbecke
11.475 Beiträge
 
Delphi 12 Athens
 
#13

AW: MadExcept vorteile gegenüber FastMM4 bezogen auf Speicherleaks

  Alt 30. Aug 2018, 12:42
@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.
Uwe Raabe
Certified Delphi Master Developer
Embarcadero MVP
Blog: The Art of Delphi Programming
  Mit Zitat antworten Zitat
Benutzerbild von Stevie
Stevie

Registriert seit: 12. Aug 2003
Ort: Soest
4.027 Beiträge
 
Delphi 10.1 Berlin Enterprise
 
#14

AW: MadExcept vorteile gegenüber FastMM4 bezogen auf Speicherleaks

  Alt 30. Aug 2018, 13:07
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).
Stefan
“Simplicity, carried to the extreme, becomes elegance.” Jon Franklin

Delphi Sorcery - DSharp - Spring4D - TestInsight

Geändert von Stevie (30. Aug 2018 um 13:12 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von Codehunter
Codehunter

Registriert seit: 3. Jun 2003
Ort: Thüringen
2.272 Beiträge
 
Delphi 10.4 Sydney
 
#15

AW: MadExcept vorteile gegenüber FastMM4 bezogen auf Speicherleaks

  Alt 30. Aug 2018, 14:09
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
Ich mache grundsätzlich keine Screenshots. Schießen auf Bildschirme gibt nämlich hässliche Pixelfehler und schadet der Gesundheit vom Kollegen gegenüber. I und E zu vertauschen hätte den selben negativen Effekt, würde aber eher dem Betriebsklima schaden
  Mit Zitat antworten Zitat
freimatz

Registriert seit: 20. Mai 2010
1.456 Beiträge
 
Delphi 11 Alexandria
 
#16

AW: MadExcept vorteile gegenüber FastMM4 bezogen auf Speicherleaks

  Alt 4. Sep 2018, 18:23
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.
  Mit Zitat antworten Zitat
Ghostwalker

Registriert seit: 16. Jun 2003
Ort: Schönwald
1.299 Beiträge
 
Delphi 10.3 Rio
 
#17

AW: MadExcept vorteile gegenüber FastMM4 bezogen auf Speicherleaks

  Alt 5. Sep 2018, 06:17
Ö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.
Uwe
e=mc² or energy = milk * coffee²
  Mit Zitat antworten Zitat
Benutzerbild von Codehunter
Codehunter

Registriert seit: 3. Jun 2003
Ort: Thüringen
2.272 Beiträge
 
Delphi 10.4 Sydney
 
#18

AW: MadExcept vorteile gegenüber FastMM4 bezogen auf Speicherleaks

  Alt 5. Sep 2018, 08:17
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.
Ö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.
Ich mache grundsätzlich keine Screenshots. Schießen auf Bildschirme gibt nämlich hässliche Pixelfehler und schadet der Gesundheit vom Kollegen gegenüber. I und E zu vertauschen hätte den selben negativen Effekt, würde aber eher dem Betriebsklima schaden
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 2 von 2     12   


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 23:10 Uhr.
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