Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

For bugs related to Red Hat Enterprise Linux 3 product line. The current stable release is 3.9. For Red Hat Enterprise Linux 6 and above, please visit Red Hat JIRA https://issues.redhat.com/secure/CreateIssue!default.jspa?pid=12332745 to report new issues.

Bug 172090 (IT_81559)

Summary:

Memory leak in the vesa driver

Product:

Red Hat Enterprise Linux 3

Reporter:

Bastien Nocera <bnocera>

Component:

XFree86

Assignee:

X/OpenGL Maintenance List <xgl-maint>

Status:

CLOSED ERRATA

QA Contact:

David Lawrence <dkl>

Severity:

medium

Docs Contact:

Priority:

medium

Version:

3.0

CC:

tao

Target Milestone:

---

Target Release:

---

Hardware:

All

OS:

Linux

Whiteboard:

Fixed In Version:

RHBA-2006-0410

Doc Type:

Bug Fix

Doc Text:

Story Points:

---

Clone Of:

Environment:

Last Closed:

2006-07-20 15:24:19 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:

Bug Depends On:

Bug Blocks:

181405

Attachments:

Description	Flags
VESACloseScreen.patch	none

Description Bastien Nocera 2005-10-31 10:46:43 UTC

The current RHEL3 Xfree86 will leak memory for each new client connecting, and
disconnecting from the X server.

Upstream patch available at:
http://cvsweb.xfree86.org/cvsweb/xc/programs/Xserver/hw/xfree86/drivers/vesa/vesa.c.diff?r1=1.45&r2=1.46

Steps to Reproduce:
while : ; do xlogo & sleep 3 ; kill -9 `ps aux | grep xlogo | awk '{print $2}'`
; done
while : ; do ps aux | grep "X :0" | grep -v grep ; sleep 5 ;done

Actual Results:

# while : ; do ps aux | grep "X :0" | grep -v grep ; sleep 5 ;done
root  28283  1.6  0.9 35972 9732 ?   S 11:26 0:02 /usr/X11R6/bin/X :0
root  28283  1.6  0.9 35972 9732 ?   S 11:26 0:02 /usr/X11R6/bin/X :0
root  28283  1.5  1.2 38772 12532 ?  S 11:26 0:02 /usr/X11R6/bin/X :0 <-
starting xterm
root  28283  1.5  1.2 38772 12532 ?  S 11:26 0:02 /usr/X11R6/bin/X :0
root  28283  1.5  1.2 38772 12532 ?  S 11:26 0:02 /usr/X11R6/bin/X :0
root  28283  1.5  0.9 36612 9736 ?   S 11:26 0:03 /usr/X11R6/bin/X :0 <- exiting
xterm

Expected Results:

# while : ; do ps aux | grep "X :0" | grep -v grep ; sleep 5 ;done
root  28283  1.6  0.9 35972 9732 ?   S 11:26 0:02 /usr/X11R6/bin/X :0
root  28283  1.6  0.9 35972 9732 ?   S 11:26 0:02 /usr/X11R6/bin/X :0
root  28283  1.5  1.2 38772 12532 ?  S 11:26 0:02 /usr/X11R6/bin/X :0 <-
starting xterm
root  28283  1.5  1.2 38772 12532 ?  S 11:26 0:02 /usr/X11R6/bin/X :0
root  28283  1.5  1.2 38772 12532 ?  S 11:26 0:02 /usr/X11R6/bin/X :0
root  28283  1.5  0.9 36612 9732 ?   S 11:26 0:03 /usr/X11R6/bin/X :0 <- exiting
xterm

Comment 5 Mike A. Harris 2006-03-28 14:48:38 UTC

U8 review ...  see bug #172091 which is identical issue for RHEL4 for
status.

Withholding devel ACK for time being.

Comment 9 Mike A. Harris 2006-04-25 10:51:34 UTC

Patch applied to build 4.3.0-102.EL.  Will update when packages are built.

Comment 10 Mike A. Harris 2006-04-25 13:43:06 UTC

XFree86-4.3.0-102.EL is now available for download via ftp
at the following URL:  ftp://people.redhat.com/mharris/testing/3.0E

After upgrading all of the packages, please test them to see if the problem
reported has now been resolved and not any changes (good/bad).

Comment 12 Mike A. Harris 2006-05-02 10:54:39 UTC

Are you sure this isn't an FC-5 system?  mkfontdir/mkfontscale are located
in /usr/bin only on FC-5 with modular X.  I have reviewed the RHEL-3 packages
I've provided at the above URL (the 103.EL packages), and they invoke
the proper command:

[mharris@people i386]$ rpm -qp --scripts
XFree86-ISO8859-14-100dpi-fonts-4.3.0-103.EL.i386.rpm
postinstall scriptlet (through /bin/sh):
{
    umask 133;/usr/X11R6/bin/mkfontdir /usr/X11R6/lib/X11/fonts/100dpi
#    umask 133;which fc-cache &> /dev/null && fc-cache
/usr/X11R6/lib/X11/fonts/100dpi
    /usr/sbin/chkfontpath -q -a /usr/X11R6/lib/X11/fonts/100dpi:unscaled
} &> /dev/null || :


