Closed
Bug 374340
Opened 18 years ago
Closed 17 years ago
firefox (and Xorg as a consequence) eat all available memory with google maps
Categories
(Firefox :: General, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: lisik, Assigned: johnjbarton)
References
()
Details
Attachments
(4 files)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.2) Gecko/20060601 Firefox/2.0.0.2 (Ubuntu-edgy)
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.2) Gecko/20060601 Firefox/2.0.0.2 (Ubuntu-edgy)
Hi everyone
Using firefox 2.0.0.2 on Linux with maps.google.com makes the browser and Xorg eat all available memory in few minutes bringing the system to a crawl.
The same firefox version on Windows limits the memory usage to about 50 MB only.
No browser.cache.memory.xyz tweaking on both systems
System info: 1 GB of RAM and 1/2 GB of swap
Reproducible: Always
Steps to Reproduce:
1. go to maps.google.com
2. using hybrid/satellite map mode
3. move around the map for about 3-4 minutes zooming to some area
Actual Results:
all available memory including swap is being taken over by firefox and Xorg.
If you keep using google maps system is slowing to a crawl
Expected Results:
Firefox should have limited the memory usage to some level
Reporter | ||
Comment 1•18 years ago
|
||
Reporter | ||
Comment 2•18 years ago
|
||
Reporter | ||
Comment 3•18 years ago
|
||
Reporter | ||
Updated•18 years ago
|
Summary: firefox (and Xorg as a consequence) eat all avalable memory → firefox (and Xorg as a consequence) eat all avalable memory with google maps
Comment 4•18 years ago
|
||
I'm also seeing this with Linux Iceweasel 2.0.0.1.
I noticed something about "reclaiming memory from circularly-linked data structures" in the 3.0 pre-release-notes, and wondered if it could be related to this. But that would be cross-platform; does this really not affect windows?
Reporter | ||
Updated•18 years ago
|
Summary: firefox (and Xorg as a consequence) eat all avalable memory with google maps → firefox (and Xorg as a consequence) eat all available memory with google maps
Reporter | ||
Updated•18 years ago
|
Severity: normal → major
Reporter | ||
Comment 5•18 years ago
|
||
The previous firefox version (1.5.x) does not have this problem
Reporter | ||
Updated•18 years ago
|
Version: unspecified → 2.0 Branch
Comment 6•18 years ago
|
||
seeing this behavior in latest minefield trunk build.
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a6pre) Gecko/20070608 Minefield/3.0a6pre
Comment 7•18 years ago
|
||
I guess it'd help to add am running on Ubuntu Feisty 7.04, X.Org version 7.2
Comment 8•18 years ago
|
||
It might relates to bug 311130. I'm developing a google-maps-like engine and I can confirm this leak/memory issue relates to images loaded within javascript. Had to switch to alternative browser as it was making XOrg's memory grow to 300megs+
Opera on linux does nothing wrong to X when surfing google maps.
Flags: blocking-firefox3?
Comment 9•18 years ago
|
||
Hit 'eat, eat more' button cyclically to increase both X and Firefox memory usage.
Comment 10•18 years ago
|
||
We don't block on unconfirmed bugs, please renom once confirmed.
Flags: blocking-firefox3?
Comment 11•18 years ago
|
||
FYI, after further testing, it seems xorg memory problem is caused by firebug itself or interaction between fb+ff. Once this extension is disabled, xorg memory consumption goes back to normal on pages like maps.google.com.
Comment 12•18 years ago
|
||
> memory problem is caused by firebug
Well spotted! Yes, I also find that the problem goes away when Firebug is disabled.
Reporter | ||
Comment 13•18 years ago
|
||
There is a Firebug bug filed here:
http://code.google.com/p/fbug/issues/detail?id=34&q=images
It shows a temporary solution without having to turn Firebug entirely off.
Assignee | ||
Comment 14•17 years ago
|
||
Firebug fixed in version 1.1.0, please close this report.
Assignee | ||
Updated•17 years ago
|
Assignee: nobody → johnjbarton
Assignee | ||
Updated•17 years ago
|
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•