|
IDE debuggen und __Recovery?
Liste der Anhänge anzeigen (Anzahl: 3)
Sacht mal, kann es sein, dass man keine Prozesse debuggen kann, die zu viel RAM belegen?
Grade eben hing D11 beim Schließen ... auf X geklickt, wollte auf den "willst'e speichern?"-Dialog klicken, aber der kam nie. 1,5 2,5 GB RAM und immernoch steigend, alle 4 Kerne gleichmäßig zu 40-50% ausgelastet und laut Ressourcenmonitor keine Dateizugriffe IDE nochmal gestartet und wollte schauen, was Delphi macht, also Start > Verbinden > BDS.exe Weil es nicht ging, nochmal XE gestartet und dort das Selbe Zitat:
Laut ProcessExplorer: * 50% aller Threads hingen in einem Assert (siehe Anhang) ... nur er erste Thread bewegte sich * und im Haupthtread 6 Mal verschachtelt abwechselnd der Exceptiondialog von Delphi und MadExcept Ein Speicherabbild hatte ich diesmal auch erstellt ... falls Lust Nach gefühlt einer 1/4 Stunde im Taskmanager gesehn, dass es inzwischen einen Fehlerdialog gibt, der war sichtbar und meinte nicht genug Speicher, aber war nicht bedienbar/wegklickbar und Delphi hing weiterhin mit guter CPU-Last. > Lösung Taskmanager > Kill Ach ja, und vom Taskmanager heute auch mal was Neues gesehn, nach längerer Zeit -> Effizienzmodus (siehe Anhang) So, dann geschaut, was das Minütliche __Recovery sagt * diesmal war wirklich eine Datei gespeichert und eine INI * Delphi gestartet * Projektgruppe wieder geladen * die Unit wurde auch geladen und jetzt SOLLTE doch eine Meldung ala "hab Änderungen gefunden, soll ich sie laden?", ABER NEIN, kam nicht und die Änderungen waren auch nicht geladen * Unit geschlossen * wieder geöffnet * und jetzt wurde das __Recovery bösartig gelöscht (zum Glück hab ich mir vorher eine Kopie gemacht) Funktioniert der DRECK eigentlich bei irgendwem zuverlässig? |
AW: IDE debuggen und __Recovery?
Das ist weniger das Problem. Das Problem ist, dass das zu debuggende Problem bereits an die Grenzen des Speichers gestoßen ist. Durch die Fragmentierung ist ja schon vor den 3 GB Schluss. Deshalb kommt man NACH einem solchen Problem kaum noch in einen solchen Prozess hinein. So etwas kann man nur sinnvoll debuggen, wenn man sich vorher einklinkt.
Das passiert übrigens auch mit anderen Debuggern wie WinDbg. Da geht es in solchen Fällen auch kaum weiter. Den wollte ich nämlich bei einem ähnlichen Problem als Alternative verwenden. |
AW: IDE debuggen und __Recovery?
Meistens hoffe ich, dass es gut geht ... will ja dann erst nachsehn, nachdem es geknallt hat. :wall:
Jetzt wo du's sagst ... an meinen Eigenen hatte ich jetzt nicht gedacht. :freak:  https://www.delphipraxis.net/215343-...ltepunkte.html(aber Stacktrace wäre da eh noch nicht vorhanden) |
AW: IDE debuggen und __Recovery?
@himitsu , in your second screenshot your focused thread is not the main one, yet it does show what may be the culprit,
LdrInitializeThunk is the kernel function responsible for loading dynamic libraries, most likely and like when the an exe is loading and the OS is preparing and loading its dependencies from its import table, some DLL loaded by LoadLibrary might pass without this, yet this one might be called for the import for that DLL, aka not directly. On side note : i hate delayed loading import, it can lead to unpredictable cases. Is there any thing useful with the main thread ? , as it is visible in the screen shot, which in a loop too, but with less intensive CPU usage at ~500 million cycle per second. So your main thread might show the dead loop or at least more information. extra resource: https://stackoverflow.com/questions/...45012_43851743, yet your case might be in loading and failed memory allocation, yet the main thread request loading again... |
AW: IDE debuggen und __Recovery?
OK, welcher Thread es war, war prinzipiell erstmal egal ... wollte nur wissen was da so viel CPU verbraucht
und ob ich da irgendeinen Anhaltspunkt finde, das Problem zukünftig zu beseitigen. (z.B. wenn es etwas von unserem eigenem DesignTimeCode gewesen wäre) Ab und an sah dieser Thread z.B. so aus Zitat:
|
AW: IDE debuggen und __Recovery?
Zitat:
https://embt.atlassian.net/servicede...tal/1/RSS-1224But it could be that simple if we could see it directly. :stupid: |
AW: IDE debuggen und __Recovery?
Well, all what i see from this stack is
1) MadExcept may be unable handle exception (or to be more accurate,) can't stack tracing under low memory, unless it is failing to handle its own exceptions. 2) There is recursive calls and this is more dangerous then (1) 3) The stack is cut short, this is not all !, and you need more powerful tool to capture the stack on such thread, for that use WinDbg. |
| Alle Zeitangaben in WEZ +1. Es ist jetzt 00:11 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