![]() |
Allgemeine Schutzverletzung bei Programmende
Hallo,
seit etlichen Wochen plagen mich allgemeine Schutzverletzungen bein Programmende und ich komme nicht weiter. Mit bestimmten Ständen meiner SW und einer bestimmten Bedienung tritt er recht zuverlässig auf. Mit bestimmten Ständen meine ich Branches in git ab einem commit. Mit Bedienung meine ich z.B. Programm starten und sofort wieder beenden. Das heist aber nicht dass ich nur bisecten muss und ich hätte das Problem. Commit A ist noch symptomfrei, wenn ich dann nur eine Methode umbenenne und eine andere ungebraucht lösche "knallts". Oder wenn commit B geht, habe ich nur ein Dialogfenster vergrössert und schon "knallts". Mit FastMM FullDebugMode sieht der Callstack so aus: System._IntfClear(???) :004112a4 @IntfClear + $10 dxDockPanel.TdxDockPanel.Destroy Vcl.Controls.TWinControl.Destroy Vcl.Controls.TCustomControl.Destroy dxDockControl.TdxCustomDockControl.Destroy dxDockControl.TdxTabContainerDockSite.Destroy Vcl.Controls.TWinControl.Destroy Vcl.Controls.TCustomControl.Destroy dxDockControl.TdxCustomDockControl.Destroy dxDockControl.TdxDockSite.Destroy Vcl.Controls.TWinControl.Destroy Vcl.Forms.TScrollingWinControl.Destroy Vcl.Forms.TCustomForm.Destroy :00e20c62 TdxCustomRibbonForm.Destroy + $26 Fm_main.TVollMainForm.Destroy System.TObject.Free System.Classes.TComponent.DestroyComponents Vcl.Forms.DoneApplication System.SysUtils.DoExitProc System._Halt0 Ohne diese Option (aber mit EnableMemoryLeakReporting) so: System.TMonitor.Destroy System.TInstBucket.Finalize System.TInstHashMap.Finalize System.Finalization System.FinalizeUnits :004b6c86 InterceptFinalizeUnits + $5A Mein DevExpress ist drei Jahre alt. Dort habe ich nicht gefunden, dass da ein Bug offen wäre. Mit madExcept mit "instantly crash on ..." geht nicht wegen zu wenig Speicher. Mit madExcept und memory leak detection tritt das Problem nicht auf. Wie kann ich das Problem beheben? Wie finde ich das raus. Schreibt da irgendwas im Speicher falsch rum? Wird etwas doppelt freigegeben? Müsste dann aber doch FastMM mit FullDebugMode finden. Memory Leaks gibt es welche, aber die tun ja doch nicht weh solange man genug Speicher hat. :( Meine App ist leider auch nicht gerade klein (>500 Dateien mit 700k Zeilen) ![]() |
AW: Allgemeine Schutzverletzung bei Programmende
Das du es auf einen Commit einschränken kannst ist doch schon mal sehr gut. Mach doch jetzt einfach einen Diff zwischen dem Commit bei dem der Fehler noch nicht auftritt und dem, bei dem der Fehler gut simuliert werden kann. Dann solltest du doch recht schnell den Verursacher finden können.
EDIT: Ich glaube ich habe nicht gut genug gelesen. Aber vielleicht hilft es ja doch, einen Diff zu machen. Eventuell solltest du das gleiche was du oben beschreibst mal auf einem etwas älteren Stand auch testen (auf einem anderen Branch) und dich immer weiter in der Commit History vorarbeiten. Wenn du dann an einen Punkt kommst an dem es passiert, dann kannst du da ja wieder einen Diff machen. |
AW: Allgemeine Schutzverletzung bei Programmende
Ich vermute, der Fehler ist bereits vorher drin, schlägt aber wegen zufällig harmloser Speicherinhalte nicht zu.
|
AW: Allgemeine Schutzverletzung bei Programmende
Zitat:
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 04:43 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