Slashdot Mirror


Ubuntu LTS Experiences X.org Memory Leak

MonsterTrimble writes "Ubuntu 10.04 LTS Beta 2 is experiencing a major memory leak due to patches for X.org. 'An X.Org Server update that was pushed into the Lucid repository last week has resulted in the system being slower and slower as it is left on, until it reaches a point where the system is no longer usable. ... In order to make the Ubuntu 10.04 LTS deadline, the developers are looking at just reverting three of the patches, which brings the GLX version back to 1.2. Ubuntu developers are now desperate for people willing to test out this updated X.Org Server package so they can determine by this Friday whether to ship it with Ubuntu 10.04 LTS or doing an early SRU (Stable Release Update). Right now this X.Org Server that's being tested is living in the ubuntu-x-swat PPA.'"

8 of 320 comments (clear)

  1. Re:Valgrind? by Anonymous Coward · · Score: 2, Informative

    How come this wasn't caught when they were profiling? Notice I said "when" - the X.org people aren't seriously deploying patches to such a crucial app without profiling first, are they?

    Because this isn't a patch or bug from the "X.org people". It's a patch ubuntu applied to x.org for GLX 1.4 support or something like that. So the question should be, why aren't the ubuntu people profiling before releasing patches.

  2. Details on the Ubuntu Wiki by John+Whitley · · Score: 3, Informative

    The Ubuntu Wiki has details on this issue at the GEMLeak entry. It provides instructions on how to upgrade to (and remove) the candidate packages in the PPA. This comment is worthy of note for those already on Lucid:

    This does not affect cards using proprietary drivers or not using DRI2. Intel will always be affected since DRI2 is used with and without KMS, ATI uses DRI1 without KMS.

  3. Seems a bit over-hyped by Super+Techie · · Score: 5, Informative

    If you read the wiki page referenced carefully, it would seem that the general consensus is that the bug is fixed in the testing packages. https://wiki.ubuntu.com/X/Testing/GEMLeak Seems a bit blown out of proportion to me.

    1. Re:Seems a bit over-hyped by TheQuantumShift · · Score: 2, Informative

      And the important part from the wiki:

      This does not affect cards using proprietary drivers or not using DRI2.

      And a quick check of top shows xorg is "only" using 140MB currently on my machine (up 3 days, using fglrx)

      --

      Shift happens. Fire it up.
  4. Re:What? by nedlohs · · Score: 3, Informative

    Which would be why they sent that to their -dev mailing list.

    You do know the difference between someone sending a request, and someone else reporting on that request, and someone else reporting on someone else reporting on that request?

    Right???

  5. Re:Well... by h4rr4r · · Score: 3, Informative

    Installed by the OEM not MS.

  6. It's "Lucid Lynx" by MagicFab · · Score: 1, Informative

    During its development cycle, Ubuntu is called by its code name "Lucid Lynx".

    Only once it's released will it become Ubuntu 10.04 LTS.

    --
    Notepad specialist & FAT administrator, group training available
  7. Re:Valgrind? by nxtw · · Score: 4, Informative

    I never understood backporting. Sure, it gives the illusion of stability, but you're relying on a much smaller set of developers, those for your OS, who may or may not understand the upstream code well enough to make smart decisions and having them glue code in and call it a "stable" release version.

    Considering how much of the development actually comes from Red Hat, it's likely that at least they understand the upstream code well.

    One reasons I will always pick Debian - stable over running Red Hat / CentOS with it's 3 year old versions of software that has "backported" fixes.

    RHEL/CentOS software is only three years old if you're running a three year old version of RHEL/CentOS. The upcoming RHEL 6 will include newer software.

    Red Hat probably spends more time testing their backported fixes than the upstream developers spend testing the original code.