464253 - Assertion failure: exit->numStackSlots == stableTree->stackTypeMap.length()

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine, defect)

Description

[IU]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/20081111 Firefox/2.0.0.11
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/20081111 Minefield/3.1b2pre

When visiting the linked infoworld.com URL, the browser consumes high CPU and leaks memory.  Only solution is to force quit.  Same behavior on XP and OSX.  It reportedly crashed on Vista.  Happens only when JIT content is enabled.

Script responsible is http://js-kit.com/comments.js


Reproducible: Always

Steps to Reproduce:
1. Open Windows Task Manager (WTM)
2. Under WTM Processes, add the VM Size column
3. Create a new profile or disable all blocking extensions and hacks
4. Visit the linked URL
5. Notice the high CPU usage and Minefield unresponsiveness
6. Notice on WTM that "Mem Usage" cycles, but "VM Size" continues to grow
7. Compare with JIT content disabled.

Actual Results:  
As stated.

Comment 1

[Jim Jeffery not reading bug-mail 1/2/11]

I see same on Vista HP SP1 - marking 'New'

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b2pre) Gecko/20081111
Minefield/3.1b2pre Firefox/3.0 ID:20081111032821

Comment 2

[Carsten Book [:Tomcat]]

i will check Firefox for Memory Leaks with this testurl.

Comment 3

[IU]

Attachment: JavaScript responsible for bug. Source: http://js-kit.com/comments.js

Comment 4

[IU]

Attachment: Infoworld website at time of bug

Comment 5

[RFLazaro]

When loading that page, Firefox memory usage peaks at 700MB but Firefox does trim down back to 50MB.

Comment 6

[Carsten Book [:Tomcat]]

Note: i don't see a Memory Leak here, but the Debug Build (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/20081113 Minefield/3.1b2pre) was running into a fatal assertion:

Assertion failure: exit->numStackSlots == stableTree->stackTypeMap.length(), at c:/work/mozilla/builds/1.9.1-trace-malloc/mozilla/js/src/jstracer.cpp:2164

But i didn't saw a memory leak here.

Comment 7

[IU]

@Carsten: Did you at least see the huge memory and CPU consumption?

Comment 8

[Jim Jeffery not reading bug-mail 1/2/11]

This seems to be fixed with an hourly that has the latest merge from TraceMonkey.

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b2pre) Gecko/20081114 Minefield/3.1b2pre Firefox/3.0 ID:20081114102041 <- latest hourly

Comment 9

[Carsten Book [:Tomcat]]

(In reply to comment #8)
> This seems to be fixed with an hourly that has the latest merge from
> TraceMonkey.
> 
> Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b2pre) Gecko/20081114
> Minefield/3.1b2pre Firefox/3.0 ID:20081114102041 <- latest hourly

Confirmed, also a new generated Debug Build does not crash with the steps to reproduce. -> Worksforme

Comment 10

[IU]

I'm not sure I can verify that this bug is fixed.  I just compared the comments.js file, linked from the infoworld.com site, with the one in the attached ZIP file, and I notice there have been significant changes made.

When I loaded the page from the content in the ZIP file, using an affected Minefield version, I could not reproduce the crash -- only when online.  Therefore, someone more skilled than I, and who knows how to verify using the original comments.js file, will need to check this.

Thanks