User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/532.3 (KHTML, like Gecko) Chrome/4.0.223.11 Safari/532.3 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.1.4) Gecko/20091016 Firefox/3.5.4 It happens only on Windows or Mac. On linux it works ok. Reproducible: Always Steps to Reproduce: 1. Just enter to http://ghostnest.ohdev.com.ar/dreamerator/war/Mappy.html#ModelDesigner1 Actual Results: Firefox hangs Expected Results: Fast canvas 3d emulation! :)

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.3a1pre) Gecko/20091027 Minefield/3.7a1pre Confirmed on trunk. Causes a crash for me.

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.4) Gecko/20091016 Firefox/3.5.4 Doesn't happen on 1.9.1 branch.

I get a stop-script dialog with the following url: http://ghostnest.ohdev.com.ar/dreamerator/war/canvaseditor/AC280349860F98E5AE4FFF8AD16F2BBA.cache.html:2286 After that, I get this assertion: ###!!! ASSERTION: op == PL_DHASH_LOOKUP || RECURSION_LEVEL(table) == 0: 'op == PL_DHASH_LOOKUP || RECURSION_LEVEL(table) == 0', file c:/Users/Natch/Documents/mozilla_trunk/m-c_debug/xpcom/build/pldhash.c, line 612 Stack attached. !analyze -v hang Looks like a CC/GC issue...

Sorry about that, the previous stack was on a stale build, this is on latest-trunk. Previously, I'd have to play around with the page to get to is, now just loading the page hits this assertion: ###!!! ASSERTION: Should have aVisibleRegionBeforeMove when there are moving frames: '(aVisibleRegionBeforeMove != nsnull) == aBuilder->HasMovingFrames()', file c:/Users/Natch/Documents/mozilla_trunk/mozilla-central/layout/base/nsDisplayList.cpp, line 322 Stack attached.

-->Layout it seems...

I've attached a patch to bug 516885 that fixes that assertion. It's harmless. The real issue here in the JS engine. I get stuck in stacks that look like this: #0 0x003a470a in js_NewStringCopyN (cx=0x16f5400, s=0x7a508012, n=23986) at /Users/roc/mozilla-checkin/js/src/jsstr.cpp:3157 #1 0x003a47fd in js_NewDependentString (cx=0x16f5400, base=0x95b2300, start=9, length=23986) at /Users/roc/mozilla-checkin/js/src/jsstr.cpp:3099 #2 0x003a50c7 in SubstringTail (cx=0x16f5400, str=0x95b2300, length=23995, begin=9, end=23995) at /Users/roc/mozilla-checkin/js/src/jsstr.cpp:752 #3 0x003a77d3 in str_substring (cx=0x16f5400, argc=2, vp=0x171b92c) at /Users/roc/mozilla-checkin/js/src/jsstr.cpp:778 and other stacks doing memory allocation related to these operations. It looks like something bz mentioned earlier about substring operations making copies because the length is too long?

Yeah. We used to copy if either length or offset was > 2^14. Then bug 519492 changed us to copy if length > 2^8 or offset > 2^20. In your case, your length is between 2^14 and 2^15, so you lost no matter what. You can locally change DEPENDENT_LENGTH_BITS in jsstr.h to 18, say, and see how much that helps.... The bug on making js_NewDependentString not copy no matter what, pretty much, is bug 521423.

That said, why is this a regression? When did it regress?

Why is a canvas demo doing such large substring extraction? /be

