Bug 211130

From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)

Description of problem:
Unmatched calls to XtAppLock() and XtAppUnlock() in function XmeGetDefaultRenderTable() in openmotif/lib/Xm/ResConvert.c can cause deadlock in applications that make X/Motif calls from multiple threads prior to the X event loop. 

Version-Release number of selected component (if applicable):
openmotif-2.2.3-9.RHEL4.1

How reproducible:
Always


Steps to Reproduce:
1. Invoke 'normal' X/Motif initialisation functions in one thread and repeatedly invoke XtAppLock() and XtAppUnlock in another.
2. Don't invoke the X event loop (e.g. don't call XtAppMainLoop) in either thread.
3. 

Actual Results:
The thread that calls XmeGetDefaultRenderTable() first (e.g. via XtVaAppInitialise) obtains the application lock and never relinquishes it. The other thread is thus unable to obtain the application lock. In our application this effect causes our software to 'hang'.

Expected Results:
Matched calls to XtAppLock() and XtAppUnlock() would allow other threads access to the application lock and hence could make an X/Motif function call without blocking indefinitely.

Additional info:
This problem has been identified in OpenMotif bug #1239 and a fix incorporated at revision 1.5 of ResConvert.c.

I suspect that calls to YieldAppLock() and RestoreAppLock() from the event loop (Xt Intrinsics xc/lib/Xt/Threads.c) allow many applications to work despite this bug - the proviso being that the thread that executes the event loop is not blocked indefinitely prior to the event loop being started.