Using Win32 critical section API in a heaviliy multithreaded environment can cause access violations

Issue #179 resolved
Daniel Bärmann
created an issue

I'm working on a project that spawns multiple threads and accesses shared resources using critical sections through Win32 API calls of InitializeCriticalSection/EnterCriticalSection etc. This occurs mainly through thirdparty components using VCL classes like TFont and its OwnerLock-Property.

I can reproduce this using the attached sample under MacOS Mojave 10.14.3. Running the sample results in an access violation after a short time with the following call stack:

System._DbgExcNotify(0,$5271DA0,$189E86 {'EAccessViolation'},$33FA3,nil)
System.NotifyReRaise
:0001aa3b NotifyReRaise + $13
System.Internal.ExcUtils.RaiseSignalException(???,???,2962209944)
:00033fa3 RaiseSignalException + $37
:002989f3 ; libcrossvcl32
:003b29f4 ; libcrossvcl32
:0041b7e6 ; libcrossvcl32
TestCs.TestCs$ActRec.$0$Body(110)
System.Threading.TParallel.ForWorker$ActRec.$0$Body
System.Threading.TTask.ExecuteReplicates$ActRec.$0$Body
System.Threading.TTask.Execute
System.Threading.TTask.InternalExecute($524E280)
System.Threading.TTask.InternalWork(???)
:0013e1db TTask.InternalWork + $83
System.Threading.TThreadPool.TQueueWorkerThread.ExecuteWorkItem(TParallel.TReplicaTask($524E2C4) as TThreadPool.IThreadPoolWorkItem)
System.Threading.TThreadPool.TQueueWorkerThread.Execute
System.Classes.ThreadProc($525C2A0)
System.ThreadWrapper($523F550)
:a7c275e8 ; libsystem_pthread
:a7c2a7d7 ; libsystem_pthread
:a7c267a6 ; libsystem_pthread

Comments (1)

  1. Log in to comment