Bug 211130 - Multithreaded application deadlock due to OpenMotif
Multithreaded application deadlock due to OpenMotif
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: openmotif (Show other bugs)
4.2
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Thomas Woerner
:
Depends On:
Blocks: 234251
  Show dependency treegraph
 
Reported: 2006-10-17 11:40 EDT by Andy Baker
Modified: 2010-10-22 02:31 EDT (History)
1 user (show)

See Also:
Fixed In Version: RHBA-2008-0215
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-04-09 11:51:38 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Andy Baker 2006-10-17 11:40:11 EDT
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.
Comment 4 RHEL Product and Program Management 2008-02-01 14:11:52 EST
This request was evaluated by Red Hat Product Management for
inclusion, but this component is not scheduled to be updated in
the current Red Hat Enterprise Linux release. If you would like
this request to be reviewed for the next minor release, ask your
support representative to set the next rhel-x.y flag to "?".
Comment 9 errata-xmlrpc 2008-04-09 11:51:38 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2008-0215.html

Note You need to log in before you can comment on or make changes to this bug.