[mharris@people i386]$ rpm -qp --scripts XFree86-syriac-fonts-4.3.0-103.EL.i386.rpm
postinstall scriptlet (through /bin/sh):
{
  FONTDIR=/usr/X11R6/lib/X11/fonts/OTF
  umask 133;/usr/X11R6/bin/mkfontscale $FONTDIR
  umask 133;/usr/X11R6/bin/mkfontdir $FONTDIR
  umask 133;which fc-cache &> /dev/null && fc-cache $FONTDIR
  /usr/sbin/chkfontpath -q -a $FONTDIR
} &> /dev/null || :
postuninstall scriptlet (through /bin/sh):
{
  FONTDIR=/usr/X11R6/lib/X11/fonts/OTF
  if [ "$1" = "0" ]; then
    umask 133;/usr/X11R6/bin/mkfontscale $FONTDIR
    umask 133;/usr/X11R6/bin/mkfontdir $FONTDIR
    umask 133;which fc-cache &> /dev/null && fc-cache $FONTDIR
  fi
} &> /dev/null || :


etc.

If this really is a RHEL-3 system, has it perhaps had FC-5 packages
installed on it?  I have reviewed the XFree86.spec file in detail
for the 103.EL build also, and all instances of mkfontdir/mkfontscale
appear to be correct.

I did a quick check of the 102.EL build as well and it appears to be fine
also.  Please provide the output from this failed system for the following
commands:

rpm -q redhat-release
rpm -qa |sort > rpm.log

I'm unable to reproduce this problem, and can't see how it could happen.

Comment 14 Mike A. Harris 2006-05-02 11:30:12 UTC

I was able to reproduce the leak now with the vesa driver as reported,
using an X server started without any clients, and performing
the test indicated in the first comment via remote shell.

A second attempt on a different machine has shown a rather dramatic
memory leak from this.

With the patch applied however, the memory leak has completely gone,
and the server uses consistent memory usage with the provided test case.


[root@localhost ~]# while : ; do ps aux | grep "X :0" | grep -v grep ; sleep 1 ;done
root      4980 28.0  1.3 14596 7200 ?        R    07:33   0:13 X :0
root      4980 28.0  1.3 14596 7200 ?        S    07:33   0:14 X :0
root      4980 27.5  2.1 14596 11040 ?       S    07:33   0:14 X :0
root      4980 28.5  1.3 14596 7200 ?        S    07:33   0:14 X :0
root      4980 27.9  1.3 14596 7200 ?        S    07:33   0:14 X :0
root      4980 27.5  2.1 14596 11040 ?       S    07:33   0:14 X :0
root      4980 28.4  1.3 14596 7200 ?        S    07:33   0:15 X :0
root      4980 27.9  1.3 14596 7200 ?        S    07:33   0:15 X :0
root      4980 27.5  2.1 14596 11040 ?       S    07:33   0:15 X :0
root      4980 28.3  1.3 14596 7200 ?        S    07:33   0:16 X :0
root      4980 27.4  1.3 14596 7200 ?        S    07:33   0:16 X :0
root      4980 27.0  2.1 14596 11044 ?       S    07:33   0:16 X :0
root      4980 27.8  1.3 14596 7204 ?        S    07:33   0:17 X :0
root      4980 27.4  1.3 14596 7204 ?        S    07:33   0:17 X :0
root      4980 27.0  2.1 14596 11044 ?       S    07:33   0:17 X :0
root      4980 27.8  1.3 14596 7204 ?        S    07:33   0:18 X :0
root      4980 27.3  1.3 14596 7204 ?        S    07:33   0:18 X :0
root      4980 27.0  2.1 14596 11044 ?       S    07:33   0:18 X :0
root      4980 27.7  1.3 14596 7204 ?        S    07:33   0:18 X :0
root      4980 27.3  1.3 14596 7204 ?        S    07:33   0:18 X :0
root      4980 27.0  2.1 14596 11044 ?       S    07:33   0:18 X :0
root      4980 27.7  1.3 14596 7204 ?        S    07:33   0:19 X :0
root      4980 27.3  1.3 14596 7204 ?        S    07:33   0:19 X :0
root      4980 27.0  2.1 14596 11048 ?       S    07:33   0:19 X :0
root      4980 27.7  1.3 14596 7208 ?        S    07:33   0:20 X :0
root      4980 27.3  1.3 14596 7208 ?        S    07:33   0:20 X :0
root      4980 27.0  2.1 14596 11048 ?       S    07:33   0:20 X :0
root      4980 27.7  1.3 14596 7208 ?        S    07:33   0:21 X :0
root      4980 27.3  1.3 14596 7208 ?        S    07:33   0:21 X :0
root      4980 27.0  2.1 14596 11048 ?       S    07:33   0:21 X :0
root      4980 27.6  1.3 14596 7208 ?        S    07:33   0:22 X :0
root      4980 27.3  1.3 14596 7208 ?        S    07:33   0:22 X :0
root      4980 28.0  1.3 14596 7212 ?        S    07:33   0:22 X :0
root      4980 27.3  1.3 14596 7212 ?        S    07:33   0:22 X :0
root      4980 27.0  2.1 14596 11056 ?       S    07:33   0:23 X :0
root      4980 27.6  1.3 14596 7216 ?        S    07:33   0:23 X :0
root      4980 27.3  1.3 14596 7216 ?        S    07:33   0:23 X :0
root      4980 27.0  2.1 14596 11056 ?       S    07:33   0:23 X :0
root      4980 27.6  1.3 14596 7216 ?        S    07:33   0:24 X :0
root      4980 27.3  1.3 14596 7216 ?        S    07:33   0:24 X :0
root      4980 27.0  2.1 14596 11056 ?       S    07:33   0:24 X :0
root      4980 27.6  1.3 14596 7216 ?        S    07:33   0:25 X :0
root      4980 27.3  1.3 14596 7216 ?        S    07:33   0:25 X :0
root      4980 27.0  2.1 14596 11056 ?       S    07:33   0:25 X :0
root      4980 27.6  1.3 14596 7216 ?        S    07:33   0:26 X :0
root      4980 27.3  1.3 14596 7216 ?        S    07:33   0:26 X :0
root      4980 27.0  2.1 14596 11060 ?       S    07:33   0:26 X :0
root      4980 27.5  1.3 14596 7220 ?        S    07:33   0:27 X :0
root      4980 27.3  1.3 14596 7220 ?        S    07:33   0:27 X :0
root      4980 27.0  2.1 14596 11060 ?       S    07:33   0:27 X :0
root      4980 27.5  1.3 14596 7220 ?        S    07:33   0:27 X :0
root      4980 27.2  1.3 14596 7220 ?        S    07:33   0:27 X :0



