I had occasion to run across an old bug (reported in 2013) in the ABC library which hasn’t been fixed yet, but which can be fixed by users.
I’ve posted the details here, and also in the Clarion10 newsgroup.
Synopsis:
The use of ASSERT’s in procedures with a CRITICALSECTION can lead to a race condition, which in turn causes the RTL to hang.
Conditions:
The problem only occurs when the program is in Debugmode.
The problem probably only occurs if ASSERTHOOK has been used, but I cannot confirm that for sure.
Background:
From the Help, Synchronization Objects topic
“Due to the fact that Windows uses procedure-modal methods when dealing with MDI based applications (a program with an APPLICATION window) you must not have any user input when you have control of a synchronization object with an MDI based application. This is likely to lead to your application locking up … If you must have user input, then you must release control of the synchronization object while waiting for user input.”
An ASSERT statement is clearly user input. Hence an ASSERT in the CriticalProcedure would violate the terms of the documentation.
The more problematic problem is if ASSERTHOOK is used - then an ASSERT may trigger another CriticalProcedure - resulting in a deadlock.
For example:
AssertHook to a normal Clarion window. This window makes use of the INIMGR class. That class in turn makes use of CriticalProcedures.
So, some ASSERT somewhere fires, this triggers the IniMgr, which requires the CriticalProcedure. Hence Deadlock.
I have identified 3 ABC files which contain ASSERT’s inside procedures that also have a CriticalProcedure in them.
ABERROR.CLW
ABFILE.CLW
ABUTIL.CLW
Note that I do not recommend commenting out the critical procedure, as these are necessary for normal program usage.
I would recommend commenting out the ASSERT’s completely - only in procedures that have a CriticalProcedure declared - especially if you are having runtime lockups when compiled in debug mode.