1247496 - "too much recursion" error on vine.co with JIT enabled on Win64

Status: RESOLVED FIXED

(Core :: JavaScript Engine: JIT, defect)

Description

[Kyle Repinski]

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:47.0) Gecko/20100101 Firefox/47.0
Build ID: 20160210071115

Steps to reproduce:

(Configuration: *Any* Win64 Firefox build with "media.wmf.enabled"=true (default))
Attempt to watch a "Vine" video on its webpage, e.g. https://vine.co/v/i1lg0wgpZQe


Actual results:

The video playback never starts. I can right click the video element and select options like Play/Pause, Show/Hide Controls, but nothing visibly changes; it appears to have just locked up.


Expected results:

The video should play.

The strange thing is that watching Vine's mp4 directly (e.g. https://v.cdn.vine.co/r/videos/274888C3881309227981415342080_5d3663f752e.3.0.11050096931407576011.mp4 ) works fine, playback only fails on their website. This behavior is not observed with 32-bit Windows builds, and setting "media.wmf.enabled"=false 'fixes' the issue.

This may or may not be related to a particular hardware decoder, in my case it is occurring on a AMD Radeon HD 6620G (Northern Islands-family) with the latest drivers (16.1.1), on Windows 7. I will attempt to round up some other systems and see if I can reproduce it on them.

Comment 1

[Kyle Repinski]

Ooops, looks like disabling WMF results in it falling back to Flash. Disabling Flash causes it to fail to play at all, including on 32-bit builds.

I'm also seeing a warning in the 'Web Console' with the Win64 builds saying something about "too much recursion" with Javascript, that may just be a side-effect of the main issue though.

Comment 2

[Alice0775 White]

I can confirm the problem on x64 build with clean profile.
Though, i686 build works fine.

Comment 3

[Loic]

And the CPU use with the 64b is clearly higher than the 32b version when failing to decode the video.

Comment 4

[Kyle Repinski]

The GPU usage is also very high, it hits 35%+ whereas normally decoding uses somewhere around 15%. All that whilst nothing changes in the video element.

Comment 5

[Chris Pearce [:cpearce (Not reading bugmail)]]

If you set media.hardware-video-decoding.enabled=false and media.wmf.enabled=true, does that fix the problem?

Comment 6

[Loic]

Same result: no playback, high CPU use.

Comment 7

[Emanuel Hoogeveen [:ehoogeveen]]

I'm also seeing this. I think this started after a change by Vine or a Windows update, as I've been using 64-bit Nightly for quite a while and vines certainly worked before - whereas now it doesn't work going back to at least Firefox 44. 64-bit Chrome works fine, incidentally. Is there anything I can do to help debug this? I can do local builds if needed.

Comment 8

[Kyle Repinski]

The break occurs on the first Nightly build of the 42.0a1 version. Everything versioned 41.0a1 and lower works fine.

To be clear:
GOOD (last  build of 41.0a1): https://archive.mozilla.org/pub/firefox/nightly/2015/06/2015-06-29-03-02-10-mozilla-central/
BAD  (first build of 42.0a1): https://archive.mozilla.org/pub/firefox/nightly/2015/06/2015-06-29-13-40-17-mozilla-central/

Comment 9

[Loic]

Reg range:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=312c68b16549de9cea1557f461d5d234bd5e0a7d&tochange=c26dbd63604d726430f24b8b6f00b3dedb03fc4c

I see no suspicious bug. Weird.

Comment 10

[Kyle Repinski]

Setting media.mediasource.mp4.enabled=false allows Vine to play, both on the 42.0a1 build I mentioned and on the latest Nightly. The 'too much recursion' error also disappears.

Comment 11

[Kyle Repinski]

Firefox 42.0's release notes states "Media Source Extension for HTML5 video available for all sites". I'm guessing Vine's player is checking for Firefox 42 before trying to use MSE, and then when they do use it they're somehow either
a) hitting a bug in Win64 Firefox builds, or
b) assuming Win64 Firefox doesn't exist and as a result aren't running their code as they intend to

That seems like the only explanation. I have no idea how to contact Vine and ask them nor do I know how any of this works well enough to debug it, hopefully somebody else more knowledgeable can chime in here!

Comment 12

[Alice0775 White]

It works as expected if UA spoofed as follows.
general.useragent.override = Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:40.0) Gecko/20100101 Firefox/40.0

Tested on
https://hg.mozilla.org/mozilla-central/rev/1150ac4755c7bb35df4fc7504f6f1b6c257f400e
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0 ID:20160218030349

Comment 13

[Alice0775 White]

