Delphi 12.3 mal wieder verreckt

[himitsu]

So, nachdem Delphi schonwieder, mitten beim Schreiben einfach so verreckt ist.
(diesmal nur hängen geblieben, aber wortlos einfach verschwunden gab es auch schon öfters)

Außerdem war ich nachlässig, nachdem das mit dem Recovery in letzter Zeit gut funktionierte.
Beim Start einer neuen (nach Absturz) oder einer zweiten IDE-Instanz (um was anderes nachgucken zu können)
kam ja immer ein (so in etwa)
> Hab Recovery gefunden, soll ich laden?
:: nein
> OK, soll ich's dann Löschen?
:: nein

Nur diesmal .... Ich weiß jetzt nicht, ob die neue Instanz das gelöscht hat, oder ob es wirklich keine Recovery-Datei gab.



OK, nun bin ich diesmal dazu gekommen nachsehn zu wollen, was da eigentlich hängt.
Allgemein ist es so, bzw. es kommt mir so vor, als wenn beim Hängenbleiben zufällig fast immer ein IDE-Insight-Hint zu sehen ist.

Ich hab ja dieses schrottige Moddeling deaktiviert, also dachte ich es gibt kein .NET mehr,
aber wieso sehe ich da 4 oder 5 Threads, wie sie in der clr.dll (C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll) abhängen?
(bei ntdll.ZwRemoveIoCompletion oder ntdll.NtWaitForMultipleObjects)

Außerdem hängt irgendein Thread im Synchronize

Zitat:

:77d4905c ntdll.ZwWaitForSingleObject + 0xc
:77987c42 KERNELBASE.WaitForSingleObject + 0x12
rtl.System.SysUtils.WaitForSyncWaitObj(???,???)
rtl.System.SysUtils.WaitOrSignalObj(???,$FFFFFFFF, ???)
rtl.System.TMonitor.Wait($3BF26E8,4294967295)
rtl.System.TMonitor.Wait($3E2775E0,$2292730,429496 7295)
rtl.System.Classes.TThread.Synchronize($480AFDE8,F alse,False)
rtl.System.Classes.TThread.Synchronize(???,(System .Classes.TThread.CallOnTerminate,$FB8E180))
rtl.System.Classes.TThread.Synchronize((System.Cla sses.TThread.CallOnTerminate,$FB8E180))
rtl.System.Classes.TThread.DoTerminate
rtl.System.Classes.ThreadProc($FB8E180)
rtl.System.ThreadWrapper($3E1E7610)
:76275d49 kernel32.BaseThreadInitThunk + 0x19
:77d3d6db ntdll.RtlInitializeExceptionChain + 0x6b
:77d3d661 ; C:\Windows\System32\ntdll.dll

Von den Adressen im Stack oder den Parametern zeigt leider keine auf die Thread-Prozedur,
damit man rausbekommen könnte, welcher Thread das ist, bzw. was er machen wollte.

Emba ignoriert leider immernoch meinenm Request, endlich mal die Threadnamen "richtig" zu setzen.


Und nun der Hauptthread.
Der hat 'nen Deadlock im Delphi-Speichemanager,
während er grade einen Stacktrace auflösen wollte, oder so,
nachdem irgendein ein SetLength in der coreide abgeraucht ist.

Zitat:

