Memory Leak in Firebug
Sworddragon
hanging some times. After ~7 days firefox is opened there is a leak of
~100 MB memory and firefox is hanging very often (every 10 seconds a
freeze of 1 second). After a lot of weeks i have localized the
problem. This problem occurs only with Firebug enabled (all other
addons are disabled). A pure firefox don't have this problem. I'm
using Firefox 3.5.6 with Firebug 1.4.5 (console, net and script are
disabled). I have tested this problem in Firebug 1.5X.0b8 and can
confirm this issue in this version too.
John J Barton
How many of those 100MB are required by Firebug to support your
debugging?
jjb
Sworddragon
> debugging?
I don't understand your question. Maybe this helps you: After 7 days
without Firebug enabled firefox never used more then 100 MB memory.
With Firebug enabled Firefox was using near of 200 MB memory after 7
days. Every day the memory usage was increasing a little and the
freezes becomes more often. The annoying thing for me are the short
freezes of this problem.
John J Barton
Your description of your browser experience uses words like 'leak' and
'freeze'. My question is: how can we know the difference between a
'leak' and simply your app takes a lot of memory to debug? or between
a 'freeze' and your app takes a lot of CPU to debug?
jjb
Sworddragon
> 'freeze'. My question is: how can we know the difference between a
> 'leak' and simply your app takes a lot of memory to debug? or between
> a 'freeze' and your app takes a lot of CPU to debug?
As i sayed i have tested firefox with firebug enabled and after this i
have tested it with firebug disabled. Without firebug firefox is not
using more than 100 MB of memory and with firebug enabled firefox uses
~200 mb of memory (just after the seventh day). And this with all tabs
closed and a cleared cache (the cache control in firefox is set to
automatic). Firefox was using every day a little bit more of memory
but only with firebug enabled and firefox was freezing every day a
little bit more only with firebug enabled too. This seems for me to a
memory leak this causes firebug to freeze the browser sometimes. This
bug is every time reproduceable (I'm using Windows XP Professional SP3
if it is necessary) and now some programmers can try to analyze this
problem to see if this is really a memory leak.
Brian Di Palma
--
You received this message because you are subscribed to the Google Groups "Firebug" group.
To post to this group, send email to fir...@googlegroups.com.
To unsubscribe from this group, send email to firebug+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/firebug?hl=en.
John J Barton
On Jan 6, 9:33 am, Brian Di Palma <off...@gmail.com> wrote:
> I simply restart FF. Honestly, Firebug leaks, but the effort required to fix
> these issues
> would probably be large. I might be wrong but I doubt the Firebug devs are
> going to try and fix leaks and I don't blame them as it's a massive
> time sink.
I appreciate your attitude. I've worked on bug reports for Firebug
memory problems many times. A couple of times I've found and fixed a
problem. But the cost/benefit ratio is way out of whack. For some
reason memory problems in particular are reported with great
indignation and very little in the way of facts. I have to go back and
forth for a long time to get a test case. Then lots of times the
problem is actually in the application, eg it loads images in a loop
or something. If I find and fix a bug, I never recall anyone verifying
that Firebug was better for them afterwards.
But I don't want anyone to take this as a sign I would not try again.
Rather it's the opposite: if anyone wants to put the effort into a
test case for a memory (or CPU problem), I'll work on it right away. I
just don't to complain about leaks then not follow up with facts.
So SwordDragon, you say you can reproduce these problems. How?
jjb
Sworddragon
Maybe you missunderstood me, because the reproduction is explained in
my other posts. Maybe my english acknowledgment is to bad for such
complex posts.
I try it to explain it simple:
Just run your firefox with firebug enabled about 1-7 days and do your
daily requests (like looking for other bug reports on firebug) and
look at your memory usage sometimes after closing all tabs and
deleting your cache. You will see a little increased memory usage
every day. In this time you will got hundred of freezes and this is
not because an image that is loading in a loop because all contents
are already loaded (for example i got this freezes permanently with a
local version of phpMyAdmin and all other sites that i visit).
John J Barton
On Jan 6, 10:47 am, Sworddragon <sworddrag...@aol.com> wrote:
> > So SwordDragon, you say you can reproduce these problems. How?
>
> Maybe you missunderstood me, because the reproduction is explained in
> my other posts. Maybe my english acknowledgment is to bad for such
> complex posts.
I think your english is great! But I think you misunderstand what a
test case is.
I need a detailed step-by-step procedure that everyone can apply and
get exactly the same result, and a way to tell that we got the same
result. For example,
1. Use Firebug 1.6a1 in Firefox 3.5.7
2. Open http://getfirebug.com
3. Open Firebug with F12
4. Enable all panels, select the Console panel
5. Reload
6. Check the OS memory
7. Reload
8. Compare the OS memory with step 6 after waiting for 5 seconds.
The result will be no significant increase in memory no matter how
many times you repeat 5-8.
So there is my test which shows that Firebug has no leaks. You repeat
that test. Do you see a different result? If not then do you have a
change to the test which shows a leak?
jjb
>
> I try it to explain it simple:
>
> Just run your firefox with firebug enabled about 1-7 days and do your
> daily requests (like looking for other bug reports on firebug) and
> look at your memory usage sometimes after closing all tabs and
> deleting your cache. You will see a little increased memory usage
> every day. In this time you will got hundred of freezes and this is
> not because an image that is loading in a loop because all contents
> are already loaded (for example i got this freezes permanently with a
> local version of phpMyAdmin and all other sites that i visit).
I'm completely sure you have a problem. But this isn't a test case,
the steps are too vague to reproduce.
jjb
Sworddragon
> get exactly the same result, and a way to tell that we got the same
> result. For example,
> 1. Use Firebug 1.6a1 in Firefox 3.5.7
> 3. Open Firebug with F12
> 4. Enable all panels, select the Console panel
> 5. Reload
> 6. Check the OS memory
> 7. Reload
> 8. Compare the OS memory with step 6 after waiting for 5 seconds.
> The result will be no significant increase in memory no matter how
> many times you repeat 5-8.
>
> So there is my test which shows that Firebug has no leaks. You repeat
> that test. Do you see a different result? If not then do you have a
> change to the test which shows a leak?
Firebug 1.6a1 is not compatible with firefox 3.5.7 so i installed
firefox 3.6 Beta 5 and firebug 1.6a1. I disabled all addons and
plugins excepting firebug and restarted firefox. I opened firebug and
have enabled all panels. I made a lot of reloads over ~30 minutes at
this site. At the beginning firefox was using ~75 MB of memory. The
memory usage increased a very little with every reload. After the 30
minutes i cleared the cache and firefox was using ~200 MB of memory.
After this i visited some sites to look if the freezes are back and i
can confirm it. The freezes comes every ~10-30 seconds and freezes the
browser for ~1 second. Not only this, I got a new issue. Firefox is
writing all letters at any page with a delay. If I do nothing the
overall cpu usage is between 0 and 2%. If I type only a letter the cpu
usage increases to 50% (2 core processor).
John J Barton
On Jan 6, 1:45 pm, Sworddragon <sworddrag...@aol.com> wrote:
> > I need a detailed step-by-step procedure that everyone can apply and
> > get exactly the same result, and a way to tell that we got the same
> > result. For example,
> > 1. Use Firebug 1.6a1 in Firefox 3.5.7
> > 2. Openhttp://getfirebug.com
> > 3. Open Firebug with F12
> > 4. Enable all panels, select the Console panel
> > 5. Reload
> > 6. Check the OS memory
> > 7. Reload
> > 8. Compare the OS memory with step 6 after waiting for 5 seconds.
> > The result will be no significant increase in memory no matter how
> > many times you repeat 5-8.
>
> > So there is my test which shows that Firebug has no leaks. You repeat
> > that test. Do you see a different result? If not then do you have a
> > change to the test which shows a leak?
>
> Firebug 1.6a1 is not compatible with firefox 3.5.7 so i installed
> firefox 3.6 Beta 5 and firebug 1.6a1. I disabled all addons and
> plugins excepting firebug and restarted firefox. I opened firebug and
> have enabled all panels. I made a lot of reloads over ~30 minutes at
> this site. At the beginning firefox was using ~75 MB of memory. The
Which "this site"? Do you mean:
http://groups.google.com/group/firebug/browse_frm/thread/260d8dca10ee402e
How can I reproduce "a lot"? Can you reproduce the problem with 1
reload? 10 reloads? I need the bare minimum steps, otherwise I can't
fix the problem. I can't wait 30minutes for every test.
> memory usage increased a very little with every reload. After the 30
How can I compare to "a very little"? 1byte? 10MB?
> minutes i cleared the cache and firefox was using ~200 MB of memory.
How much memory was used before you cleared the cache? Did it jump up
when
you cleared the cache? If yes, then what buttons did you push to
perform this step? (Something like Firefox > Tools > Clear Recent
History > Deatils ...?) If the memory did not jump when you cleared
the cache, then why did you do that step?
> After this i visited some sites to look if the freezes are back and i
> can confirm it. The freezes comes every ~10-30 seconds and freezes the
> browser for ~1 second. Not only this, I got a new issue. Firefox is
How can I tell that my browser acts like yours? What specific user
interface change do you call a "freeze"?
> writing all letters at any page with a delay. If I do nothing the
> overall cpu usage is between 0 and 2%. If I type only a letter the cpu
> usage increases to 50% (2 core processor).
Please open Firefox > Tools > Error Console. Clear it. Then tell me if
any message appear when you type.
jjb
Sworddragon
Yes, i mean the site of this thread.
> How can I reproduce "a lot"? Can you reproduce the problem with 1
> reload? 10 reloads? I need the bare minimum steps, otherwise I can't
> fix the problem. I can't wait 30minutes for every test.
In the 30 minutes i made some hundred refreshes of this site. I think
it was near 1000 refreshes. But it seems there is no limit. Make only
500 refreshes for a less leak or make 2000 refreshes for maybe over
300 MB of memory usage.
> How can I compare to "a very little"? 1byte? 10MB?
Just some KB for every reload. I haven't noticed every reload. I have
just seen that the memory usage was increasing a few MB (5-10) every
few reloads (20-50).
> How much memory was used before you cleared the cache? Did it jump up
> when
> you cleared the cache? If yes, then what buttons did you push to
> perform this step? (Something like Firefox > Tools > Clear Recent
> History > Deatils ...?) If the memory did not jump when you cleared
> the cache, then why did you do that step?
Before i cleared the cache the memory usage was the same (~200 MB). I
did this step because i saw sometimes that the memory usage goes down
after clearing the cache. Maybe it was just a random or maybe firefox
is deallocationg some or all the cache that is hold in the RAM.
> How can I tell that my browser acts like yours? What specific user
> interface change do you call a "freeze"?
The complete process is freezing. That means you can do what you want
for example:
- Just scroll up and down a site for ~1 minute and it stops sometimes
because of the freeze.
- Select things in a dropdown field or other elements and it will
stops selecting if the freeze occurs.
- Watch some videos and they will freeze to.
At the last months i noticed that the freezes becomes more often and
are longer if the memory usage is higher.
> Please open Firefox > Tools > Error Console. Clear it. Then tell me if
> any message appear when you type.
I have already restartet firefox. But maybe this helps you: The delay
was in the address bar of firefox too.
John J Barton
On Jan 6, 5:42 pm, Sworddragon <sworddrag...@aol.com> wrote:
> > Which "this site"? Do you mean:http://groups.google.com/group/firebug/browse_frm/thread/260d8dca10ee...
>
> Yes, i mean the site of this thread.
By the way some people read the newsgroup by email.
>
> > How can I reproduce "a lot"? Can you reproduce the problem with 1
> > reload? 10 reloads? I need the bare minimum steps, otherwise I can't
> > fix the problem. I can't wait 30minutes for every test.
>
> In the 30 minutes i made some hundred refreshes of this site. I think
> it was near 1000 refreshes. But it seems there is no limit. Make only
> 500 refreshes for a less leak or make 2000 refreshes for maybe over
> 300 MB of memory usage.
Ok but I can't refresh 1000 times to solve the problem, it's not
practical.
We could get some hints by running with the Console/Script/Net panels
disabled.
>
> > How can I compare to "a very little"? 1byte? 10MB?
>
> Just some KB for every reload. I haven't noticed every reload. I have
> just seen that the memory usage was increasing a few MB (5-10) every
> few reloads (20-50).
>
> > How much memory was used before you cleared the cache? Did it jump up
> > when
> > you cleared the cache? If yes, then what buttons did you push to
> > perform this step? (Something like Firefox > Tools > Clear Recent
> > History > Deatils ...?) If the memory did not jump when you cleared
> > the cache, then why did you do that step?
>
> Before i cleared the cache the memory usage was the same (~200 MB).
Ok, so the cache is not part of the problem, let's forget about it.
I
> did this step because i saw sometimes that the memory usage goes down
> after clearing the cache. Maybe it was just a random or maybe firefox
> is deallocationg some or all the cache that is hold in the RAM.
>
> > How can I tell that my browser acts like yours? What specific user
> > interface change do you call a "freeze"?
>
> The complete process is freezing. That means you can do what you want
> for example:
> - Just scroll up and down a site for ~1 minute and it stops sometimes
> because of the freeze.
> - Select things in a dropdown field or other elements and it will
> stops selecting if the freeze occurs.
> - Watch some videos and they will freeze to.
>
> At the last months i noticed that the freezes becomes more often and
> are longer if the memory usage is higher.
Please check the total memory used on your machine. I guess your
machine is paging. That is, it's just another side effect of the
memory used rather than a different problem.
jjb
Sworddragon
> practical.
>
> We could get some hints by running with the Console/Script/Net panels
> disabled.
I have tested a lot of reloads again for ~1 hour. I have disabled the
console, script and net panel. I have made several tests like:
Refreshes without opening the main panel of firebug at any time (F12).
Refreshes with opened main panel and the pointer to the disabled
console, HTML, CSS and DOM panel.
The memory usage was pending in an area of ~20-40 MB at reloadings.
After every test i looked for freezes but i haven't noticed any (maybe
they are to weak at the moment). The memory usage was increasing just
a few MB after any test and at the end firefox is using now ~146 MB of
memory if all tabs are closed. This seems to be a leak too and maybe
it want get bigger and i will got the freezes if i'm refreshing for
some more hours or surfing a few days.
> Please check the total memory used on your machine. I guess your
> machine is paging. That is, it's just another side effect of the
> memory used rather than a different problem.
The paging is disabled so my operating system can only use his ~3,5 GB
of physical memory.
John J Barton
On Jan 6, 8:22 pm, Sworddragon <sworddrag...@aol.com> wrote:
> > Ok but I can't refresh 1000 times to solve the problem, it's not
> > practical.
>
> > We could get some hints by running with the Console/Script/Net panels
> > disabled.
>
> I have tested a lot of reloads again for ~1 hour. I have disabled the
> console, script and net panel. I have made several tests like:
> Refreshes without opening the main panel of firebug at any time (F12).
Sorry I can't follow the paragraph below this one. For this test, did
you see the same leak as before? None?
> Refreshes with opened main panel and the pointer to the disabled
> console, HTML, CSS and DOM panel.
? The pointer to? Anyway the result was?
>
> The memory usage was pending in an area of ~20-40 MB at reloadings.
Is that good or bad?
> After every test i looked for freezes but i haven't noticed any (maybe
> they are to weak at the moment). The memory usage was increasing just
> a few MB after any test and at the end firefox is using now ~146 MB of
> memory if all tabs are closed. This seems to be a leak too and maybe
> it want get bigger and i will got the freezes if i'm refreshing for
> some more hours or surfing a few days.
>
> > Please check the total memory used on your machine. I guess your
> > machine is paging. That is, it's just another side effect of the
> > memory used rather than a different problem.
>
> The paging is disabled so my operating system can only use his ~3,5 GB
> of physical memory.
Let's see if we can sort out the memory issues first.
jjb
Sworddragon
> you see the same leak as before? None?
Not the same leak it was more like a lite version of the memory leak.
Maybe there are more leaks in different modules. This there be an
explanation why in this test case the leak is just so low an i needed
the double time to see that is a memory leak. But this is just a
speculation.
> ? The pointer to? Anyway the result was?
With pointer I mean that the panel was selected. The result was that
there was a little more memory usage after a few hundred reloads with
any panel selected.
> > The memory usage was pending in an area of ~20-40 MB at reloadings.
>
> Is that good or bad?
I don't think it's bad. I made a realod every ~2 seconds and firefox
seems to be cache every time the site again in the memory. After a few
reloads the memory is decreasing a little (~20-40 MB). I think this is
just a garbage collection of firefox.
John J Barton
one you ran.
http://getfirebug.com/tests/issues/leak/reloadSimple.html
When you put that URL in to the location bar and append "?v=1" to the
end, the page will auto reload until you kill the page.
You will probably want to have a second tab open, with eg Firebug off
though it might be interesting to try with it on.
I ran it until I got 1000 reloads, then I closed the tab and waited a
bit to let the garbage collector run if it would.
With Firebug open on the Console panel and all panels enabled the
memory for Firefox went from 50MB to 65MB.
With Firebug closed, Firefox went from 47MB to 67MB.
With a different profile, no extensions installed, Firefox went from
45MB to 61MB.
These reloads are so fast that I think lots of Firebug code never
runs. I can add a delay to insure that the result is more similar to
manual reload. By cloning this file and adding HTML, CSS, JS, or net
traffic the reload case can be studied.
You can try this test case and see if you get the same results.
jjb
Sworddragon
the firebug main panel was opened and the script panel was selected.
Now i tried on this thread to make some reloads with the firebug main
panel closed. After 15 minutes the memory usage was just commuting
around 90 MB. Then I have opened the main panel and selected the
script panel. I got at every reload a break error and after 10 minutes
the memory usage after closing all tabs is ~130 MB. I'm writing now a
own script which does many reloads and try to get the memory leak. At
success i will post it here.
Sworddragon
(20002 reloads were made in this time) with the opened main panel of
firebug and the script panel selected. The memory usage of firefox was
177 MB after i closed all tabs. The freezes was back too. The script
uses a cookie to count the reloads so the firebug main panel stay
opened. The script can be downloaded here: http://rapidshare.com/files/331627349/memory_leak.html
Beware that the script uses the full power of your processor (firefox
limit it to 1 core).
John J Barton
On Jan 7, 2:26 am, Sworddragon <sworddrag...@aol.com> wrote:
> I could successfully created the script. I have tested it 1 hour
But as I tried to explain before, this kind of test is not useful.
There are almost no tools to find a memory leak. The only way I have
been successful in the past is by trial-and-error:
1) Find a test case that can show the leak quickly,
2) Change a parameter of the test run (panel selection, panel enable,
kind of page content, Firebug option, etc).
3) Look for a case where the leak does not happen.
4) Go to 2.
So we need a test that provides an answer in at most 2 minutes.
Otherwise the procedure is not practical.
jjb
Sworddragon
But the test is running automatically so you can do something else at
this time.
> 1) Find a test case that can show the leak quickly,
> 2) Change a parameter of the test run (panel selection, panel enable,
> kind of page content, Firebug option, etc).
> 3) Look for a case where the leak does not happen.
> 4) Go to 2.
While i was sleeping the test was running for 12 hours (1907434
Reloads). At this test i haven't opened the firebug main panel. After
the 12 hours firefox was just using a memory amount of ~48 MB after
closing all tabs and no freezes have occured.
> So we need a test that provides an answer in at most 2 minutes.
> Otherwise the procedure is not practical.
Just run my test 2 minutes and you will get a memory leak of 2-4 MB or
is that not enough?
John J Barton
On Jan 7, 2:05 pm, Sworddragon <sworddrag...@aol.com> wrote:
> > But as I tried to explain before, this kind of test is not useful.
>
> But the test is running automatically so you can do something else at
> this time.
Not with my computer, it is pegged at 100% CPU during the test.
>
> > 1) Find a test case that can show the leak quickly,
> > 2) Change a parameter of the test run (panel selection, panel enable,
> > kind of page content, Firebug option, etc).
> > 3) Look for a case where the leak does not happen.
> > 4) Go to 2.
>
> While i was sleeping the test was running for 12 hours (1907434
> Reloads). At this test i haven't opened the firebug main panel. After
> the 12 hours firefox was just using a memory amount of ~48 MB after
> closing all tabs and no freezes have occured.
I ran your test for 1000 rounds with Firebug closed. The memory went
from 83M to 87M.
Then I ran your test for 5000 rounds with Firebug open on the script
panel. The memory went from 87M to 95M.
If there is a leak in Firebug that amounts to <4M in 5000 reloads,
then in my opinion it is not worth further investigation.
Now I would guess that you are surprised or disappointed or even
disbelieving by my result. So the next step is for you to create a new
Firefox profile, install only Firebug 1.6a2, and repeat exactly either
your test or mine.
>
> > So we need a test that provides an answer in at most 2 minutes.
> > Otherwise the procedure is not practical.
>
> Just run my test 2 minutes and you will get a memory leak of 2-4 MB or
> is that not enough?
No because the memory reading with Firefox is not accurate to 2-4MB,
it has garbage collection.
jjb
Sworddragon
You can run the test if you are taking a bath or something else that
needs some time :P
So you can see the big leak and the freezes.
> If there is a leak in Firebug that amounts to <4M in 5000 reloads,
> then in my opinion it is not worth further investigation.
You mustn't forget that this test is like a benchmark. There is not
many content that firebug does analyze. This thread shows that the
slower manual refreshes with more content got such a big memory leak
too.
> Now I would guess that you are surprised or disappointed or even
> disbelieving by my result. So the next step is for you to create a new
> Firefox profile, install only Firebug 1.6a2, and repeat exactly either
> your test or mine.
I created a new profile, installed firebug 1.6a2 and disabled all
other addons and plugins and repeatet my test with the selected script
panel. After 1 hour (~20600 reloads) firefox was using 196 MB of
memory.
John J Barton
On Jan 7, 10:48 pm, Sworddragon <sworddrag...@aol.com> wrote:
> > Not with my computer, it is pegged at 100% CPU during the test.
>
> You can run the test if you are taking a bath or something else that
> needs some time :P
> So you can see the big leak and the freezes.
Notice that your concern here is that Firefox memory increases after
hundreds of reloads. Why is that important to you? I suspect that you
use one reload for every change to your site/code as a means of
development. That is certainly the way I have to work on Firebug. Are
you willing to wait to see this problem fixed until I have 1000 baths?
>
> > If there is a leak in Firebug that amounts to <4M in 5000 reloads,
> > then in my opinion it is not worth further investigation.
>
> You mustn't forget that this test is like a benchmark. There is not
> many content that firebug does analyze. This thread shows that the
> slower manual refreshes with more content got such a big memory leak
> too.
So far I see no evidence of a memory leak. In your machine you have
lots of memory taken in the exotic case of tens of thousands of
reloads. Also in you see lots of memory taken for manual refreshes
over 7 days. Still the question remains as to the cause of your
problems. So far we have no way to know if the problem is a Firebug
memory leak. The fact that the problem disappears when you disable
Firebug does point to Firebug as being involved. But until we have a
test case that shows the problem on my machine I can't help you.
>
> > Now I would guess that you are surprised or disappointed or even
> > disbelieving by my result. So the next step is for you to create a new
> > Firefox profile, install only Firebug 1.6a2, and repeat exactly either
> > your test or mine.
>
> I created a new profile, installed firebug 1.6a2 and disabled all
> other addons and plugins and repeatet my test with the selected script
> panel. After 1 hour (~20600 reloads) firefox was using 196 MB of
> memory.
I don't understand your test. If you create a new profile, then
install Firebug, how can you have any other addons or plugins to
disable?
jjb
Sworddragon
> lots of memory taken in the exotic case of tens of thousands of
> reloads. Also in you see lots of memory taken for manual refreshes
> over 7 days. Still the question remains as to the cause of your
> problems. So far we have no way to know if the problem is a Firebug
> memory leak. The fact that the problem disappears when you disable
> Firebug does point to Firebug as being involved. But until we have a
> test case that shows the problem on my machine I can't help you.
I don't know why you aren't willing to make just one longer test. You
must only one time make my test with 20000 reloads (on my processor it
needs ~1 hour) if the script panel is selected (maybe this test needs
a little shorter or longer dependend on you processor). I have
extended my test with parameters. You can control it with the starting
round, a limit and a delay. The default values are no delay, no limit
and a round of 1. If you want to make only one full try at this test
you will see the full memory leak (this test needs ~20000 reloads
too).
http://rapidshare.com/files/332397158/memory_leak.html
> I don't understand your test. If you create a new profile, then
> install Firebug, how can you have any other addons or plugins to
> disable?
Firefox is reading addons and plugins from external ressources like
Microsoft .NET Framework Assistant, flash plugin, java plugin and many
more. This is the reason why i must disable them after creating a new
profile.
John J Barton
On Jan 8, 2:51 pm, Sworddragon <sworddrag...@aol.com> wrote:
> > So far I see no evidence of a memory leak. In your machine you have
> > lots of memory taken in the exotic case of tens of thousands of
> > reloads. Also in you see lots of memory taken for manual refreshes
> > over 7 days. Still the question remains as to the cause of your
> > problems. So far we have no way to know if the problem is a Firebug
> > memory leak. The fact that the problem disappears when you disable
> > Firebug does point to Firebug as being involved. But until we have a
> > test case that shows the problem on my machine I can't help you.
>
> I don't know why you aren't willing to make just one longer test. You
> must only one time make my test with 20000 reloads (on my processor it
> needs ~1 hour) if the script panel is selected
For two reasons: 20,000 reloads is not realistic and 1 hour is not
practical for fixing a memory bug.
I really appreciate your efforts. But we need either a more realistic
test case or a faster one. I know you are convinced there is a
problem, but Firebug has lots of problems. So far the information
looks like this problem is not very significant. I'm sorry you have to
restart Firefox every few days, but really it's not such a big cost
for using Firebug. I think it makes more sense for me to work on
changing Firebug so users don't have to reload to debug. Then any
memory increase on reload won't matter.
If you want to do more experiments I will make more suggestions.
First I would suggest you check that the script panel is truly related
to the problem. Check another panel, eg HTML and Console. If the
memory increase only happens when the Script is selected, then try the
script-limiter, the small menu on the tool bar that says "All".
Another kind of change is to increase the HTML (by 10x) or the
scripts.
jjb
Sworddragon
On 9 Jan., 02:11, John J Barton <johnjbar...@johnjbarton.com> wrote:
> On Jan 8, 2:51 pm, Sworddragon <sworddrag...@aol.com> wrote:
>
> > > So far I see no evidence of a memory leak. In your machine you have
> > > lots of memory taken in the exotic case of tens of thousands of
> > > reloads. Also in you see lots of memory taken for manual refreshes
> > > over 7 days. Still the question remains as to the cause of your
> > > problems. So far we have no way to know if the problem is a Firebug
> > > memory leak. The fact that the problem disappears when you disable
> > > Firebug does point to Firebug as being involved. But until we have a
> > > test case that shows the problem on my machine I can't help you.
>
> > I don't know why you aren't willing to make just one longer test. You
> > must only one time make my test with 20000 reloads (on my processor it
> > needs ~1 hour) if the script panel is selected
>
> For two reasons: 20,000 reloads is not realistic and 1 hour is not
> practical for fixing a memory bug.
>
> I really appreciate your efforts. But we need either a more realistic
> test case or a faster one. I know you are convinced there is a
> problem, but Firebug has lots of problems. So far the information
> looks like this problem is not very significant. I'm sorry you have to
> restart Firefox every few days, but really it's not such a big cost
> for using Firebug. I think it makes more sense for me to work on
> changing Firebug so users don't have to reload to debug. Then any
> memory increase on reload won't matter.
I doesn't really have a problem with this memory leak it is just a
little annoying. I'm reporting many bugs on many applications not just
firebug. Not all reported bugs are beeing fixed and sometimes my
reports are completely ignored.
> If you want to do more experiments I will make more suggestions.
>
> First I would suggest you check that the script panel is truly related
> to the problem. Check another panel, eg HTML and Console. If the
> memory increase only happens when the Script is selected, then try the
> script-limiter, the small menu on the tool bar that says "All".
>
> Another kind of change is to increase the HTML (by 10x) or the
> scripts.
At first I have updated firefox to version 3.5 RC1. I have made a lot
of tests (with 1000 reloads) the last hours. I have opened the firebug
main panel and closed them directly. After 20000 reloads there was no
memory leak so the main panel must be opened to get the memory leak. I
have called a debug function that does some things. Allocationg
content to various types of variables and manipulating the DOM.
Nothing of them increased the memory usage more as without this debug
function. Even 30000 calls of this function (not in a loop, I have
copied and pasted it) per reload doesn't change anything. Removing the
CDATA from the javascript code doesn't change anything too. After this
I have added more HTML elements. 15000 <div>Debug</div> and the memory
usage was increasing after 1000 reloads to ~70 MB (the previous tests
without this additional HTML content was using just ~55-60 MB. I have
maded some tests with various things like nested elements and the
memory usage was ~70 MB too. Using CDATA or a comment to the 15000
<div>Debug</div> needs just ~55-60 MB and the same happens with using
only one div - container that contains 250000 zeros (0) as content. It
seems that the memory leak appears on parsing HTML elements
independent from the amount of content in the HTML elements.
At next I'm doing 6 tests with 20000 reloads and 15000 <div>Debug</
div> with another panels selected. I have created 6 new profiles for
this test and started them in seperate processes. The tests will need
a long time (maybe a day or longer) and if they are finished I will
post the results here.
John J Barton
On Jan 9, 1:47 am, Sworddragon <sworddrag...@aol.com> wrote:
> On 9 Jan., 02:11, John J Barton <johnjbar...@johnjbarton.com> wrote:
...
> I have added more HTML elements. 15000 <div>Debug</div> and the memory
> usage was increasing after 1000 reloads to ~70 MB (the previous tests
> without this additional HTML content was using just ~55-60 MB.
Firebug does not directly store information in proportion to the
number of HTML elements. The HTML panel is created incrementally based
on which elements the user has explored.
Firebug does track changes to HTML via DOM Mutation events. This
begins after the 'load' event. So you might try inserting elements in
the onload handler. If the extra memory scaled with the number of
mutation events then we'd be on to something. Might try attributes
also.
The only other way I can imagine that Firebug memory would scale with
HTML content would be if the window object itself is not being deleted
by Firefox because Firebug holds at reference to it somewhere.
jjb
Sworddragon
with every panel selected are finished. Here are the results:
Console: 202 MB
HTML: 208 MB
CSS: 197 MB
Script: 208 MB
DOM: 205 MB
Network: 180 MB
It seems that the amount of HTML content isn't the reason but I'm
wondering why the memory usage was inceased by only 1000 reloads.
After the 6 tests i have made 2 tests with manipulating the DOM. One
test with a call from the onload attribute of the body tag and the
other test with a call in the javascript code. At these tests i have
made 1000 nested DOM operations with attribute manipulation per
reload. After this tests the memory usage was 182 MB with a call from
the onload attribute and 190 MB with a call in the javascript code.
This memory leak isn't easy to analyze but do you have any other
suggestions?
John J Barton
First I suggest you double check that your current test 'scales' with
the number of reloads, meaning 500 reloads gives half as much increase
as 1000. Also double check the impact of disabling Console panel.
If it does scale, then here are some suggestions:
1) Add an unload event handler to the page. Does not have to do
anything in particular, it will just cause the page to be handled
differently.
2) Include some large JS library. (I tried this but did not see any
effect).
3) Add some AJAX requests to exercise the net traffic components.
jjb
Steven Roussey
> HTML content would be if the window object itself is not being deleted
> by Firefox because Firebug holds at reference to it somewhere.
Is there a way to figure this out?
Something like telling the GC to flush itself a couple of times and
see how many windows are still around?
I happen to see this memory increase thing, and the long pause issue
where Firefox will hang for a couple of seconds before I see what I
was typing or scrolling starts to work. At that point I know I should
restart Firefox. ;) Unfortunately, I can get to this point several
times a day, not once every several days.
Also, on a tangent, the jetpack project had a module to count memory
references (it needed a c++ module to do so), and it was broken out
into a separate add-on for Firefox 3.5 (no 3.6 yet):
https://addons.mozilla.org/en-US/firefox/addon/14666
https://wiki.mozilla.org/Labs/Memory_Profiler
http://hg.mozilla.org/users/avarma_mozilla.com/memory-profiler/
I'm curious if Firebug or Chromebug could repurpose it for its own
needs...
John J Barton
On Jan 11, 11:50 am, Steven Roussey <srous...@gmail.com> wrote:
> > The only other way I can imagine that Firebug memory would scale with
> > HTML content would be if the window object itself is not being deleted
> > by Firefox because Firebug holds at reference to it somewhere.
>
> Is there a way to figure this out?
>
> Something like telling the GC to flush itself a couple of times and
> see how many windows are still around?
How can we enumerate the windows in any other way than the ones we
already use? We don't see any extras...
>
> I happen to see this memory increase thing, and the long pause issue
> where Firefox will hang for a couple of seconds before I see what I
> was typing or scrolling starts to work. At that point I know I should
> restart Firefox. ;) Unfortunately, I can get to this point several
> times a day, not once every several days.
>
> Also, on a tangent, the jetpack project had a module to count memory
> references (it needed a c++ module to do so), and it was broken out
> into a separate add-on for Firefox 3.5 (no 3.6 yet):https://addons.mozilla.org/en-US/firefox/addon/14666https://wiki.mozilla.org/Labs/Memory_Profilerhttp://hg.mozilla.org/users/avarma_mozilla.com/memory-profiler/
>
> I'm curious if Firebug or Chromebug could repurpose it for its own
> needs...
I don't know how that tool assigns memory to windows. This is one of
the problems it should be good at solving.
jjb
Steven Roussey
> already use? We don't see any extras...
I was wondering if there was a low-level routine that would return all
objects subject to GC, then iterate through them all and see how many
were windows. There would be no way to use a high level API as it
would obviously have marked those windows as gone. But gone and
actually garbage collected are different things. I have no idea if
there is such a low level API available.
-steve--
John J Barton
Sure there is, in the garbage collector. I think that the jetpack
memory analyzer does just as you suggest: walks the collector's heap
and tries to sort out the stuff.
>
> -steve--
Steven Roussey
> Otherwise the procedure is not practical.
This is not a test to exercise a specific area that would let us know
where a bug is, if there is one, but instead a 5 minute test that we
might be able to use for our purposes of narrowing down to a specific
panel, etc:
http://service.futuremark.com/peacekeeper/run.action (5 min)
Other benchmark sites might also be of use, though some can take a
long time like moz dromaeo at 35minutes. Though in that case, subsets
could be done (like DOM only).
http://v8.googlecode.com/svn/data/benchmarks/v5/run.html (about 1
min)
http://dromaeo.com/?all (35 min)
http://dromaeo.com/?dom (2 min)
http://dromaeo.com/?jslib (5 min)
http://www2.webkit.org/perf/sunspider-0.9/sunspider-driver.html (???)
-steve--
John J Barton
Ok, but what to do with these ? Sworddragon and I both created tests
and reported results, but we don't get the same results.
jjb
Sworddragon
> and reported results, but we don't get the same results.
I thought you haven't run at any time a test with 20000 reloads? Just
try it one time and don't see the test as a analyze but as a
demonstration of the existence of the memory leak.