(In reply to Alice0775 White from comment #12)
> It works as expected if UA spoofed as follows.
> general.useragent.override = Mozilla/5.0 (Windows NT 6.1; Win64; x64;
> rv:40.0) Gecko/20100101 Firefox/40.0
> 
> Tested on
> https://hg.mozilla.org/mozilla-central/rev/
> 1150ac4755c7bb35df4fc7504f6f1b6c257f400e
> Mozilla/5.0 (Windows NT 6.1; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0
> ID:20160218030349

Oops,

It works as expected if UA spoofed as follows.
general.useragent.override = Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:40.0) Gecko/20100101 Firefox/40.0

Tested on
https://hg.mozilla.org/mozilla-central/rev/1150ac4755c7bb35df4fc7504f6f1b6c257f400e
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:47.0) Gecko/20100101 Firefox/47.0 ID:20160218030349

Comment 14

[Loic]

I dont see the difference with both UAs...

Comment 15

[Kyle Repinski]

(In reply to Alice0775 White from comment #13)
> It works as expected if UA spoofed as follows.
> general.useragent.override = Mozilla/5.0 (Windows NT 6.1; Win64; x64;
> rv:40.0) Gecko/20100101 Firefox/40.0

That confirms my suspicions on them doing a UA check before using MSE. Now I guess the question is what's breaking there. Should this be set as a blocker of Bug 778617 since it's presumably MSE-related?

Comment 16

[Loic]

Open the JS scripts linked from Vine, there are some code about tests with navigator.userAgent.

Comment 18

[Igor]

My bug 1255024 was closed as duplicate of this bug.

One thing I don't understand is, why it is working for me when I start Firefox in safe mode (firefox.exe -safe-mode) but not with a default (vanilla) profile.

Is Firefox using a different UA in safe mode?

Comment 19

[Loic]

No, same UA but I guess some JS stuff is disabled.

Comment 20

[Emanuel Hoogeveen [:ehoogeveen]]

IIRC the JITs are disabled, but I doubt that would affect this. Hardware acceleration is also disabled, though - maybe this is some interaction with DXVA gone wrong?

Comment 21

[Loic]

Disabling HWA does nothing.
But it works fine with media.mediasource.mp4.enabled=false. So it's related to MSE, I guess.

Comment 22

[Loic]

Chris, any idea why disabling MSE fixes the playback?

Comment 23

[Chris Pearce [:cpearce (Not reading bugmail)]]

The player here is using MediaSource, but the JavaScript that feeds it fails when run in Win64 Firefox. So disabling MediaSource means the site takes a non-MediaSource path, and won't run the failing script.

The script runs fine in 32bit Firefox, but in Win64 Firefox, the script fails with a "too much recursion" error logged to the WebConsole, along with a JS call stack.

Toggling javascript.options.baselinejit to false fixes the issue.

So this must be is a bug in the JavaScript engine.

Naveed: Can one of your JS guys look into this?


STR:
1. Open https://vine.co/v/i1lg0wgpZQe in Win64 Firefox Nightly with JIT enabled

Expected result: Video should play

Observed result: Video does not play, "too much recursion" error in WebConsole.

Comment 24

[Emanuel Hoogeveen [:ehoogeveen]]

Jan, could this be another instance of bug 1227035? (another weird coincidence if so :) )

Comment 25

[Emanuel Hoogeveen [:ehoogeveen]]

Looks like today's Nightly still gives the "too much recursion" error in the win64 build, so if bug 1227035 *is* related, the fix wasn't enough to address this case. I checked the win32 build against the win64 build with a clean profile, and confirmed that only the win64 build shows the error.

Comment 26

[Jan de Mooij [:jandem]]

Hm I can reproduce this on OS X if I lower the stack limit in XPCJSRuntime.cpp to be a bit less than what we use on Windows. Will investigate.

Comment 27

[Jan de Mooij [:jandem]]

The website uses a recursive algorithm somewhere and we end up with more than 2100 JS frames on the stack. Vine should stop doing that.

There's some low hanging fruit to make some stack frames smaller though and improve the recursion depth a bit. I also want to see if MSVC with PGO is inlining too much, resulting in huge stack frames.

Comment 28

[Emanuel Hoogeveen [:ehoogeveen]]

Yeah, I think this was caused by a change on Vine's end at some point, since I could reproduce it back to Firefox 44 (I didn't go back further). The fact that 64-bit Firefox on Windows is still pretty new is probably the only reason they haven't addressed it yet.

Comment 30

[Emanuel Hoogeveen [:ehoogeveen]]

Fixed in today's Nightly by bug 1257234 :)

Comment 31

[Trel]

FYI

baselinejit on = vine doesn't work
baselinejit off = twitter embedded tweets on twitter doesn't work