:779922d7 KERNELBASE.SleepEx + 0x7
:7158a009 ; C:\Program Files (x86)\Embarcadero\Studio\23.0\bin\borlndmm.dll
:69464334 exceptiondiag290.@Jcldebug@TJclStackInfoList@$bctr $qqroipvot3t3 + 0xa8
:6946426d exceptiondiag290.@Jcldebug@TJclStackInfoList@$bctr $qqroipvot3 + 0x31
:6946792e ; c:\program files (x86)\embarcadero\Studio\23.0\bin\exceptiondiag290 .bpl
rtl.System.SysUtils.Exception.RaisingException(??? )
rtl.System.SysUtils.GetExceptionObject($133EF5C)
:69452b6e ; c:\program files (x86)\embarcadero\Studio\23.0\bin\exceptiondiag290 .bpl
:69452d56 ; c:\program files (x86)\embarcadero\Studio\23.0\bin\exceptiondiag290 .bpl
rtl.System._HandleAnyException
:6dde1339 @HandleAnyException + $35
:77d84214 ; C:\Windows\System32\ntdll.dll
:77d4b66f ntdll.KiUserExceptionDispatcher + 0xf
rtl.System._DynArraySetLength
:6dde6a8e @DynArraySetLength + $A
:6ed92b18 ; C:\Program Files (x86)\Embarcadero\Studio\23.0\bin\coreide290.bpl
:6ed88574 ; C:\Program Files (x86)\Embarcadero\Studio\23.0\bin\coreide290.bpl
:6ed88b7b coreide290.@Editorcontrol@TCustomEditControl@EdRef resh$qqro + 0x57
:6edab6e3 ; C:\Program Files (x86)\Embarcadero\Studio\23.0\bin\coreide290.bpl
:6edac28f coreide290.@Kbclient@TIDEKBDChildAPI@ProcessKeyStr oke$qqriiii + 0xa3
:6ed971d2 ; C:\Program Files (x86)\Embarcadero\Studio\23.0\bin\coreide290.bpl
:6ed86e5b coreide290.@Editorcontrol@TCustomEditControl@CNKey Down$qqrr22Winapi@Messages@TWMKey + 0x9f
vcl.Vcl.Controls.TWinControl.WndProc((256, 90, 1376257, 0, 90, 0, (), 1, 21, (), 0, 0, ()))
vcl.Vcl.Controls.TWinControl.MainWndProc(???)
rtl.System.Classes.StdWndProc(6033274,48384,90,137 6257)
:75d19a63 ; C:\Windows\System32\user32.dll
:75d07bdd ; C:\Windows\System32\user32.dll
:75d07680 ; C:\Windows\System32\user32.dll
:75d13ee9 ; C:\Windows\System32\user32.dll
:77d4b646 ntdll.KiUserCallbackDispatcher + 0x36
:75d20438 ; C:\Windows\System32\user32.dll
:75d073a6 user32.SendMessageW + 0x46
vcl.Vcl.Forms.TApplication.IsKeyMsg(???)

Hätte mir mehr gewünscht, dass sich besser rausstellt, was wo nun warum sich sperrt.