Fwiw, on latest-latest trunk (i.e. post today's merge), this page _really_ borks the browser, and it eventually crashes, I'm working on a st.

From the stacks, it looks like it's doing an XHR to load some data and then parsing the result.

Memory goes up to 1GB+ after about 5 secs on my system, even if I unload the page.

(In reply to comment #12) > Memory goes up to 1GB+ after about 5 secs on my system, even if I unload the > page. That makes it sound like we are failing to GC when we should. js_NewStringCopyN uses cx->malloc, which I think should be counted correctly, but maybe there are other strings coming from somewhere else.

The patch for bug 519492 seems sufficient to provoke the symptom here. /be

Hmm. So maybe some (most?) of the strings here fell under the 2^14 length cutoff?

That doesn't explain the lack of gc, btw, unless the page is holding on to all of those strings. Brendan, did you try backing out bug 519492 locally and test, or was that a theoretical argument?

Theoretical, but dependent strings share the independent string's jschar buffer, copies of course do not. So it may be that the strings are all live and the 1GB+ memory use consists in large parts of all the live non-dependent substrings. Two of the three substring calls in the app have their results stored (as key and value) in a JS array... /be

I just tried a local backout of bug 519492, and it doesn't change the behavior I see on the testcase. That behavior is a CPU spike to 100% for about 3-4 seconds, then no cpu usage (using steps from comment 0). In particular, no hang. Is there something else I need to do to reproduce the bug?

Oh, and given comment 0's stuff about the hang not happening on Linux... I am in fact testing on Mac.

Hi guys, sorry to be annoying. Does the bug 519492 solved this problem? Thanks!

No. For now, I can't reproduce this problem. How do I go about doing so?

Is this page http://ghostnest.ohdev.com.ar/dreamerator/war/Mappy.html#ModelDesigner1 working for you on windows xp?

I don't have WinXP, so I have no idea. I can check on Vista.

Ah, I know for sure that it works on Linux on that it does'n work on Windows XP.

Do you perhaps have Kaspersky Antivirus installed on that XP system?

Hmm... I can _sometimes_ reproduce the slowness with Firefox 3.5.4 (the release build) but not with my own 1.9.2 build. This is still on Mac. I can reproduce slowness in the Vista VM, but everything in there is slow today for some reason. :( I do see a large amount of memory traffic on this page. Gal, how much RAM does the XP machine in question have? Is Linux running on the same machine?

Natch, you marked this bug as a regression. What is it a regression from or to? Comment 2 makes no sense, since this bug is reported against a 1.9.1 build....

No, I dont have Kaspersky Antivirus installed. I am running on a 2gb ram pc, that only have windows xp installed. The firefox version I use its the one mensioned on this post. But I also tried out Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.6pre) Gecko/20091106 Shiretoko/3.5.6pre, and Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20091013 Minefield/3.7a1pre, but the problem still there.

Tested with 3.5.5 on Windows XP and Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20091106 Minefield/3.7a1pre Might not be as fast as Chrome, but definitely no hang.

José, how much RAM? Gal, how much RAM does the Linux machine that wasn't showing the problem have?

Wasn't my machine, but I will check it out and tell you

(In reply to comment #30) > José, how much RAM? > I got 3 gigs ram. I did notice that the CPU usage goes up to 50 and "Mem Usage" up to 1.1 gig while loading though. This values go down to normal ones once the page is loaded.

The site in question changed some (you can see by the way the black dialog now loads in the upper-left corner), I can't really reproduce the hang or bad behavior anymore, previously on 1.9.1 the site worked and just took some time to load (understandably). However, on trunk the site hogged a lot of memory and _always_ resulted in a hang then crash (windows crash dialog pops up). Even when it did load on trunk it wouldn't work correctly and the memory would be very high.

Yes, sorry, the site is changing contantly, its a WIP, on a testing server... But the bug still there... If I make some changes and I make it work I will be happy, but I will like you find the bug and solve it

Natch, sounds like you're seeing a different issue from the original bug here. Please file it separately and hunt down a regression range, since you can actually reproduce it? I don't see anything like what you're seeing. Gal, it really sounds like it's just a matter of whether the browser starts swapping while allocating that giant chunk of RAM. If it does, things are obviously slow.... If the page is in fact constantly changing, that'll make it very difficult to analyze and even more difficult to tell whether it's fixed. Can you create a static version and point to it?

Here I put a static version that wont change. http://institutoeras.appspot.com... But I just update to Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5, and its working... but also I made some optimizations, so I dont know the reason

http://institutoeras.appspot.com/#ModelDesigner1 This one particulary not working for me. This two one works on my machine: http://institutoeras.appspot.com/#ModelDesigner0 http://institutoeras.appspot.com/#ModelDesigner2

OK. On that first url from comment 37, I do indeed see a very long period of thrashing on trunk (or rather on tracemonkey). The patch in bug 521423 fixes that completely. I see a somewhat shorter hang on 1.9.1 there. The thrashing definitely got a bit worse with bug 519492. The exact amount obviously depends on the ram situation when the page is loaded. The assertion in comment 4 is not related to this bug. There's no hang (just a slow script), nor a memory leak that I can see.

Hi guys, I fix the problem changing my Collada parser implementation, and it works realy good. Anyway, thank you for the support and help me to track the problem! Keep the good working!

I'm going to mark this duplicate of bug 521423.