Bug 403711 - Memory leak with Second Life
Summary: Memory leak with Second Life
Alias: None
Product: Fedora
Classification: Fedora
Component: mesa
Version: 8
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Adam Jackson
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: secondlife
TreeView+ depends on / blocked
Reported: 2007-11-29 01:01 UTC by Callum Lerwick
Modified: 2018-04-11 16:33 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2007-12-13 04:13:32 UTC
Type: ---

Attachments (Terms of Use)

Description Callum Lerwick 2007-11-29 01:01:59 UTC
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-13 04:13:32 UTC
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.