Bug 438910

Summary: sr #1797542 - [motifzone 1400 ] openmotif/ BadFont on multiple display application .
Product: Red Hat Enterprise Linux 5 Reporter: ritz <rkhadgar>
Component: openmotifAssignee: Thomas Woerner <twoerner>
Status: CLOSED WONTFIX QA Contact:
Severity: medium Docs Contact:
Priority: high    
Version: 5.1CC: dmair, mnowak, pknirsch, syeghiay, tao
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-10-15 23:00:49 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
patch
none
test case none

Description ritz 2008-03-25 21:45:50 UTC
Description of problem:
A BadFont X error is produced the second time a widget hierarchy is created and
displayed.

Version-Release number of selected component (if applicable):
openmotif-2.3.0-3.el5

How reproducible:
frequent

Steps to Reproduce:
Customer cannot provide a reproducer. The original program is a framework, and
it turned out to be easier to debug and fix in that context than create a
standalone example.  I can describe essentially what it did, though:

Repeatedly:
 * Open a display
 * Create an app shell on it
 * Create a scrolled window widget in that
 * Create a form widget in that
 * Create a label in that
 * Realize everything
 * Unrealize everything
 * Close the display and start over

I'm not an X11/Xm programmer so can't say exactly how to do this.  Examining the
code and seeing that using the memory address of a structure as a hash index
past the life of the structure seemed clear enough as a problem.  The ResConvert
stuff caches Display-specific things based on the address of the Display
structure; if that same address subsequently holds a structure for a Display on
a different server, the cache is wrong.

The real application frequently destroys and recreates widget hierarchies on
different displays, so this and bug #1388 which also used a structure address as
a key are very sensitive to the behavior of the memory allocator.  RHEL5 in
particular causes problems that are not seen in earlier releases.

Actual results:
BadFont on multiple display application

Expected results:
Motif application should not crash

Additional info:

patch from customer attached.

Upstream bug
http://bugs.mot ifzone.net/long_list.cgi?buglist=1400


 problem :

ResConvert.c in the Motif library maintains a DefaultSystemFontList in a
function-static variable.  This contains a mapping from Display memory
addresses to XmFontList structures.  One of these fonts is loaded by Motif
itself.  When the parent Display is closed (via XCloseDisplay), all the
fonts associated with the X11 display are unloaded, but this mapping is
never updated to dissociate the display address from the font references.

If a new display is subsequently opened, and the address of its Display
structure happens to be the same as the old one, the DefaultSystemFontList
code will happily return an XmFontList that was initialized with references
to fonts that have subsequently been unloaded.  X11 reloads its fonts, but
because Motif has not noticed that the display was closed it does not reload
its own font.  The font Motif loads often has the same name ("fixed") as a
font X11 loads, and it may be that the X11 reload places it at the same
address as it had been.  If so, and the Motif reference to the font is not
corrupted, everything happens to work.  If anything at all goes wrong, Motif
will reference memory that does not contain a valid font reference, and the
display server will produce a BadFont error.

The solution:

VendorS.c in the Motif library includes a DisplayClosedCallback that is
called when the Motif display[*] is closed.  This has been modified to
ultimately call a new function XmeReleaseDisplayDefaults in ResConvert.c
which in turns dissociates the display address with the font list and
reclaims the list and its contained entries.

Commentary:

First, DisplayClosedCallback is invoked when the XmDisplay is closed.  The
XmDisplay is an XtAppShell that is maintained as long as some Motif widget
is associated with the Display.  It is not the same as the underlying X11
display.  The DisplayClosedCallback is invoked whenever the last Motif
widget is removed from the display, even if the X11 Display remains open.
As the display remains open, the underlying fonts are not unloaded, and the
references are still valid, and in fact may be in use by other (non-Motif)
widgets on the display.  This should be OK since, even though we reclaim the
font list memory, we know no Motif references to the fonts exist, and
non-Motif references should have their own, unrelated handles.  So it is not
necessary to hook into the XtCloseDisplay callback infrastructure.

Second, the loop to reclaim the font space is probably overly protective,
but it works, and in the absence of documentation of exactly how the invoked
functions behave, or a pre-existing example of the same action, I'm not
going to mess with it.

Comment 1 ritz 2008-03-25 21:47:27 UTC
Created attachment 299075 [details]
patch

Comment 2 Phil Knirsch 2008-05-05 12:01:16 UTC
Proposing for RHEL-5.3, waiting with final ACK on developer review.

Read ya, Phil 


Comment 3 RHEL Program Management 2008-06-02 20:12:26 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.

Comment 4 Phil Knirsch 2008-06-13 13:42:25 UTC
This bug needs a review from the component owner before granting Devel ACK.

Thanks,

Read ya, Phil


Comment 5 Thomas Woerner 2008-07-02 13:59:39 UTC
Please use XtDestroyWidget on the topLevelShellWidget to destroy it after it is
unrealised. This should fix your problem.

Comment 7 Thomas Woerner 2008-07-04 15:20:55 UTC
Created attachment 311045 [details]
test case

Comment 20 RHEL Program Management 2009-03-26 16:47:14 UTC
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 23 RHEL Program Management 2010-08-09 18:11:39 UTC
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.

Comment 25 RHEL Program Management 2011-01-11 20:00:37 UTC
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.

Comment 26 RHEL Program Management 2011-01-11 23:16:44 UTC
This request was erroneously denied for the current release of
Red Hat Enterprise Linux.  The error has been fixed and this
request has been re-proposed for the current release.

Comment 27 RHEL Program Management 2011-05-31 13:11:12 UTC
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.