Bug 498357

Thanks for the bug report.  We have reviewed the information you have provided above, and there is some additional information we require that will be helpful in our diagnosis of this issue.

Could you please try to run Xvfb under valgrind and attach the resulting logs to this issue as an uncompressed attachment?

We will review this issue again once you've had a chance to attach this information.

Thanks in advance.

Created attachment 344230 [details]
valgrind output

Thanks for the help.  I hope I ran this correctly:

valgrind --tool=memcheck --leak-check=full Xvfb :1 -screen 0 1280x1024x24

If not, my appologies and thanks!

That looks like you just launched Xvfb and shut it down.  You should run gempak against it too, so we can see what the memory usage is like in the situation where you're encountering leaks.

Hi Adam,

I did, each time you see 'FreeFontPath:' blah blah, GEMPAK was run once.

daryl

Greetings,

Is there any more information I could provide you folks?

thanks,
  daryl

I also experience problems with xvfb.  Running xorg-x11-server-Xvfb.x86_64                                        1.1.1-48.52.el5  under kernel 2.6.18-128.1.6.el5.  When the system boots, xvfb crashes and needs to be restarted every 60-90 seconds until it becomes stable, sometime after 6+ hours.  We use xvfb in conjunction with WXP see http://wxp.unisys.com/  

I notice that Fedora 11 is up to version xorg-x11-server-Xvfb-1.6.1.901-1, wondering if some or all of those changes could be implemented under RHEL.

Xvfb is a package in heavy use by the university meteorology community for the automatic generation of weather maps and other products, prompt fix of this issue is greatly appreciated.

Thanks,
Brendon

I can echo Brendon's comments above. I am one of the big users on that machine and the other day, when I was placing high demands on xvfb, it was crashing in less than a minute. I finally had to run our checkxvfb script, which would restart it after a crash, before I generated my graphic, which needed Xvfb. I generated thousands of images for a research project and it had to restart very frequently.

This is really my first experience with RedHat, as I have been a user of FreeBSD for over 10 years. I can never remember a single crash of Xvfb, since it became available on the systems running FreeBSD. I really would like to see a fix to this problem ASAP.

Jim

Hi Jim,

I've been using Xvfb for many, many moons and never ran into trouble until now.  Will have to see how RHEL5.4 beta's xvfb behaves.  

Thankfully, I don't task xvfb enough to make it crash.  Are you sure your crashes are not related to memory exhaustion?

daryl

Daryl,

I'm not sure about the memory problem, I'll have to let Brendon check into that next week, when he is back from vacation. However, yesterday for several hours, I pointed ALL of our graphics generating routines that use Xvfb to use another FreeBSD machine's Xvfb as a remote DISPLAY device (I can easily do that by changing a one line file, which all of our graphics generating programs access to see which display to use). During several hours of this experiment, the result was that Xvfb was still crashing on the RH box and still was being restarted at least every 5-15 minutes even though no activity was being sent its way. Xvfb was stable with no crashes on the FreeBSD box--in fact we don't even have an automatic check and restart script on it.

Xvfb is extremely important for our operations and research.

Jim

Greetings RedHat,

Is there any more information I could provide you folks?  In the past 30 days, my Xvfb binary leaked just about 3 GB of memory.  I don't have issues with it crashing like my colleagues do.  Perhaps if I reached memory exhaustion, it would crash...

thanks,
  daryl

Hi Daryl

RHEL get bugs get addressed a lot faster if they are submitted via customer support/tam via issue tracker. 

There are times when I've seen bugs submitted by BZ on RHEL problems that wind up hanging in limbo because there isn't an issue tracker ticket associated with it.

Having two tools can be a problem because support uses IT,  engineering uses BZ and product management makes their decisions using both.

Hi Ritz,

Thanks for the message.  We are just a EDU customer with a cheap site subscription without support (other than for the rhn proxy machine).  No TAM either :) 

daryl

Howdy,

The RHEL5.4 Xvfb leaks in the same manner :)  

xorg-x11-server-Xvfb-1.1.1-48.67.el5

daryl

Howdy,

The RHEL5.5 Xvfb leaks in the same manner :)

xorg-x11-server-Xvfb-1.1.1-48.76.el5

daryl

RHEL 6 Xvfb leaks as well :(

RHEL 6.1 Xvfb leaks as well :(

My workaround for the xvfb memory leak/crash to restart xvfb daily via a cronjob. Hope we will see a resolution to xvfb mem leak in rhel 5u7.

sorry @linferna , RHEL 5.7 Xvfb leaks as well :(

RHEL 6.2 Xvfb leaks as well :(

Created attachment 558246 [details]
rhel6.2 valgrind output

More valgrind output for RHEL6.2 attached.  Just ran for about 20 minutes with the command:

valgrind --log-file=/tmp/myvg.log --tool=memcheck --leak-check=full --show-reachable=yes Xvfb :1 -screen 0 1280x1024x24

So X has this silly notion of a "server regeneration", which is a bunch of teardown-and-reset that happens on the transition from N>1 clients to 0.  It looks like most of the leaked memory there is coming from the regeneration path.

As a (bad) workaround you could run Xvfb with -noreset, which will skip the regeneration code and just sit idle when the last client disconnects.  Technically that violates the letter of the X protocol spec but it's doubtful that your application is going to notice.

Thank you.  I have been running the '-noreset' since your message and it appears to be working!  Have not seen any of the applications complain either.

It is definitely working! Running for over a day now and near no change in memory, yipeee!  Thank you very much.

Some suggested patches for this issue:
http://lists.freedesktop.org/archives/xorg-devel/2012-February/029524.html

Backported the applicable leak fixes from the upstream patch series in comment #30.

MODIFIED

Memory leak is still visible with the most updated packages when running:

# Xvfb :1 -screen 0 800x600x24 &
# while true; do xdpyinfo -display :1 ; done

Monitor using "top" in another terminal session and Xvfb constantly increases memory usage.

pmap results: 49304k to 89356k in 2560 iterations of xdpyinfo.

I will attach the pmap log.

Created attachment 614436 [details]
pmap log

Re-tested (using method in comment 37) with xorg-x11-server-1.1.1-48.97.el5 and associated:

49308K to 133116K in ~2hr and 40mins. The leak has slowed down, but is still evident. Is this acceptable?

(In reply to comment #39)
> Re-tested (using method in comment 37) with xorg-x11-server-1.1.1-48.97.el5
> and associated:
> 
> 49308K to 133116K in ~2hr and 40mins. The leak has slowed down, but is still
> evident. Is this acceptable?

no, this is unacceptable. Imagine that it needs to run for days.
-> ASSIGNED

Yet another hole plugged, MODIFIED again.

New packages fixed the memory leak entirely. Locked at 49276K, I will be running it over night but for now, Verified.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-0083.html