('nen 12.3 ohne Erweiterungen)

[haentschman]

Moin...

Zitat:

So, nachdem Delphi schonwieder, mitten beim Schreiben einfach so verreckt ist.

...habe ich täglich, wenn an einem Formular arbeite. Besonders öfter bei der Mehrfachauswahl der Controls! Knetfest! Taskmanger bei ca. 30%. Inzwischen speichere ich JEDEN Step vorher.

[himitsu]

Hab das Recovery schon auf eine Minute gestellt.
(ich muß mal schauen, ob ich Lust und Zeit finde ein "richtiges" Recovery einzubinden ... so, wie es inzwischen sogar Notepad und Paint können)

Beim FormDesigner muß man eh bissl aufpassen.
https://www.delphipraxis.net/217712-...-property.html
https://www.delphipraxis.net/217780-...ert-fokus.html

Beim Umschalten der Config (Windows <> Android)
muß erstmal der LSP abgeschossen werden, damit die ausgegrauten IFDEF passen

Muß auch ständig restartet werden, damit CodeCompletion und Strg+Linksklick wieder gehen.

Abgesehn, dass der Designer eh extrem langsam reagiert.
Die Projektverwaltung bei vielen Projekten sowieso schon ewig.
Und das neue cool-bunte lokale und überwachte Variablen ist noch viel langsamer geworden (vor allem bei größeren/vielen Daten)
und manchmal verrecken die Überwachten Ausdrücke und bleiben dann disabled, bis zum IDE-Neustart

Aber wenn es mitten beim Codeschreiben verreckt, ist schon am nervigsten. (da hilft dann nur Screenshot, weil Recovery garantiert noch nicht da)

[Kas Ob.]

Well, i only can say what comes to mind and from what see here, and while i don't have and didn't use anything after XE8, i saw lot of these from Delphi 2009, 2010 and XE8 (with few in between and before)

So,
As for the "some thread is hanging in the Synchronize", this is classic failure in clean up, the thread is blocking (hanging in this case) in DoTerminate, waiting for the main thread to release it, yet the release will never come.
With classic failure in clean up, i meant in this case the failure not in code but in the structure and logic, the failure to predict breaking point and allowing race condition, clean up was done in the code half assed, removed from part and left in other package/library... that thread was created at some point from the main, but a clean/refactor messed the structure and left it without connection to the main thread loop, in this case and because DoTerminate calling an assigned event OnTerminate, and this most likely belongs to an already unloaded package or again the main thread is lost for it, in other words WakeMainThread is not there, and it will be there waiting for specific signal that will never come,..
This happen when you build a library to be used with Windows Service or may be in Console application, where main thread has different main loop (or wait state) and it in theory should not fail, but when tangling so many of these then all what needed is one small exception throwing main thread waiting on already the waiting signal, and you left with freezing application.

to get better diagnose for this case, you need to track it and remove, but how ? you said you have no idea who started this one,
It is easier if you look at this in light form different angle, ( and that why i hate anonymous methods specially if they attached to threads), you have to monitor the creation of all threads and their calling stacks before reaching this point then find the caller/creator, use real debugger with trace like x64dbg https://x64dbg.com/ or any tracing/tracking/monitoring tool like ApiMonitor to track CreateThread and identify it by Handle, the tool should/must capture the stack (even Procoss Monitor from SysInternals can capture CreateThread with calling stack).


As for the main dish and you main question:

Zitat:

:77d4b66f ntdll.KiUserExceptionDispatcher + 0xf
rtl.System._DynArraySetLength
:6dde6a8e @DynArraySetLength + $A
:6ed92b18 ; C:\Program Files (x86)\Embarcadero\Studio\23.0\bin\coreide290.bpl
:6ed88574 ; C:\Program Files (x86)\Embarcadero\Studio\23.0\bin\coreide290.bpl
:6ed88b7b coreide290.@Editorcontrol@TCustomEditControl@EdRef resh$qqro + 0x57
:6edab6e3 ; C:\Program Files (x86)\Embarcadero\Studio\23.0\bin\coreide290.bpl
:6edac28f coreide290.@Kbclient@TIDEKBDChildAPI@ProcessKeyStr oke$qqriiii + 0xa3
:6ed971d2 ; C:\Program Files (x86)\Embarcadero\Studio\23.0\bin\coreide290.bpl
:6ed86e5b coreide290.@Editorcontrol@TCustomEditControl@CNKey Down$qqrr22Winapi@Messages@TWMKey + 0x9f

I don't know what is Editorcontrol is, i can remember if i saw it in my IDEs, and not sure if this is CustomEdit derived or TMemo or something else, but clearly it did capture the CNKeyDown message then reached ProcessKeyStroke which called EdRefresh and from there SetLength lead to an exception.

How to unpack this ? well, it is not easy at all because we are missing huge chunks from the big picture.
So thoughts here, and i am sorry they are less helpful but might give you some insights if you want to dig deeper into this
1) The most important and clearest thing is the many failures of the exception handling in the IDE which Embarcadero keep using and trusting of the blue, the Jcldebug , why ? who knows, there is way better two tools and could have helped filtering and fixing all this crab years ago, yet they keep implementing their own based on outdated codes, using MadExcept or EurekaLog could helped capture better call stacks and even stopping this from happening, enough ranting and lets back to the failures.
A) Some calls resolved and some is not, seen from coreide290, this is functionality failure and it is enough to be not used at all.
B) Failure to correctly handle HandleAnyException, which is ... well ... will come to this later because it is the crucial point in this case.
C) The consistent and known failure to display Exception Dialog when the main thread is f*****, see MadExcept and EurekaLog neatly build to separate these dialog from the main thread, the current exception handling in IDE is known and there for decades, on the contrary a simple not to re-raise and just not show a dialog in could solved/reduced the freezing or silent crashing, they could (well if they have spare time from adding huge features like ternary...) and just add a feature to generate a simple file exception logging instead of dialog and suppress the dialogs altogether, they themselves could have way better reports to fix the IDE.

2) We have EditCOntrol that capture and handle WM_KEY message, then it leads to refresh, between these two a focus lost or changed could caused havoc, specially events in VCL by default use Sender as generic, so a missed check to ensure the code is still executing on the same control could caused this, from what i understand the newer IDE can show multiple editor, and that if we talking about what you were doing when this went south, the key pressed was in the code editor ? or some of the newer search editor ? or something else
See, i write with many errors (typos) and go fix them, like the above, i wrote EditCOntrol instead of EditControl, and always (most of the time) go back and fix them, this caused by things, like what i doing while writing, like answering phone, or thinking of different part of the code while writing some elsewhere..or... doesn't matter it caused by fraction of second that i held my left Shift key down by my left pinky, problem with coordination may be, the thing is what you do when you hit a key with another key in some small time period a key that might switch focus ?! there is so many combination of shortcuts, and we as human might not notice how this happen, this can be a reason, but it is failure in the IDE none the less, only way harder to reproduce, the IDE and the editor and its memory manager should be under some stress while background thread doing something.

3) the unresolved calls from the same freaking IDE that shipped this exception handling is so annoying, that i can't believe the developers can find exceptions or even care to find them to begin with, how they should understand what it is going on, or they are super duper developers that don't make mistakes and don't miss anything... it is mind boggling.

4) The fact of a key press coming form Windows message leading to a refresh is hard for me to imagine, well i have vivid imagination, and yes i can imagine many scenarios for going from key press to directly call a procedure/function called EdRefresh, but is this logically correct to do, Refresh what ? a visual content refresh usually you call that with a message, right ? not direct call, you are short circuiting here, are you refreshing the internal content without updating ? then yes it is possible and should have better name, yet this should very easy to protect against and again mind boggling to lead to a an exception in adjusting an array length, right ? yes i am right here!.

