Huge Memory Leak if you use JavaScript in IE4
| Author |
Message |
|
Electru
#1 / 9
|
 Huge Memory Leak if you use JavaScript in IE4 Incredible! The following 5-line HTML file will cause IE4.01/SP1 (on NT4/SP3) to leak about 50-100K of virtual memory every time! <html>
<body>
<script></script>
</body>
</html>
Even if you just open the page and hit 'refresh' a few times, you can see
the memory usage going up at an alarming rate. (Use the NT task manager, and
look at the 'Mem Usage' panel).
Sooner or later, you'll run out of virtual memory, and get the dreaded
'System Process - Out of Virtual Memory' dialog, telling you to close one or
more programs. That's if your machine doesn't crash, of course.
This behaviour seems to affect ANY page which has ANY JavaScript in it (as
the above HTML fragment does by default, since it doesn't explicitly set
the 'language' attribute for the script).
I find it somewhat sinister that if I add "language='VBScript'" to the
script tag, the problem goes away. Is this Microsoft's idea of how to make
VBScript more popular than JavaScript?
|
| Sat, 26 May 2001 03:00:00 GMT |
|
 |
|
Microsoft Scripting D
#2 / 9
|
Huge Memory Leak if you use JavaScript in IE4 Hi there, I'm totally unable to reproduce that alleged leak. What if you take a look
at the PERFMON private bytes counter for the IE process? Do you see a leak
there as well? How big?
As for the "Is this Microsoft's idea of how to makeVBScript more popular
than JavaScript?" comment -- I'm assuming that this is a joke, but on the
off chance that it isn't:
As the guy who helped write both the VBScript and JScript engine, let me
tell you that Microsoft does not have any sinister plan to make VBScript
more popular than JScript or vice versa. I get asked this all the time.
"The examples for product Blah are all in JScript, does this mean that
Microsoft is deprecating VBScript?" "JScript has lousy error handling, does
this mean that Microsoft is deprecating JScript", etc, etc, etc.
One of my goals is to make JScript and VBScript have similar enough feature
sets so that script authors can use whatever language they feel more
comfortable with. That's why for version 5, we've added error handling to
JScript, and classes, the "with" statement, regular expressions, and "eval"
to VBScript. Microsoft is committed to working with the ECMA committee to
move the script standard forward and provide the best implementation of that
standard. We are also obviously hugely committed to the Visual Basic family
of languages, given the huge number of VB programmers in the industry today.
We want both languages to succeed. Furthermore, the Active Scripting
interfaces are a public interface -- we want third parties to write
languages like Perl, Python, Haskell, etc as scripting languages. (Unlike,
say, Netscape, who wants you to use only their language on your web pages.
:-) )
Eric
Quote: >Incredible! The following 5-line HTML file will cause IE4.01/SP1 (on >NT4/SP3) to leak about 50-100K of virtual memory every time! ><html>
><body>
><script></script>
></body>
></html>
>Even if you just open the page and hit 'refresh' a few times, you can see
>the memory usage going up at an alarming rate. (Use the NT task manager,
and
>look at the 'Mem Usage' panel).
>Sooner or later, you'll run out of virtual memory, and get the dreaded
>'System Process - Out of Virtual Memory' dialog, telling you to close one
or
>more programs. That's if your machine doesn't crash, of course.
>This behaviour seems to affect ANY page which has ANY JavaScript in it (as
>the above HTML fragment does by default, since it doesn't explicitly set
>the 'language' attribute for the script).
>I find it somewhat sinister that if I add "language='VBScript'" to the
>script tag, the problem goes away. Is this Microsoft's idea of how to make
>VBScript more popular than JavaScript?
|
| Sun, 27 May 2001 03:00:00 GMT |
|
|
|
Keith Chadwic
#3 / 9
|
Huge Memory Leak if you use JavaScript in IE4 Well Said Eric, I agree whole heartedly Keith Chadwikc
Quote: >Hi there, >I'm totally unable to reproduce that alleged leak. What if you take a look
>at the PERFMON private bytes counter for the IE process? Do you see a leak
>there as well? How big?
>As for the "Is this Microsoft's idea of how to makeVBScript more popular
>than JavaScript?" comment -- I'm assuming that this is a joke, but on the
>off chance that it isn't:
>As the guy who helped write both the VBScript and JScript engine, let me
>tell you that Microsoft does not have any sinister plan to make VBScript
>more popular than JScript or vice versa. I get asked this all the time.
>"The examples for product Blah are all in JScript, does this mean that
>Microsoft is deprecating VBScript?" "JScript has lousy error handling,
does
>this mean that Microsoft is deprecating JScript", etc, etc, etc.
>One of my goals is to make JScript and VBScript have similar enough feature
>sets so that script authors can use whatever language they feel more
>comfortable with. That's why for version 5, we've added error handling to
>JScript, and classes, the "with" statement, regular expressions, and "eval"
>to VBScript. Microsoft is committed to working with the ECMA committee to
>move the script standard forward and provide the best implementation of
that
>standard. We are also obviously hugely committed to the Visual Basic
family
>of languages, given the huge number of VB programmers in the industry
today.
>We want both languages to succeed. Furthermore, the Active Scripting
>interfaces are a public interface -- we want third parties to write
>languages like Perl, Python, Haskell, etc as scripting languages. (Unlike,
>say, Netscape, who wants you to use only their language on your web pages.
>:-) )
>Eric
>>Incredible! The following 5-line HTML file will cause IE4.01/SP1 (on
>>NT4/SP3) to leak about 50-100K of virtual memory every time!
>><html>
>><body>
>><script></script>
>></body>
>></html>
>>Even if you just open the page and hit 'refresh' a few times, you can see
>>the memory usage going up at an alarming rate. (Use the NT task manager,
>and
>>look at the 'Mem Usage' panel).
>>Sooner or later, you'll run out of virtual memory, and get the dreaded
>>'System Process - Out of Virtual Memory' dialog, telling you to close one
>or
>>more programs. That's if your machine doesn't crash, of course.
>>This behaviour seems to affect ANY page which has ANY JavaScript in it (as
>>the above HTML fragment does by default, since it doesn't explicitly set
>>the 'language' attribute for the script).
>>I find it somewhat sinister that if I add "language='VBScript'" to the
>>script tag, the problem goes away. Is this Microsoft's idea of how to make
>>VBScript more popular than JavaScript?
|
| Sun, 27 May 2001 03:00:00 GMT |
|
|
|
Electru
#4 / 9
|
Huge Memory Leak if you use JavaScript in IE4 Quote:
>>Incredible! The following 5-line HTML file will cause IE4.01/SP1 (on >>NT4/SP3) to leak about 50-100K of virtual memory every time! >><html>
>><body>
>><script></script>
>></body>
>></html>
>>Even if you just open the page and hit 'refresh' a few times, you can see
>>the memory usage going up at an alarming rate. (Use the NT task
>>manager, and look at the 'Mem Usage' panel).
>>Sooner or later, you'll run out of virtual memory, and get the dreaded
>>'System Process - Out of Virtual Memory' dialog, telling you to close
>>one or more programs. That's if your machine doesn't crash, of course.
>>This behaviour seems to affect ANY page which has ANY JavaScript in it (as
>>the above HTML fragment does by default, since it doesn't explicitly set
>>the 'language' attribute for the script).
>>I find it somewhat sinister that if I add "language='VBScript'" to the
>>script tag, the problem goes away. Is this Microsoft's idea of how to make
>>VBScript more popular than JavaScript?
...and you replied: Quote: >I'm totally unable to reproduce that alleged leak. What if you take a look
>at the PERFMON private bytes counter for the IE process? Do you see a leak
>there as well? How big?
I'm not entirely surprised that you can't reproduce it, because I was frankly stunned that anyone* would release a product with such a huge (and obvious) bug in it. I'm also glad you can't reproduce it, because that means that there is a configuration out there that doesn't suffer from the problem (perhaps all configs except mine?), and so I may be able to get my client off my back without having to re-write everything in VBScript. [ * anyone that is with the possible exception of Netscape, whose browser
seems to have more bugs than a dead rat ]
But I can assure you that it happens on all machines I've tried it on (which
all have the same config, which I'll detail in a minute). But first, just in
case you misunderstood, I'm talking about a leakage of virtual memory, not
physical memory. So, the figure I'm looking at is the 'Commit Charge (K)
Total' on the performance monitor tab of the NT Task Manager. The physical
memory figure doesn't seem to change much (or at least, not to the same
degree).
My configuration is NT4 (build 1381) with SP3, and IE4 version 4.72.3110.8,
with SP1. I'm in the UK, so I may or may not have international versions of
the above (I don't know how to tell). Also, I arrived at these versions via
the usual patches - I started off with some version of IE3, and have since
upgraded. I also have most of the developer tools on my machine, which also
seem to like replacing various DLLs.
One of the other machines I've tried it on exhibits exactly the same
behaviour, and since the machine is only a couple of months old, its
configuration has a better pedigree - it probably started off life with
NT4/SP3 and IE4, possibly without SP1 (though it has that now). However, it
also has some of the development tools.
STOP PRESS: I asked a friend at another company to try it out, and he can't
reproduce the problem even though his machine has a very similar
configuration to mine.
Here's a typical run, with a freshly-booted machine with nothing running
except the browser (and PWS, which is stopped):
The commit charge figure is at 43044 before I start the browser. I start the
browser with a blank page, and it jumps to 46820. When I drop the HTML file
on it, it jumps to 49704. When I hit refresh, it jumps to 49780, then 49844,
49892, 49960, 50012. So, it's gained about 300K after viewing the page 6
times.
If I wait for about a minute, the figure drops slightly, to 49936. But if I
hit refresh again, it jumps back to 50020, and after a minute only drops
back to 50004. In other words, there seems to be an element of memory
recovery, but it never regains nearly as much as it has lost (or at any
rate, not fast enough to stop it from running out of virtual memory
altogether).
You asked about the private bytes count for IE in the performance monitor. I
started IE on an http URL so that IEXPLORE showed up as a separate process,
and then loaded in my test file. The figure jumps around a bit, so I decided
to take each reading after I'd lost 1000K of virtual memory according to the
task manager. My readings (not on a 'fresh' machine this time, since I'd
been doing the other tests first) were 2183168, 2199552, 2203648, 2211840,
2220032. So, it goes steadily up, but (if my arithmetic serves me well) it
only goes up 10K for each 1000K of virtual memory loss.
I hope this is helpful. I'd be happy to run more tests for you if you like.
Quote: >As for the "Is this Microsoft's idea of how to makeVBScript more popular
>than JavaScript?" comment -- I'm assuming that this is a joke,
Well, kinda, but it did cross my mind :-) Quote: >but on the off chance that it isn't: >As the guy who helped write both the VBScript and JScript engine, let me >tell you that Microsoft does not have any sinister plan to make VBScript >more popular than JScript or vice versa. I get asked this all the time. >"The examples for product Blah are all in JScript, does this mean that >Microsoft is deprecating VBScript?" "JScript has lousy error handling, >does this mean that Microsoft is deprecating JScript", etc, etc, etc. >One of my goals is to make JScript and VBScript have similar enough feature
>sets so that script authors can use whatever language they feel more
>comfortable with. That's why for version 5, we've added error handling to
>JScript, and classes, the "with" statement, regular expressions, and "eval"
>to VBScript. Microsoft is committed to working with the ECMA committee to
>move the script standard forward and provide the best implementation of
>that standard. We are also obviously hugely committed to the Visual
>Basic family of languages, given the huge number of VB programmers
>in the industry today.
>We want both languages to succeed. Furthermore, the Active Scripting
>interfaces are a public interface -- we want third parties to write
>languages like Perl, Python, Haskell, etc as scripting languages. (Unlike,
>say, Netscape, who wants you to use only their language on your web pages.
>:-) )
OK, I applaud your efforts wholeheartedly. I should say that I insisted on using IE in my kiosk application despite the fact that my client had a strong preference for Netscape - in my experience IE just plain works better. But I'm sure you can imagine that my embarasment is consequently much greater when I have to admit to the client that his kiosk will stop working after a few hours - and that the problem is down to the browser I insisted on. (Now we're getting way off topic). From a web developer's point of view,
having lots of choice over what language to use in a particular browser
doesn't really help matters while there are other browsers out there that
don't support all of those languages. Unless you're in a closed-shop
situation (as I happen to be here with my kiosk app), you need your pages to
be viewable on as many browsers as possible, so you need to choose a
language which all browsers support. And that, currently, is JavaScript.
Anything that makes it less likely that the 'standard' language becomes less
standard or less ubiquitous is, in my opinion, a bad thing. This applies
just as much to HTML as it does to scripting languages, of course. Both
Microsoft and Netscape are guilty of polluting HTML with their own
non-standard tags, and of implementing certain parts of the standard
incorrectly. It is possible to move the standard forward without having
vendor-specific extensions, and my life would be a lot easier if it were
always done that way.
What's frustrating about JavaScript is that it's really hard to write a
script that works the same in all browsers - even different versions of the
same browser (Netscape included). If I had the ability to direct where
Netscape and Microsoft spent their time, I would have you both make sure
that your browsers implemented JavaScript exactly according to the spec
(which I'd write :-)) so that I could guarantee that a page which worked on
one browser also worked on the other. Having either of you implement another
language is *way* down my list of priorities.
Of course, having more than one client-side langauge means that anyone
trying to get into (or stay in) the browser market has a much bigger hurdle
to get over. Especially if one of those languages is proprietary, or subject
to change at the whim of their competitor... :-)
|
| Mon, 28 May 2001 03:00:00 GMT |
|
|
|
I. Thu
#5 / 9
|
Huge Memory Leak if you use JavaScript in IE4 Quote:
> using IE in my kiosk application despite the fact that my client had a
> strong preference for Netscape - in my experience IE just plain works
> better. But I'm sure you can imagine that my embarasment is consequently
> much greater when I have to admit to the client that his kiosk will stop
> working after a few hours - and that the problem is down to the browser I
> insisted on.
I've observed the same behavior. But has your client WinNT on a 32 MB RAM machine with a 1 GB hard disk? I haven't tested for 24 hours but remembers me some problems with a NT-Server and router software - 12 clients. Maybe there was such a problem too and not only the router ;-) since all problems could be solved for a while by a shut down of the server for a moment. __ IT http://www.it97.de/JavaScript/JS_tutorial/JS_beginners.html
|
| Tue, 29 May 2001 03:00:00 GMT |
|
|
|
Vidar Petursso
#6 / 9
|
Huge Memory Leak if you use JavaScript in IE4
Quote: >What's frustrating about JavaScript is that it's really hard to write a
>script that works the same in all browsers - even different versions of the
>same browser (Netscape included). If I had the ability to direct where
>Netscape and Microsoft spent their time, I would have you both make sure
>that your browsers implemented JavaScript exactly according to the spec
>(which I'd write :-)) so that I could guarantee that a page which worked on
>one browser also worked on the other.
I think you are confusing JavaScript with DOM. -- Best Regards Vidar Petursson ICYSOFT http://www.icysoft.com
Admin for these Mailing Lists Game Programmers Mailing List Coders Mailing List Windows Programmers Mailing List Copy Protection Mailing List Tel: 354-557-4809 SBN Level 2 & ClubSBN Member No matter where you go there you are.
|
| Tue, 29 May 2001 03:00:00 GMT |
|
|
|
Richard M. Smit
#7 / 9
|
Huge Memory Leak if you use JavaScript in IE4
> One of my goals is to make JScript and VBScript have similar enough feature
> sets so that script authors can use whatever language they feel more comfortable > with.
Any idea why I can't use JScript in the Developer Studio IDE? Right now,
I'm forced to use VBScript. Kind of odd that an IDE for C++ requires
the use of VBScript. Most C/C++ programmers, of course, will feel
more at home with JScript.
Richard
|
| Fri, 01 Jun 2001 03:00:00 GMT |
|
|
|
Microsoft Scripting D
#8 / 9
|
Huge Memory Leak if you use JavaScript in IE4 Re: your memory leak situation -- I'll look into it. Re: standards. Here on the script team, we are committed to the ECMA
process. That doesn't mean that we aren't adding Microsoft-specific
features to JScript -- we are, just as Netscape adds features to their
version. The point of the standard is having a core set of functionality
that you know will be there -- a lowest common denominator that you can
write to. These new features will eventually make it into future standards.
The next ECMA standard will probably include structured error handling, for
instance.
The same goes for the DOM, in theory. Now that the DOM is being
standardized by an independant body, all browser vendors have a target to
hit. That doesn't mean that we can't innovate -- we have to innovate,
because obviously we want the user experience to be better in our browser.
Eric
Quote:
>>>Incredible! The following 5-line HTML file will cause IE4.01/SP1 (on
>>>NT4/SP3) to leak about 50-100K of virtual memory every time!
>>><html>
>>><body>
>>><script></script>
>>></body>
>>></html>
>>>Even if you just open the page and hit 'refresh' a few times, you can see
>>>the memory usage going up at an alarming rate. (Use the NT task
>>>manager, and look at the 'Mem Usage' panel).
>>>Sooner or later, you'll run out of virtual memory, and get the dreaded
>>>'System Process - Out of Virtual Memory' dialog, telling you to close
>>>one or more programs. That's if your machine doesn't crash, of course.
>>>This behaviour seems to affect ANY page which has ANY JavaScript in it
(as
>>>the above HTML fragment does by default, since it doesn't explicitly set
>>>the 'language' attribute for the script).
>>>I find it somewhat sinister that if I add "language='VBScript'" to the
>>>script tag, the problem goes away. Is this Microsoft's idea of how to
make
>>>VBScript more popular than JavaScript?
>...and you replied:
>>I'm totally unable to reproduce that alleged leak. What if you take a
look
>>at the PERFMON private bytes counter for the IE process? Do you see a
leak
>>there as well? How big?
>I'm not entirely surprised that you can't reproduce it, because I was
>frankly stunned that anyone* would release a product with such a huge (and
>obvious) bug in it. I'm also glad you can't reproduce it, because that
means
>that there is a configuration out there that doesn't suffer from the
problem
>(perhaps all configs except mine?), and so I may be able to get my client
>off my back without having to re-write everything in VBScript.
>[ * anyone that is with the possible exception of Netscape, whose browser
>seems to have more bugs than a dead rat ]
>But I can assure you that it happens on all machines I've tried it on
(which
>all have the same config, which I'll detail in a minute). But first, just
in
>case you misunderstood, I'm talking about a leakage of virtual memory, not
>physical memory. So, the figure I'm looking at is the 'Commit Charge (K)
>Total' on the performance monitor tab of the NT Task Manager. The physical
>memory figure doesn't seem to change much (or at least, not to the same
>degree).
>My configuration is NT4 (build 1381) with SP3, and IE4 version 4.72.3110.8,
>with SP1. I'm in the UK, so I may or may not have international versions of
>the above (I don't know how to tell). Also, I arrived at these versions via
>the usual patches - I started off with some version of IE3, and have since
>upgraded. I also have most of the developer tools on my machine, which also
>seem to like replacing various DLLs.
>One of the other machines I've tried it on exhibits exactly the same
>behaviour, and since the machine is only a couple of months old, its
>configuration has a better pedigree - it probably started off life with
>NT4/SP3 and IE4, possibly without SP1 (though it has that now). However, it
>also has some of the development tools.
>STOP PRESS: I asked a friend at another company to try it out, and he can't
>reproduce the problem even though his machine has a very similar
>configuration to mine.
>Here's a typical run, with a freshly-booted machine with nothing running
>except the browser (and PWS, which is stopped):
>The commit charge figure is at 43044 before I start the browser. I start
the
>browser with a blank page, and it jumps to 46820. When I drop the HTML file
>on it, it jumps to 49704. When I hit refresh, it jumps to 49780, then
49844,
>49892, 49960, 50012. So, it's gained about 300K after viewing the page 6
>times.
>If I wait for about a minute, the figure drops slightly, to 49936. But if I
>hit refresh again, it jumps back to 50020, and after a minute only drops
>back to 50004. In other words, there seems to be an element of memory
>recovery, but it never regains nearly as much as it has lost (or at any
>rate, not fast enough to stop it from running out of virtual memory
>altogether).
>You asked about the private bytes count for IE in the performance monitor.
I
>started IE on an http URL so that IEXPLORE showed up as a separate process,
>and then loaded in my test file. The figure jumps around a bit, so I
decided
>to take each reading after I'd lost 1000K of virtual memory according to
the
>task manager. My readings (not on a 'fresh' machine this time, since I'd
>been doing the other tests first) were 2183168, 2199552, 2203648, 2211840,
>2220032. So, it goes steadily up, but (if my arithmetic serves me well) it
>only goes up 10K for each 1000K of virtual memory loss.
>I hope this is helpful. I'd be happy to run more tests for you if you like.
>>As for the "Is this Microsoft's idea of how to makeVBScript more popular
>>than JavaScript?" comment -- I'm assuming that this is a joke,
>Well, kinda, but it did cross my mind :-)
>>but on the off chance that it isn't:
>>As the guy who helped write both the VBScript and JScript engine, let me
>>tell you that Microsoft does not have any sinister plan to make VBScript
>>more popular than JScript or vice versa. I get asked this all the time.
>>"The examples for product Blah are all in JScript, does this mean that
>>Microsoft is deprecating VBScript?" "JScript has lousy error handling,
>>does this mean that Microsoft is deprecating JScript", etc, etc, etc.
>>One of my goals is to make JScript and VBScript have similar enough
feature
>>sets so that script authors can use whatever language they feel more
>>comfortable with. That's why for version 5, we've added error handling to
>>JScript, and classes, the "with" statement, regular expressions, and
"eval"
>>to VBScript. Microsoft is committed to working with the ECMA committee to
>>move the script standard forward and provide the best implementation of
>>that standard. We are also obviously hugely committed to the Visual
>>Basic family of languages, given the huge number of VB programmers
>>in the industry today.
>>We want both languages to succeed. Furthermore, the Active Scripting
>>interfaces are a public interface -- we want third parties to write
>>languages like Perl, Python, Haskell, etc as scripting languages.
(Unlike,
>>say, Netscape, who wants you to use only their language on your web pages.
>>:-) )
>OK, I applaud your efforts wholeheartedly. I should say that I insisted on
>using IE in my kiosk application despite the fact that my client had a
>strong preference for Netscape - in my experience IE just plain works
>better. But I'm sure you can imagine that my embarasment is consequently
>much greater when I have to admit to the client that his kiosk will stop
>working after a few hours - and that the problem is down to the browser I
>insisted on.
>(Now we're getting way off topic). From a web developer's point of view,
>having lots of choice over what language to use in a particular browser
>doesn't really help matters while there are other browsers out there that
>don't support all of those languages. Unless you're in a closed-shop
>situation (as I happen to be here with my kiosk app), you need your pages
to
>be viewable on as many browsers as possible, so you need to choose a
>language which all browsers support. And that, currently, is JavaScript.
>Anything that makes it less likely that the 'standard' language becomes
less
>standard or less ubiquitous is, in my opinion, a bad thing. This applies
>just as much to HTML as it does to scripting languages, of course. Both
>Microsoft and Netscape are guilty of polluting HTML with their own
>non-standard tags, and of implementing certain parts of the standard
>incorrectly. It is possible to move the standard forward without having
>vendor-specific extensions, and my life would be a lot easier if it were
>always done that way.
>What's frustrating about JavaScript is that it's really hard to write a
>script that works the same in all browsers - even different versions of the
>same browser (Netscape included). If I had the ability to direct where
>Netscape and Microsoft spent their time, I would have you both make sure
>that your browsers implemented JavaScript exactly according to the spec
>(which I'd write :-)) so that I could guarantee that a page which worked on
>one browser also worked on the other. Having either of you implement
another
>language is *way* down my list of priorities.
>Of course, having more than one client-side langauge means that anyone
>trying to get into (or stay in) the browser market has a much bigger hurdle
>to get over. Especially if one of those languages is proprietary, or
subject
>to change at the whim of their competitor... :-)
|
| Sat, 02 Jun 2001 03:00:00 GMT |
|
|
|
Electru
#9 / 9
|
Huge Memory Leak if you use JavaScript in IE4 Quote: >Re: your memory leak situation -- I'll look into it.
Great, thanks. Quote: >Re: standards. Here on the script team, we are committed to the ECMA >process. That doesn't mean that we aren't adding Microsoft-specific >features to JScript -- we are, just as Netscape adds features to their >version. The point of the standard is having a core set of functionality >that you know will be there -- a lowest common denominator that you can >write to. These new features will eventually make it into future standards. >The next ECMA standard will probably include structured error handling, for >instance. >The same goes for the DOM, in theory. Now that the DOM is being
>standardized by an independant body, all browser vendors have a target to
>hit. That doesn't mean that we can't innovate -- we have to innovate,
>because obviously we want the user experience to be better in our browser.
Also great :-).
|
| Thu, 07 Jun 2001 03:00:00 GMT |
|
| |
|
