Freeze check: Duplicates not allowed

delphi package - automated exception handling
Post Reply
mroessen
Posts: 1
Joined: Wed Jun 24, 2020 4:00 pm

Freeze check: Duplicates not allowed

Post by mroessen »

Hi Madshi,

This week we enabled the freeze check for a number of our customers, to hunt down an "application not responding" error.
Since then we occasionally receive bug reports with exception class EListError and the message "Duplicates not allowed".

This is the bug report with part of the call stack:

compiled with : Delphi 11
madExcept version : 5.1.2
callstack crc : $60f8de9c, $df91565e, $c1e01723
exception number : 1
exception class : EListError
exception message : Duplicates not allowed.

thread $5a48 (TThreadPool.TThreadPoolMonitor):
008082fe +46 xxxxxxxx.exe System.Threading {System.Generics.Collections}TDictionary<System.Threading.TThreadPool,System.NativeUInt>.Add
00800dc2 +b2 xxxxxxxx.exe System.Threading TThreadPool.TThreadPoolMonitor.Execute
004c0e0f +2b xxxxxxxx.exe madExcept HookedTThreadExecute
004c0e7a +96 xxxxxxxx.exe madExcept HookedTThreadExecute
0055cb69 +49 xxxxxxxx.exe System.Classes ThreadProc
0055cbcc +ac xxxxxxxx.exe System.Classes ThreadProc
0040b8a8 +28 xxxxxxxx.exe System 21 +0 ThreadWrapper
004c0cf5 +0d xxxxxxxx.exe madExcept CallThreadProcSafe
004c0d5a +32 xxxxxxxx.exe madExcept ThreadExceptFrame
004c0dd0 +a8 xxxxxxxx.exe madExcept ThreadExceptFrame
75c46a12 +22 KERNEL32.DLL BaseThreadInitThunk
>> created by main thread ($2b2c) at:
0055cc30 +18 xxxxxxxx.exe System.Classes TThread.Create

main thread ($2b2c):

Can you confirm that this is a bug in MadExcept?

Best regards,

Marco
madshi
Site Admin
Posts: 10527
Joined: Sun Mar 21, 2004 5:25 pm

Re: Freeze check: Duplicates not allowed

Post by madshi »

Hi Marco,

why would you think that this is a bug in madExcept? The bug report does not contain any indications of that.

That said, it's weird that activating the freeze check would somehow produce these crashes. I'm not sure why that would happen. Are you sure that you didn't do other changes in your code which could cause this new crash?

FYI, the freeze check is very simple: A secondary thread is created which simply regularly sends messages to the main thread. And the secondary thread then checks if the main thread replies to those messages within a reasonable period of time. That's all. I don't see why this approach would cause additional crashes. And nobody else has reported any similar issues in the last couple of years. So I wonder if it's maybe just a coincidence that activating the freeze check seems to have created these new crashes?

An alternative explanation could be that the freeze check messages might slightly change the timing in your application, in such a way that things may now happen in a slightly different order than before. This could bring some hidden bug in your code to light which was hidden before.

These are just my thoughts. I don't have enough information to draw any firm conclusions. But from the information I have, I would guess that it's probably not a bug in madExcept.
Post Reply