I've copied text from bug 2235 (marked as a dup of this bug) which discusses this problem - it turned up with a user that was using the java-enabled javascript standalone shell and noticed very bad memory behavior. My explanation is at the bottom... roger, could you confirm my understanding of the problem? Mozilla presumably does register a branch callback, so this shouldn't be a problem with the browser.

*** Bug 2235 has been marked as a duplicate of this bug. ***

Copied text from 2235 (marked as a dup of this one) This memory blowup turned out to be a flaw with the js.c standalone interpreter (or possibly jsj, the liveconnect-enabled interpreter.) Most applications using js, such as the browser, register a 'branch callback' function that gets called whenever the javascript interpreter makes a branch. Usually this includes a check to see whether the garbage collector needs to be called. Without this check, the garbage collector is called in loops like the one below only when the system runs out of memory or triggers some other heuristic check. At least, that's my understanding.

moving to the "JavaScript Engine" component.

Setting all Javacript bugs to rginda QA Contact.

Updating QA contact -

Reassigning Mike's JS Engine bugs to Patrick, as per recent meeting -

xpcshell.c (at heart a clone of js.c) also lacks this. They can both be fixed with the same chunk of code.

*** Bug 104099 has been marked as a duplicate of this bug. ***

Fixed on 11-Feb-2004 for Narcissus. /be

testcase from bug 2235 based on example code from mff@research.att.com. mff, do you mind if we include your testcase in the javascript test library?

Sure, use it! Wow, this is ancient history ;-) Mary (In reply to comment #10) > Created an attachment (id=174881) [edit] > js1_5/Regress/regress-3649-n.js > > testcase from bug 2235 based on example code from mff@research.att.com. > > mff, do you mind if we include your testcase in the javascript test library?

js1_5/Regress/regress-3649-n.js checked in