I consider the leak to be resolved now.  Setting state back to MODIFIED.
Resolved in the 103 build.

Comment 15 Mike A. Harris 2006-05-02 11:48:44 UTC

(In reply to comment #12)
> Are you sure this isn't an FC-5 system?  mkfontdir/mkfontscale are located
> in /usr/bin only on FC-5 with modular X.  I have reviewed the RHEL-3 packages
> I've provided at the above URL (the 103.EL packages), and they invoke
> the proper command:
> 
> [mharris@people i386]$ rpm -qp --scripts
> XFree86-ISO8859-14-100dpi-fonts-4.3.0-103.EL.i386.rpm
> postinstall scriptlet (through /bin/sh):
> {
>     umask 133;/usr/X11R6/bin/mkfontdir /usr/X11R6/lib/X11/fonts/100dpi
> #    umask 133;which fc-cache &> /dev/null && fc-cache
> /usr/X11R6/lib/X11/fonts/100dpi
>     /usr/sbin/chkfontpath -q -a /usr/X11R6/lib/X11/fonts/100dpi:unscaled
> } &> /dev/null || :
> 
> 
> [mharris@people i386]$ rpm -qp --scripts
XFree86-syriac-fonts-4.3.0-103.EL.i386.rpm
> postinstall scriptlet (through /bin/sh):
> {
>   FONTDIR=/usr/X11R6/lib/X11/fonts/OTF
>   umask 133;/usr/X11R6/bin/mkfontscale $FONTDIR
>   umask 133;/usr/X11R6/bin/mkfontdir $FONTDIR
>   umask 133;which fc-cache &> /dev/null && fc-cache $FONTDIR
>   /usr/sbin/chkfontpath -q -a $FONTDIR
> } &> /dev/null || :
> postuninstall scriptlet (through /bin/sh):
> {
>   FONTDIR=/usr/X11R6/lib/X11/fonts/OTF
>   if [ "$1" = "0" ]; then
>     umask 133;/usr/X11R6/bin/mkfontscale $FONTDIR
>     umask 133;/usr/X11R6/bin/mkfontdir $FONTDIR
>     umask 133;which fc-cache &> /dev/null && fc-cache $FONTDIR
>   fi
> } &> /dev/null || :
> 
> 
> etc.
> 
> If this really is a RHEL-3 system, has it perhaps had FC-5 packages
> installed on it?  I have reviewed the XFree86.spec file in detail
> for the 103.EL build also, and all instances of mkfontdir/mkfontscale
> appear to be correct.
> 
> I did a quick check of the 102.EL build as well and it appears to be fine
> also.  Please provide the output from this failed system for the following
> commands:
> 
> rpm -q redhat-release
> rpm -qa |sort > rpm.log
> 
> I'm unable to reproduce this problem, and can't see how it could happen.


After a second report of the issue, I re-investigated the problem again.
In my initial check, I confirmed mkfontdir/mkfontscale usage, and confirmed
mkfontdir dependencies but seem to have missed mkfontscale dependency
problem.  The issue was due to using _bindir in the mkfontscale dep,
which has been corrected in the 104.EL build.

Apologies for any confusion.

Comment 17 Mike A. Harris 2006-05-04 10:48:51 UTC

XFree86-4.3.0-104.EL is now available for download via ftp at the following URL:
 ftp://people.redhat.com/mharris/testing/3.0E

Comment 22 Red Hat Bugzilla 2006-07-20 15:24:19 UTC

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-2006-0410.html