5) The failure to resolve stack, is ... (SNIPPED more ranting) .. , see ,if we only knew what that address 6ed92b18 in coreide290.bpl resolve to and the line, it will be huge difference in understanding the bug and solve it, once and for all, is it in the compiler added magic ? is it in finally..end ? is it in the terminating and cleaning up of that procedure.. , each one will point to a direction, but in any direction you will be able to solve this, this bug should be as easy to fix as it get, like never easier, but the lack of the stack of the last two calls before SetLegnth makes it harder even for the developer themselves who can simply check in debugged IDE with sources and find the issue.

6) Back the crucial moment in this case, HandleAnyException this triggered because the code either :
A) doesn't have one try..except between WM_KEY to that EdRefrsh, leading to escaping/running exception, handled centrally and waiting on already waiting main thread.
B) handled, and done badly with very frustrating design i saw so many developer keep doing it, which is capture an exception then re-raise it, to all i say, good people stop doing that, it might work now and when you thought about it, but the risk of failure in future is so high that you are rigging a bomb waiting one refactor or reuse of the code/unit.
So this freeze you seeing is very simple to solve by simply try..except and .. that is it, just don't re-raise the thingy.
In case you want to handle it right then generate/output some log before showing a dialog, how hard it is to do that.

7) The fact that the IDE freezes with SleepEx coming form borlndmm.dll (the memory manager) is so strange, so, what memory manager is used ? and how much it is out dated ? are the questions here.

Sorry for the long post, and the ranting, i have guests and writing this post and received 4 phone calls, two of them caused too much of brain capacity and they have nothing to do with digital world but with the real life and why there will not be water for 10 hours, but .. anyway i will not suggest to you to stop researching or digging into the IDE, on the contrary i love investigative work, they do widen one mental capacity and teach from others mistakes, so if you want to continue then use Ghidra or IDA to try and figure these unresolved addresses, yet even that then ruined it by not using their own TDInfo and switching to different debug information and no one outside Delphi world can handle, so .. you can put a parser for its debug information using JCL (assuming they are still using the same one and not modified version)

Hope you find that helpful, and good luck !

[himitsu]

Delphi nutzt für Named-Threads eine Exception und nichtmal das Programm selbst merkt sich den Namen.
Reagiert niemand auf diese Exception und speichert sich das, oder hängt man sich erst später dran, ist der Name verloren.
Windows bietet seit sehr vielen Jahren eine API dafür, worüber man den gesetzten Namen später und auch von extern abfragen kann.

Nja, ich Debugge die IDE auch nicht permanent (wäre auch zu nervig, Aufgrund der vielen unnötigen Exceptions)
und hänge mich eben erst dran, nachdem es geknallt hat.

Das hängende Synchronize kann auch ein Folgefehler sein, weil ja der Mainthread nicht mehr reagiert.
Dennoch kann es auch sein, dass der Mainthread auf diesen Thread wartet und jener gleichzeitig auf den Mainthread.

Es war mal möglich CriticalSections zu loggen, bzw. sie loggen sich selbst,
aber seit Embarcadero immer mehr auf TMonitor setzt (das eine TMonitor, nicht das Andere ), ist es damit leider vorbei.
Gerade hier hätte die Sperre im Speichermanager mit CriticalSections die Möglichkeit geboten zu sehen wer wann wo wartet und wer das wann und wo gesperrt hat, aber es sind nunmal keine CS.

[Kas Ob.]

I still can't understand why there is SleepEx in borlandmm, what version are they using.

My XE8 doesn't have SleepEx, also looking at FastMM4 it has Sleep but not SleepEx, using SleepEx indicate the intention to wait on signal to wake, also FastMM5 doens't have either, simple and doesn't wait with Sleep,

So, does replacing that borlandmm with another one change behavior ?

Try to a replacement and see, at least it would eliminate the cause from memory manager,
https://github.com/pleriche/FastMM4
https://github.com/pleriche/FastMM5


One idea i can think of, they used modified MM (that include SleepEx) is to integrate some part of the IDE/Compiler which compiled with different compiler/language, and in case different MM used then will revert to some layer to use, who knows ?!
Another idea, their MM is broken and buggy, and they know it, so they introduced SleepEx instead of different spinning/locking mechanism to solve an issue, in an attempt to unlock it, again who knows ?!

[himitsu]

Ich glaub das ist eine sehr alte angepasste Delphi-Version des FastMM.