Mad Except causing freeze?

delphi package - automated exception handling
Post Reply
Inca
Posts: 4
Joined: Tue May 13, 2014 2:29 am

Mad Except causing freeze?

Post by Inca »

Recently I've been getting reports of freezing with the following data:

Code: Select all

compiled with      : Delphi 10.2 Tokyo
madExcept version  : 4.0.19
callstack crc      : $e50ca668, $5100389c, $869b4074
exception number   : 8
exception message  : The application seems to be frozen.

main thread ($f0):
74d02cc1 +b1 KERNELBASE.dll                        WaitForSingleObjectEx
74d02bfd +0d KERNELBASE.dll                        WaitForSingleObject
0045a516 +02 Application.exe System.SysUtils       WaitForSyncWaitObj
0045a65f +1f Application.exe System.SysUtils       WaitOrSignalObj
0040a320 +fc Application.exe System          34 +0 TMonitor.Enter
00545c2e +1a Application.exe System.Classes        {System.Generics.Collections}TThreadList<System.Classes.TPropFixup>.LockList
00545a60 +14 Application.exe System.Classes        {System.Generics.Collections}TThreadList<System.Classes.TPropFixup>.Destroy
004097a8 +08 Application.exe System          34 +0 TObject.Free
0053c039 +4d Application.exe System.Classes        Finalization
0040b01e +3e Application.exe System          34 +0 FinalizeUnits
004aa590 +54 Application.exe madExcept             InterceptFinalizeUnits
004aa598 +00 Application.exe madExcept             InterceptHalt0FinalizeUnits
0040b428 +a8 Application.exe System          34 +0 @Halt0
74f77c02 +22 KERNEL32.DLL                          BaseThreadInitThunk
Does this mean madExcept is causing the freezes? How can I prevent it?
madshi
Site Admin
Posts: 10753
Joined: Sun Mar 21, 2004 5:25 pm

Re: Mad Except causing freeze?

Post by madshi »

No, it's not madExcept that's causing the freeze here. madExcept is listed in the callstack because madExcept has to hook into some parts of the RTL to get access to some information, or to be able to report freezes and shutdown crashes to you properly.

The freeze seems to occur when some object is freed in some unit's finalization section, which seems to result in TMonitor.Enter being called, which again seems to call WaitForSingleObject somehow, which causes the deadlock. Unfortunately, callstack tracing is not scientifically perfect, it involves some guessing by madExcept. So it's possible that TMonitor.Enter is not actually called at all, but looking at the callstack, it would make sense if it were. Unfortunately we can't really see which unit is calling TMonitor.Enter, however.
Post Reply