696018 - regame.tv livestreams website locks up browser or crashs ff

Status: RESOLVED DUPLICATE of bug 699974

(Firefox :: General, defect)

Description

[Enrico Kern]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20100101 Firefox/7.0.1
Build ID: 20110928134238

Steps to reproduce:

Go to http://www.regame.tv/live and click on any of the streams, it doesnt matter if they are online or offline.


Actual results:

Firefox locks up completly for 5-10 seconds and sometimes crashes right away. This wasnt the case with ff 6 and regame.tv did not change that detailpages.


Expected results:

The livestreamplayer should load.

Comment 1

[:aceman]

Can you provide some crash ID from about:crashes?

Comment 2

[Alice0775 White]

In my case, No crash, but UI locks for than 30sec and more .

Regression window(cached m-c),
Works:
http://hg.mozilla.org/mozilla-central/rev/b69d30cc0b24
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0a1) Gecko/20110606 Firefox/7.0a1 ID:20110606110214
Hangs:
http://hg.mozilla.org/mozilla-central/rev/3589f8cefd83
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0a1) Gecko/20110606 Firefox/7.0a1 ID:20110606132754
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b69d30cc0b24&tochange=3589f8cefd83

Regression window(cached TM),
Works:
http://hg.mozilla.org/tracemonkey/rev/b4ddabc55995
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0a1) Gecko/20110531 Firefox/6.0a1 ID:20110602151040
Hangs:
http://hg.mozilla.org/tracemonkey/rev/bf418b38bfe3
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0a1) Gecko/20110602 Firefox/6.0a1 ID:20110602194545
Pushlog:
http://hg.mozilla.org/tracemonkey/pushloghtml?fromchange=b4ddabc55995&tochange=bf418b38bfe3

in local(no PGO):
built from bf418b38bfe3 : UI locks for about 30 sec and more
built from 7a8dc72beb43 : UI locks for about 30 sec and more
built from c72fed47c034 : UI locks for about 30 sec and more
built from abd2dcd555f4 : UI locks for about 30 sec and more
built from c8e12e8c281b : UI locks for about 10 sec 
built from b4ddabc55995 : UI locks for about 10 sec 

Triggered by;
abd2dcd555f4	Luke Wagner — Bug 538293 - remove inlineCallCount and this STACK_QUOTA silliness (r=dvander)

Comment 3

[:aceman]

I can confirm the temporary freeze (about 10s), where firefox and plugin-container each take about 50% of CPU core. This is on linux, 32bit.

The "streams" are using Flash.

Comment 4

[Luke Wagner [:luke]]

I can also repro on nightly/linux.

Random breaking in gdb shows call stacks under NPAPI.  Once I break with gdb, Firefox must think the plugin is dead so I get the plugin-sad-face and the browser is responsive again.

What the 'remove inlineCallCount' patch did was increase (by about 10x) the maximum depth of the JS call stack available to content.  Previously, Firefox had the smallest max call stack depth of other browsers by far, so this change fixed that (and also removed a bunch of really gross code).  That means that, before the patch, our shallow stack depth must have been terminating the offending script earlier.

To wit, loading this in Chromium produces a 7 second hang before it becomes responsive again.  I think to fix this we need to find how this page is circumventing the operation-callback check that ordinarily kills slow scripts.

Comment 5

[Luke Wagner [:luke]]

Also: neither Chromium nor Firefox produce a stack-overflow error when they become responsive after the hang.  That means that there is some recursive call driving the slowness that actually terminates without hitting the stack limit (given enough space).

Comment 6

[Enrico Kern]

this is the crash id from when firefox actually crashed using this page.

https://crash-stats.mozilla.com/report/index/bp-951c21c3-0cb1-47df-a625-cb9772111020

Comment 7

[Enrico Kern]

so any update here? i mean basically this bug can be used sort of denial of service too if embedding this site in a iframe or replicate the behavior?!

Comment 8

[Andrew McCreight [:mccr8]]

Marking as [Snappy:P2] because it sounds bad, but looking over the hang reporter reports, I didn't see anything like the stack in Comment 6.