Bug 560668

Description of problem:
[RHEL5.3] Xorg Consumes all memory

This problem is across a number of systems, about 15 machines, All use KDE.
It is possible to make some changes on some systems.

What we found out so far is that the machine with the new nVidia driver consumed all memory again.

Machines with Vesa drivers are OK so far but the user of that workstation claims that it usually takes some time till it the phenomenon occurs.

This case is about one customer who has some sites worldwide.
All sites run with same configuration under Sun ULTRA20 M2 Workstation,with nVidia Video card.

About 15 of his systems experience this phenomenon worldwide.
We tried on one machine to update to a newer nVidia driver, and on another machine to use Vesa driver.

It is very problematic for the customer to work with Vesa drivers since he needs to use 1600x1200 screen resolution, and we couln't run this system with such resolution using Vesa driver.

After analysing his sar data of workstation with nVidia driver we found out that Xorg begins to consume alot of memory when the user is not working during evening hours.


We configured one of the problematic machines to use Vesa drivers,today on that machine Xorg consumes 1.4GB of memory.

We configured another machine to use Vesa drivers with an ATI card to make sure that nVidias drivers cause consumption of all memory.
(as mentioned previously, we couldn't use 1200x1600 resolution with Vesa driver and nVidia card)

In this case we've already seen that the problem reproduces also with ATI video card using Redhat's VESA drives, so this is not video card driver related problem.

The customer is currently preparing to deploy RHEL 5 within their organization.
The mentioned problem also reproduces on RHEL 4 systems.


Version-Release number of selected component (if applicable):


How reproducible:

It takes a very long time to see this problem
One thought about this bug:

 "how does xorg manage memory for quitting application" question:

12:42 < ofourdan|lunch> pamadio: you can always tell the X server to retain the resources, but that's for very specific use and hardly ever used  - But if you want you can :)
12:43 < ofourdan|lunch> one of the use is to set a pixmap to the root window, the app that sets the pixmaps needs to specify thatthe pixmap must not be freed once the app terminates
12:44 < ofourdan|lunch> another use is to make an app to self-recover from a network disconnection. Although this is theorically possible, I am yet to find an apps that implement this :)

12:54 < ofourdan> pamadio: see "man XSetCloseDownMode"
12:55 < ofourdan> pamadio: by default all connections start in DestroyAll mode.

From alanm: I've never seen this in practice either. 

Steps to Reproduce:

Customer s/w has to run for a very long time before this problem is seen
  
Actual results:
X.org Server consumes all memory

Expected results:

Normal operation of Xserver


Notes from SEG

This looks to be an issue that was supposed to have been fixed in the VESA driver

https://enterprise.redhat.com/issue-tracker/?module=issues&action=view&tid=81559
https://enterprise.redhat.com/issue-tracker/?module=issues&action=view&tid=83772

The problem here is that there wasn't a reproducer. Since it took so long for this problem to reappear I gather that there isn't an easy way to reproduce this ?

I could create a BZ for this but I know that engineering will want to have some way of reproducing this. This looks to me to be a slow memory leak and without some way of reproducing this I don't know if they will do anything about this.

The earlier IT's seem to indicate that this is a leak that occurs when closing a client so I would ask the customer if this is something that happens over a long period of time or does the memory consumption occur all of a sudden ?

I also don't see any indication of any long running applications that would eat up memory so it looks to be a VESA driver problem where memory isn't being released when a client closes down.

Let me know as soon as you can and I'll create a BZ for this but I'm really not sure if engineering will do much about it. The best I can do is pass it on to them and let them decide.

1) given where we are in the development cycle with RHEL 4. It's pretty late in the cycle.
2) the fact that these are U4 systems. I know that they will want to know why the customer systems have not been updated to U8.
3) the lack of a reproducer.

While there have been other reporters of similar behaviour from a couple of othe customers, the problems they have had have been attributed to faulty client code of their own and not from anything that we've distributed.

Since this occurs on RHEL5 as well, I'm filing this under RHEL5.

Additional info:

I've been going over the long history of this ticket and here are the facts as we know them:

1) This memory leak problem seems to occur on both RHEL4 and RHEL5.
2) The problem occurs with and without the Nvidia proprietary driver.
3) It takes a long time  for the problem to occur on customer systems. Up to three weeks.
4) We have not been able to reproduce the problem in house nor has this problem
  been seen elsewhere.
5) Usually, large amounts of memory consumption by the Xserver is caused by a large number of Xserver side memory requests for Pixmaps. The xrestop logs seem to indicate nothing out of the ordinary.
6) While I understand that people are getting upset (I would too), it's next to
  impossible to determine what the problem is without any way of replicating the problem.
7) The fact that this has not been reported elsewhere seems to indicate that there may be a problem with a customer application.

More NOTES:

1) the customer and us decided to keep the focus on RHEL5 (as the problem also occurs there). I am not sure a whether a bug for RHEL4 is still appropriate.

2) an interesting point the customer told is:

"""
When the application are closed, the xorg memory usage does not change.
"""

Do you know how xorg is suppose to manage memory when an application stop ?
Is it supposed to free back all ressources allocated for its display, or does it keep it in an sort of buffer used for the server own purpose ?

3) the customer requested us to log on those machine when the problem occurs to help them in a live fashion. (see below)