RangeError: Maximum call stack size exceeded on Tizen WebView when playing DRM content

[sreinus]

Have you read the FAQ and checked for duplicate open issues?
Yes

If the problem is related to FairPlay, have you read the tutorial?
Not applicable, as this issue is not related to FairPlay.

What version of Shaka Player are you using?
I am using Shaka Player version 4.11.7

Can you reproduce the issue with our latest release version?
Yes

Can you reproduce the issue with the latest code from main?
Yes

Are you using the demo app or your own custom app?
I am using my own custom app on the Tizen platform.

If custom app, can you reproduce the issue using our demo app?
The demo app is not directly available on Tizen, but testing was performed using a content URL from the demo app: https://storage.googleapis.com/shaka-demo-assets/sintel-widevine/dash.mpd

What browser and OS are you using?
WebView on Tizen 8.0, SMART-TV. User Agent details: "5.0 (SMART-TV; LINUX; Tizen 8.0) AppleWebKit/537.36 (KHTML, like Gecko) 108.0.5359.1/8.0 TV Safari/537.36"

For embedded devices (smart TVs, etc.), what model and firmware version are you using?
Samsung UE65DU7172UXXH, firmware version 1120

What are the manifest and license server URIs?
https://storage.googleapis.com/shaka-demo-assets/sintel-widevine/dash.mpd

What configuration are you using? What is the output of player.getNonDefaultConfiguration()?
{}

What did you do?
Trying to play content from https://storage.googleapis.com/shaka-demo-assets/sintel-widevine/dash.mpd without DRM configuration.

What did you expect to happen?
I expected a player error NO_LICENSE_SERVER_GIVEN (6012)

What actually happened?
The error encountered is RangeError: Maximum call stack size exceeded which points to an issue in the method alphabeticalKeyOrderStringify_ of the file shaka-player.ui.debug.js. The same error occurs if DRM settings are present in the configuration even if the content being played does not have DRM (https://storage.googleapis.com/shaka-demo-assets/angel-one/dash.mpd). If I remove DRM settings, then it plays fine.

This issue seems to stem from v4.4, because v4.3 works fine.

[avelad]

@tykus160 can you review it? Thanks!

[tykus160]

I'm not able to reproduce the issue on QE55QN91AAT (Tizen 6) using current main branch. My model is premium though, maybe that's the difference.

[joeyparrish]

alphabeticalKeyOrderStringify_ recurses through an object, but a circular reference could cause a major issue.

It is only used in serializing decoding configs to use as cache keys, though, so I don't expect a circular reference should exist. On the other hand, that's a lot of recursive calls in the screenshot. The structure should never be that deep.

Honestly, I always worried that the cache on MediaCapabilities would cause problems some day. So if someone has a clever solution to remove it, I'm open to that.

@sreinus, since we can't reproduce this, could you modify Shaka to capture the structure in the initial call to alphabeticalKeyOrderStringify_ from getDecodingInfosForVariant_? I'd love to see what JSON.stringify() makes of it.

It also occurs to me that perhaps we could end up with a circular reference through a bug in lib/polyfill/media_capabilities.js, if that somehow modified the input decoding config by mistake.

[sreinus]

alphabeticalKeyOrderStringify_ recurses through an object, but a circular reference could cause a major issue.

It is only used in serializing decoding configs to use as cache keys, though, so I don't expect a circular reference should exist. On the other hand, that's a lot of recursive calls in the screenshot. The structure should never be that deep.

Honestly, I always worried that the cache on MediaCapabilities would cause problems some day. So if someone has a clever solution to remove it, I'm open to that.

@sreinus, since we can't reproduce this, could you modify Shaka to capture the structure in the initial call to alphabeticalKeyOrderStringify_ from getDecodingInfosForVariant_? I'd love to see what JSON.stringify() makes of it.

It also occurs to me that perhaps we could end up with a circular reference through a bug in lib/polyfill/media_capabilities.js, if that somehow modified the input decoding config by mistake.

Replacing alphabeticalKeyOrderStringify with JSON.stringify() fixes the issue. I have no idea why this happens with my setup, but I agree that the current solution with the circular reference is not the best.

[joeyparrish]

If JSON.stringify fixes it, it might not be a circular reference. Here's what I found in the JS debugger in Chrome, at least:

a = {}
a.a = a
JSON.stringify(a)

VM122:1 Uncaught TypeError: Converting circular structure to JSON
    --> starting at object with constructor 'Object'
    --- property 'a' closes the circle
    at JSON.stringify (<anonymous>)
    at <anonymous>:1:6

Still, I wonder why we get into a seemingly-infinite recursion in your case and not for any of us. Could your device produce different results for "for (const key in obj)" or "for (const key of keys)" or "if (value instanceof Object)" that would lead to deeper recursion? For example, if "prototype" shows up in the keys, that could break things. It might be interesting if you could log "obj" and "keys" right after "keys.sort()" and show us what the first few iterations look like.

[shaka-bot]

Closing due to inactivity. If this is still an issue for you or if you have further questions, the OP can ask shaka-bot to reopen it by including @shaka-bot reopen in a comment.

[joeyparrish]

A related report came into video-dev Slack. In that, there seems to be a point where an array has extra properties that lead to the array constructor and therefore a circular reference. (Because for function x, x.prototype.constructor.prototype === x.prototype.)

So I'm suspicious of polyfills or app frameworks that modify Array.

[joeyparrish]

[joeyparrish]

Speculative draft PR here: #7721

It adds special cases for arrays and functions.

[joeyparrish]

Reporter on video-dev Slack confirms that the PR above fixes the issue for him!