Bug 403711 - Memory leak with Second Life
Memory leak with Second Life
Product: Fedora
Classification: Fedora
Component: mesa (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: Adam Jackson
Fedora Extras Quality Assurance
Depends On:
Blocks: secondlife
  Show dependency treegraph
Reported: 2007-11-28 20:01 EST by Callum Lerwick
Modified: 2018-04-11 12:33 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-12-12 23:13:32 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Callum Lerwick 2007-11-28 20:01:59 EST
Description of problem:
Mesa 7 seems to have a memory leak in it, that Second Life (under review)
manages to trigger. The client rapidly eats up all RAM and chokes the machine
dead if you don't kill it first. This makes it rather unusable on a 512mb
machine. I suspect it has something to do with VBO, but it's hard to tell. I've
tried running the client under valgrind/massif, but it slows it down so much I
can't get a legitimate profile before it crashes or the connection times out. At
one point disabling VBO in the client seemed to be a work around, but that
doesn't seem to stop it anymore.

This happens on all three of the machines I've tried it on. One is an eMachines
m6805 which is an x86_64 machine with a Mobile Radeon 9600, one is an i386
machine with a Radeon 9800SE, and one is an i386 laptop with Intel 830M
integrated graphics. All running stock Fedora open source drivers.

This does not happen with stock F7. I originally saw this problem when I tried
pulling the Mesa 7 RPMs from rawhide and compiling them for F7. I reverted back
to Mesa 6 and the problem went away. I figured it was something I did wrong. But
now it's back with F8 which is why I'm now fairly certain its a problem with Mesa 7.

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

How reproducible:

Steps to Reproduce:
1. Run Second Life client
2. Stand around, preferably in a busy area
3. Watch your ram/swap usage
Actual results:
System eventually runs out of ram, swaps to death.

Expected results:
RAM usage should be fairly level, client should run for hours without running
out of RAM.
Comment 2 Callum Lerwick 2007-12-12 23:13:32 EST
Hrm, seems this was ultimately triggered by an OpenJPEG bug somehow, now fixed.

Note You need to log in before you can comment on or make changes to this bug.