Malard
2007-Feb-14 11:34 UTC
Memory Leak in Firefox + Script.aculo.us 1.7.0 using Morph Effects (solution included)
Hi all,
I have noticed that the new morph functions of script.aculo.us are
causing a severe memory leak in firefox if used for a sustained
period, f.ex my application of it was using it to dynamically change
the length of a div and the colour of that div, for a web based
overview of load balancing on several computers.
What was happening that after about a day, firefox would consume
around 2gb of memory. After some careful investigation it seems that
the morph effects were leaking the memory.
In the ''setup'' function in Effects.Morph starting line 981
} else if(Element.CSS_LENGTH.test(value))
var components = value.match(/^([\+\-]?[0-9\.]+)(.*)$/),
value = parseFloat(components[1]), unit = (components.length
== 3) ? components[2] : null;
This function already is already declaring value and unit on line 972,
it seems there is either a bug in the Javascript engine in gecko or
the garbage collection as the values being reassigned on the
concatonated var statement on line 982 are the only cause of the
memory leak.
Modifying these lines to the following:
} else if(Element.CSS_LENGTH.test(value)) {
var components = value.match(/^([\+\-]?[0-9\.]+)(.*)$/);
value = parseFloat(components[1]);
unit = (components.length == 3) ? components[2] : null;
}
Resolves the issue entirely. Can other people verify and possibly
direct me to how i can add this to the library proper.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---
Thomas Fuchs
2007-Feb-14 12:57 UTC
Re: Memory Leak in Firefox + Script.aculo.us 1.7.0 using Morph Effects (solution included)
thanks for reporting this. here are some pointers for submitting a patch: http://wiki.script.aculo.us/scriptaculous/show/Development see also this page on Prototype (more or less the same for script.aculo.us): http://prototypejs.org/contribute Best, Thomas Am 14.02.2007 um 12:34 schrieb Malard:> > Hi all, > > I have noticed that the new morph functions of script.aculo.us are > causing a severe memory leak in firefox if used for a sustained > period, f.ex my application of it was using it to dynamically change > the length of a div and the colour of that div, for a web based > overview of load balancing on several computers. > > What was happening that after about a day, firefox would consume > around 2gb of memory. After some careful investigation it seems that > the morph effects were leaking the memory. > > In the ''setup'' function in Effects.Morph starting line 981 > > } else if(Element.CSS_LENGTH.test(value)) > var components = value.match(/^([\+\-]?[0-9\.]+)(.*)$/), > value = parseFloat(components[1]), unit = (components.length > == 3) ? components[2] : null; > > > This function already is already declaring value and unit on line 972, > it seems there is either a bug in the Javascript engine in gecko or > the garbage collection as the values being reassigned on the > concatonated var statement on line 982 are the only cause of the > memory leak. > > Modifying these lines to the following: > > } else if(Element.CSS_LENGTH.test(value)) { > var components = value.match(/^([\+\-]?[0-9\.]+)(.*)$/); > value = parseFloat(components[1]); > unit = (components.length == 3) ? components[2] : null; > } > > Resolves the issue entirely. Can other people verify and possibly > direct me to how i can add this to the library proper. > > > >-- Thomas Fuchs wollzelle http://www.wollzelle.com questentier on AIM madrobby on irc.freenode.net http://www.fluxiom.com :: online digital asset management http://script.aculo.us :: Web 2.0 JavaScript http://mir.aculo.us :: Where no web developer has gone before --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
Colin Mollenhour
2007-Feb-14 18:49 UTC
Re: Memory Leak in Firefox + Script.aculo.us 1.7.0 using Morph Effects (solution included)
Good work, I am *very* curious as to how you were able to track this down as a memory leak? My Firefox will creep up to >250Mb memory rather quickly and although I am pretty sure I don''t redeclare variables as is the problem in this case, I''d like to learn more about tracking down these obscure memory leaks nonetheless. Thanks, Colin Malard wrote:> Hi all, > > I have noticed that the new morph functions of script.aculo.us are > causing a severe memory leak in firefox if used for a sustained > period, f.ex my application of it was using it to dynamically change > the length of a div and the colour of that div, for a web based > overview of load balancing on several computers. > > What was happening that after about a day, firefox would consume > around 2gb of memory. After some careful investigation it seems that > the morph effects were leaking the memory. > > In the ''setup'' function in Effects.Morph starting line 981 > > } else if(Element.CSS_LENGTH.test(value)) > var components = value.match(/^([\+\-]?[0-9\.]+)(.*)$/), > value = parseFloat(components[1]), unit = (components.length > == 3) ? components[2] : null; > > > This function already is already declaring value and unit on line 972, > it seems there is either a bug in the Javascript engine in gecko or > the garbage collection as the values being reassigned on the > concatonated var statement on line 982 are the only cause of the > memory leak. > > Modifying these lines to the following: > > } else if(Element.CSS_LENGTH.test(value)) { > var components = value.match(/^([\+\-]?[0-9\.]+)(.*)$/); > value = parseFloat(components[1]); > unit = (components.length == 3) ? components[2] : null; > } > > Resolves the issue entirely. Can other people verify and possibly > direct me to how i can add this to the library proper. > > > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
Malard
2007-Feb-14 19:17 UTC
Re: Memory Leak in Firefox + Script.aculo.us 1.7.0 using Morph Effects (solution included)
I used a combination of things to isolate it, first i tried using a
tool from Software Verify. That really did''nt help much. Although it
did track down an issue with prototype which i''m still looking into.
Basically my code did something like this
create a div element, apply some style (including a width)
div element.morph({width: n%}); where n is the new value i wanted.
Had an ajax request getting the new width from the server and then
calling this routine every 200ms
Let this run for a while and found it was gaining memory.
Then tried all of the above, except instead of div element.morph, i
used setStyle, no memory loss.
This gave me the evidence i needed to blame the morph function. Once i
had that i started looking into what the function was doing, breaking
down the various aspects of the function. Somewhat trial and error, i
looked at what the setup function was doing and quickly realised what
each bit was doing, i knew i was modifying the width of values so i
looked at how that was working. I develop in the Aptana IDE and turned
on warnings mode, which uses JSLint to find possible issues. The first
thing it mentioned was that var was missing a preceding { for the
function, then it mentioned that value and unit had already been
defined.
I think by chance i caught it, when i changed the code and ran it, the
memory leak was gone.
I wrote a small test case which is here: http://pastebin.mozilla.org/3901
to replicate the problem in the future, i think its a bug with
firefox, but really dont have time to persue it, i cant imagine EVER
writing a function that compressed ;)
One bit of advice i could offer, is try and isolate which bits are
causing the problem, so if you know you''ve got a leak, comment out all
of your code and run the page again, if the leak is still happening
then look further afield, if its not, then introduce a small portion
of the code back in, and retry until you eventually isolate which bits
of the code are causing it, then isolate these and run them on their
own and just keep working like that until you can track it down. Thats
all i do :)
On Feb 14, 6:49 pm, Colin Mollenhour
<eliteii...-NPSFNn/7+NYVo650/ln6uw@public.gmane.org>
wrote:> Good work, I am *very* curious as to how you were able to track this
> down as a memory leak? My Firefox will creep up to >250Mb memory rather
> quickly and although I am pretty sure I don''t redeclare variables
as is
> the problem in this case, I''d like to learn more about tracking
down
> these obscure memory leaks nonetheless.
>
> Thanks,
> Colin
>
> Malard wrote:
> > Hi all,
>
> > I have noticed that the new morph functions of script.aculo.us are
> > causing a severe memory leak in firefox if used for a sustained
> > period, f.ex my application of it was using it to dynamically change
> > the length of a div and the colour of that div, for a web based
> > overview of load balancing on several computers.
>
> > What was happening that after about a day, firefox would consume
> > around 2gb of memory. After some careful investigation it seems that
> > the morph effects were leaking the memory.
>
> > In the ''setup'' function in Effects.Morph starting
line 981
>
> > } else if(Element.CSS_LENGTH.test(value))
> > var components = value.match(/^([\+\-]?[0-9\.]+)(.*)$/),
> > value = parseFloat(components[1]), unit = (components.length
> > == 3) ? components[2] : null;
>
> > This function already is already declaring value and unit on line 972,
> > it seems there is either a bug in the Javascript engine in gecko or
> > the garbage collection as the values being reassigned on the
> > concatonated var statement on line 982 are the only cause of the
> > memory leak.
>
> > Modifying these lines to the following:
>
> > } else if(Element.CSS_LENGTH.test(value)) {
> > var components = value.match(/^([\+\-]?[0-9\.]+)(.*)$/);
> > value = parseFloat(components[1]);
> > unit = (components.length == 3) ? components[2] : null;
> > }
>
> > Resolves the issue entirely. Can other people verify and possibly
> > direct me to how i can add this to the library proper.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---
Colin Mollenhour
2007-Feb-14 19:35 UTC
Re: Memory Leak in Firefox + Script.aculo.us 1.7.0 using Morph Effects (solution included)
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
So the short answer is trial and error + process of elimination. Damn,
I was hoping there was a magical solution. :)<br>
I might look into switching to Aptana if it has JSLint built in. I used
Eclipse exclusively when doing Java but haven''t tried it on PHP and
Javascript for a long time, I guess the tools have matured quite a bit
by now.<br>
<br>
Are the Prototype and SAU devs interested in making these libraries
JSLint validated? I know it would take a lot of work on the front end
and it doesn''t like some of the uber-cool code shortcuts that we all
like to use, but once they''re validated, I think it can help to avoid
these types of issues in the future and keeping it validated would be
very easy. I made all of my own libraries JSLint validated and it took
only a few hours using the extremely tedious online validator
copy/paste method...<br>
<br>
Does Aptana highlight JSLint problems real-time like Eclipse does for
Java compiler warnings/errors? That would make the process quite
painless.<br>
<br>
Thanks,<br>
Colin<br>
<br>
Malard wrote:
<blockquote
cite="mid:1171480632.738893.237360-yYlG0QQ1yY1E5r1IWk559WB/v6IoIuQBVpNB7YpNyf8@public.gmane.org"
type="cite">
<pre wrap="">I used a combination of things to isolate it,
first i tried using a
tool from Software Verify. That really did''nt help much. Although it
did track down an issue with prototype which i''m still looking into.
Basically my code did something like this
create a div element, apply some style (including a width)
div element.morph({width: n%}); where n is the new value i wanted.
Had an ajax request getting the new width from the server and then
calling this routine every 200ms
Let this run for a while and found it was gaining memory.
Then tried all of the above, except instead of div element.morph, i
used setStyle, no memory loss.
This gave me the evidence i needed to blame the morph function. Once i
had that i started looking into what the function was doing, breaking
down the various aspects of the function. Somewhat trial and error, i
looked at what the setup function was doing and quickly realised what
each bit was doing, i knew i was modifying the width of values so i
looked at how that was working. I develop in the Aptana IDE and turned
on warnings mode, which uses JSLint to find possible issues. The first
thing it mentioned was that var was missing a preceding { for the
function, then it mentioned that value and unit had already been
defined.
I think by chance i caught it, when i changed the code and ran it, the
memory leak was gone.
I wrote a small test case which is here: <a
class="moz-txt-link-freetext"
href="http://pastebin.mozilla.org/3901">http://pastebin.mozilla.org/3901</a>
to replicate the problem in the future, i think its a bug with
firefox, but really dont have time to persue it, i cant imagine EVER
writing a function that compressed ;)
One bit of advice i could offer, is try and isolate which bits are
causing the problem, so if you know you''ve got a leak, comment out all
of your code and run the page again, if the leak is still happening
then look further afield, if its not, then introduce a small portion
of the code back in, and retry until you eventually isolate which bits
of the code are causing it, then isolate these and run them on their
own and just keep working like that until you can track it down. Thats
all i do :)
On Feb 14, 6:49 pm, Colin Mollenhour <a
class="moz-txt-link-rfc2396E"
href="mailto:eliteii...-NPSFNn/7+NYVo650/ln6uw@public.gmane.org"><eliteii...-NPSFNn/7+NYVo650/ln6uw@public.gmane.org></a>
wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Good work, I am *very* curious as to how you
were able to track this
down as a memory leak? My Firefox will creep up to >250Mb memory rather
quickly and although I am pretty sure I don''t redeclare variables as is
the problem in this case, I''d like to learn more about tracking down
these obscure memory leaks nonetheless.
Thanks,
Colin
Malard wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi all,
</pre>
</blockquote>
<blockquote type="cite">
<pre wrap="">I have noticed that the new morph functions
of script.aculo.us are
causing a severe memory leak in firefox if used for a sustained
period, f.ex my application of it was using it to dynamically change
the length of a div and the colour of that div, for a web based
overview of load balancing on several computers.
</pre>
</blockquote>
<blockquote type="cite">
<pre wrap="">What was happening that after about a day,
firefox would consume
around 2gb of memory. After some careful investigation it seems that
the morph effects were leaking the memory.
</pre>
</blockquote>
<blockquote type="cite">
<pre wrap="">In the ''setup'' function in
Effects.Morph starting line 981
</pre>
</blockquote>
<blockquote type="cite">
<pre wrap=""> } else
if(Element.CSS_LENGTH.test(value))
var components = value.match(/^([\+\-]?[0-9\.]+)(.*)$/),
value = parseFloat(components[1]), unit = (components.length
== 3) ? components[2] : null;
</pre>
</blockquote>
<blockquote type="cite">
<pre wrap="">This function already is already declaring
value and unit on line 972,
it seems there is either a bug in the Javascript engine in gecko or
the garbage collection as the values being reassigned on the
concatonated var statement on line 982 are the only cause of the
memory leak.
</pre>
</blockquote>
<blockquote type="cite">
<pre wrap="">Modifying these lines to the following:
</pre>
</blockquote>
<blockquote type="cite">
<pre wrap=""> } else
if(Element.CSS_LENGTH.test(value)) {
var components = value.match(/^([\+\-]?[0-9\.]+)(.*)$/);
value = parseFloat(components[1]);
unit = (components.length == 3) ? components[2] : null;
}
</pre>
</blockquote>
<blockquote type="cite">
<pre wrap="">Resolves the issue entirely. Can other people
verify and possibly
direct me to how i can add this to the library proper.
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
<br>
--~--~---------~--~----~------------~-------~--~----~<br>
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group. <br> To post to this
group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org <br> To
unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
<br> For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en <br>
-~----------~----~----~----~------~----~------~--~---<br>
</body>
</html>
<br>
Martin Ellis
2007-Feb-14 19:49 UTC
Re: Memory Leak in Firefox + Script.aculo.us 1.7.0 using Morph Effects (solution included)
Yes it does, its just a toggle switch in the top menu, Aptana is compiled against Eclipse 3.1 although it works in 3.2 i recommend having a standalone copy of Aptana instead of trying to mix all the different perspectives into one as there are some known conflicts. While yes in this case it was trial and error i was using the memory validator to help me isolate where the fault was, its a great tool and can quickly help not only profile the application but spot where the most resources are being spent from a memory stand point. On 2/14/07, Colin Mollenhour <eliteii92g-NPSFNn/7+NYVo650/ln6uw@public.gmane.org> wrote:> > So the short answer is trial and error + process of elimination. Damn, I > was hoping there was a magical solution. :) > I might look into switching to Aptana if it has JSLint built in. I used > Eclipse exclusively when doing Java but haven''t tried it on PHP and > Javascript for a long time, I guess the tools have matured quite a bit by > now. > > Are the Prototype and SAU devs interested in making these libraries JSLint > validated? I know it would take a lot of work on the front end and it > doesn''t like some of the uber-cool code shortcuts that we all like to use, > but once they''re validated, I think it can help to avoid these types of > issues in the future and keeping it validated would be very easy. I made > all of my own libraries JSLint validated and it took only a few hours using > the extremely tedious online validator copy/paste method... > > Does Aptana highlight JSLint problems real-time like Eclipse does for Java > compiler warnings/errors? That would make the process quite painless. > > Thanks, > Colin > > > Malard wrote: > I used a combination of things to isolate it, first i tried using a > tool from Software Verify. That really did''nt help much. Although it > did track down an issue with prototype which i''m still looking into. > > Basically my code did something like this > > create a div element, apply some style (including a width) > > div element.morph({width: n%}); where n is the new value i wanted. > > Had an ajax request getting the new width from the server and then > calling this routine every 200ms > > Let this run for a while and found it was gaining memory. > > Then tried all of the above, except instead of div element.morph, i > used setStyle, no memory loss. > > This gave me the evidence i needed to blame the morph function. Once i > had that i started looking into what the function was doing, breaking > down the various aspects of the function. Somewhat trial and error, i > looked at what the setup function was doing and quickly realised what > each bit was doing, i knew i was modifying the width of values so i > looked at how that was working. I develop in the Aptana IDE and turned > on warnings mode, which uses JSLint to find possible issues. The first > thing it mentioned was that var was missing a preceding { for the > function, then it mentioned that value and unit had already been > defined. > > I think by chance i caught it, when i changed the code and ran it, the > memory leak was gone. > > I wrote a small test case which is here: > http://pastebin.mozilla.org/3901 > to replicate the problem in the future, i think its a bug with > firefox, but really dont have time to persue it, i cant imagine EVER > writing a function that compressed ;) > > One bit of advice i could offer, is try and isolate which bits are > causing the problem, so if you know you''ve got a leak, comment out all > of your code and run the page again, if the leak is still happening > then look further afield, if its not, then introduce a small portion > of the code back in, and retry until you eventually isolate which bits > of the code are causing it, then isolate these and run them on their > own and just keep working like that until you can track it down. Thats > all i do :) > > > On Feb 14, 6:49 pm, Colin Mollenhour <eliteii...-NPSFNn/7+NYVo650/ln6uw@public.gmane.org> > wrote: > > > Good work, I am *very* curious as to how you were able to track this > down as a memory leak? My Firefox will creep up to >250Mb memory rather > quickly and although I am pretty sure I don''t redeclare variables as is > the problem in this case, I''d like to learn more about tracking down > these obscure memory leaks nonetheless. > > Thanks, > Colin > > Malard wrote: > > > Hi all, > > > I have noticed that the new morph functions of script.aculo.us are > causing a severe memory leak in firefox if used for a sustained > period, f.ex my application of it was using it to dynamically change > the length of a div and the colour of that div, for a web based > overview of load balancing on several computers. > > > What was happening that after about a day, firefox would consume > around 2gb of memory. After some careful investigation it seems that > the morph effects were leaking the memory. > > > In the ''setup'' function in Effects.Morph starting line 981 > > > } else if(Element.CSS_LENGTH.test(value)) > var components = value.match(/^([\+\-]?[0-9\.]+)(.*)$/), > value = parseFloat(components[1]), unit = (components.length > == 3) ? components[2] : null; > > > This function already is already declaring value and unit on line 972, > it seems there is either a bug in the Javascript engine in gecko or > the garbage collection as the values being reassigned on the > concatonated var statement on line 982 are the only cause of the > memory leak. > > > Modifying these lines to the following: > > > } else if(Element.CSS_LENGTH.test(value)) { > var components = value.match(/^([\+\-]?[0-9\.]+)(.*)$/); > value = parseFloat(components[1]); > unit = (components.length == 3) ? components[2] : null; > } > > > Resolves the issue entirely. Can other people verify and possibly > direct me to how i can add this to the library proper. > > > > > > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
Ryan Gahl
2007-Feb-15 14:11 UTC
Re: Memory Leak in Firefox + Script.aculo.us 1.7.0 using Morph Effects (solution included)
Sorry, OT... but Aptana rocks :-) Anyone not using it for their heavy js development is missing some serious bennies. Just throwing in my bits, not too helpful to this discussion, I know... On 2/14/07, Martin Ellis <malard-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > > Yes it does, its just a toggle switch in the top menu, Aptana is > compiled against Eclipse 3.1 although it works in 3.2 i recommend > having a standalone copy of Aptana instead of trying to mix all the > different perspectives into one as there are some known conflicts. > > While yes in this case it was trial and error i was using the memory > validator to help me isolate where the fault was, its a great tool and > can quickly help not only profile the application but spot where the > most resources are being spent from a memory stand point. > > On 2/14/07, Colin Mollenhour <eliteii92g-NPSFNn/7+NYVo650/ln6uw@public.gmane.org> wrote: > > > > So the short answer is trial and error + process of elimination. Damn, > I > > was hoping there was a magical solution. :) > > I might look into switching to Aptana if it has JSLint built in. I used > > Eclipse exclusively when doing Java but haven''t tried it on PHP and > > Javascript for a long time, I guess the tools have matured quite a bit > by > > now. > > > > Are the Prototype and SAU devs interested in making these libraries > JSLint > > validated? I know it would take a lot of work on the front end and it > > doesn''t like some of the uber-cool code shortcuts that we all like to > use, > > but once they''re validated, I think it can help to avoid these types of > > issues in the future and keeping it validated would be very easy. I > made > > all of my own libraries JSLint validated and it took only a few hours > using > > the extremely tedious online validator copy/paste method... > > > > Does Aptana highlight JSLint problems real-time like Eclipse does for > Java > > compiler warnings/errors? That would make the process quite painless. > > > > Thanks, > > Colin > > > > > > Malard wrote: > > I used a combination of things to isolate it, first i tried using a > > tool from Software Verify. That really did''nt help much. Although it > > did track down an issue with prototype which i''m still looking into. > > > > Basically my code did something like this > > > > create a div element, apply some style (including a width) > > > > div element.morph({width: n%}); where n is the new value i wanted. > > > > Had an ajax request getting the new width from the server and then > > calling this routine every 200ms > > > > Let this run for a while and found it was gaining memory. > > > > Then tried all of the above, except instead of div element.morph, i > > used setStyle, no memory loss. > > > > This gave me the evidence i needed to blame the morph function. Once i > > had that i started looking into what the function was doing, breaking > > down the various aspects of the function. Somewhat trial and error, i > > looked at what the setup function was doing and quickly realised what > > each bit was doing, i knew i was modifying the width of values so i > > looked at how that was working. I develop in the Aptana IDE and turned > > on warnings mode, which uses JSLint to find possible issues. The first > > thing it mentioned was that var was missing a preceding { for the > > function, then it mentioned that value and unit had already been > > defined. > > > > I think by chance i caught it, when i changed the code and ran it, the > > memory leak was gone. > > > > I wrote a small test case which is here: > > http://pastebin.mozilla.org/3901 > > to replicate the problem in the future, i think its a bug with > > firefox, but really dont have time to persue it, i cant imagine EVER > > writing a function that compressed ;) > > > > One bit of advice i could offer, is try and isolate which bits are > > causing the problem, so if you know you''ve got a leak, comment out all > > of your code and run the page again, if the leak is still happening > > then look further afield, if its not, then introduce a small portion > > of the code back in, and retry until you eventually isolate which bits > > of the code are causing it, then isolate these and run them on their > > own and just keep working like that until you can track it down. Thats > > all i do :) > > > > > > On Feb 14, 6:49 pm, Colin Mollenhour <eliteii...-NPSFNn/7+NYVo650/ln6uw@public.gmane.org> > > wrote: > > > > > > Good work, I am *very* curious as to how you were able to track this > > down as a memory leak? My Firefox will creep up to >250Mb memory rather > > quickly and although I am pretty sure I don''t redeclare variables as is > > the problem in this case, I''d like to learn more about tracking down > > these obscure memory leaks nonetheless. > > > > Thanks, > > Colin > > > > Malard wrote: > > > > > > Hi all, > > > > > > I have noticed that the new morph functions of script.aculo.us are > > causing a severe memory leak in firefox if used for a sustained > > period, f.ex my application of it was using it to dynamically change > > the length of a div and the colour of that div, for a web based > > overview of load balancing on several computers. > > > > > > What was happening that after about a day, firefox would consume > > around 2gb of memory. After some careful investigation it seems that > > the morph effects were leaking the memory. > > > > > > In the ''setup'' function in Effects.Morph starting line 981 > > > > > > } else if(Element.CSS_LENGTH.test(value)) > > var components = value.match(/^([\+\-]?[0-9\.]+)(.*)$/), > > value = parseFloat(components[1]), unit = (components.length > > == 3) ? components[2] : null; > > > > > > This function already is already declaring value and unit on line 972, > > it seems there is either a bug in the Javascript engine in gecko or > > the garbage collection as the values being reassigned on the > > concatonated var statement on line 982 are the only cause of the > > memory leak. > > > > > > Modifying these lines to the following: > > > > > > } else if(Element.CSS_LENGTH.test(value)) { > > var components = value.match(/^([\+\-]?[0-9\.]+)(.*)$/); > > value = parseFloat(components[1]); > > unit = (components.length == 3) ? components[2] : null; > > } > > > > > > Resolves the issue entirely. Can other people verify and possibly > > direct me to how i can add this to the library proper. > > > > > > > > > > > > > > > > > > > > >-- Ryan Gahl Application Development Consultant Athena Group, Inc. Inquire: 1-920-955-1457 Blog: http://www.someElement.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---