Closed Bug 1128163 Opened 10 years ago Closed 3 years ago

Getting Error on all content exported from Unity

Categories

(Core :: Storage: IndexedDB, defect, P5)

Product:
Core
Component:
Storage: IndexedDB
Type:
defect

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: mbest, Unassigned)

References

(
URL
)

Details

(Keywords: regression)

http://beta.unity3d.com/jonas/WebGLBenchmark/ A error pops up in firefix 36+. More information in the console to help with debugging.
Look into this more. It appears that all unity content is generating an error message on load. This applies to 36+
Summary: Getting Error in Unity Benchmark → Getting Error on all content exported from Unity
I see an error on 38 on linux as well, so it does not seem to be specific to any version or OS. I get an alert popup showing an error message, then in the console Unable to find type [UnityEngine.dll]UnityEngine.AssemblyIsEditorAssembly WebGLBenchmark.js:1:228468 [..] Invoking error handler due to InvalidStateError" UnityConfig.js:74:4 InvalidStateError I don't see the problem on Chrome. Other Unity contents seems ok (e.g. http://files.unity3d.com/jonas/DT2/ ) so perhaps the problem is specific to this link.
OS: Windows 8.1 → All
Hardware: x86 → All
Version: 36 Branch → unspecified
It is not specific to this link, it is any content I have tried to export from the Unity Beta. Most likely this is a new detection that was not present in earlier versions.
Oh ok, I see. So they are exporting new code, and it breaks in 36+. And that link is an example of the new code. I confirmed the bug is not present in 35 (stable), so this is definitely a regression. It could in theory be either JS or WebGL related. Given that the error thrown appears to be due to an internal logic error in Unity code, I would guess JS.
URL: http://beta.unity3d.com/jonas/WebGLBe...
Keywords: regression
This regressed on the nightly of 2014-11-29-03-02-07-mozilla-central and was ok on the previous one (2014-11-28-11-43-34-mozilla-central). Regression range: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=17de0f463944&tochange=e90536aa55dd Nothing really stands out. I see just one obvious JS-affecting commit, bug 1105187. Perhaps related?
Tested on Macbook Pro in OSX 10.10 with Nightly, the issue did not manifest. On my Linux box with current Nightly, I get the same dialog with InvalidStateError as Alon immediately after the page loads (before even starting any tests). On Windows with Nightly, I get a dialog with UnknownError instead. In both cases, one can click ok on the dialog and the benchmark itself seems to work ok without problems. Attempting to use the mozregression tool to bisect this did not work, and when run via that tool, even the latest Nightly passed on both Windows and Linux. It looks like this is because the issue is somehow user profile related. Creating a new user profile (run Firefox with 'firefox -P' and create a new fresh profile) and running the page, the error no longer appears, so it seems that some state has gone wrong in existing user profiles. This makes me think the issues is not Windows+Linux (sans OSX) -specific, but that only the user profiles on my Windows and Linux systems are in such a bad state. I suspect the root cause for this is somewhere in IndexedDB operation, since on the Windows Emscripten build bots, we had same kind of transient browser suite run errors with an UnknownError exception being thrown from IDBFS operation, but those would disappear after updating Firefox, so we were not able to dig to the root of this.
With further testing, I have the following steps to reproduce to get a new profile to a bad state: Pre-setup: 1. Download http://clb.demon.fi/dump/UnityWebGLBenchmark.zip and unzip it to some convenient location. 2. In that directory, run 'python -m SimpleHTTPServer' 3. Download http://clb.demon.fi/dump/http+++beta.unity3d.com.zip. STR: 1. Run Firefox Nightly with 'firefox -P' 2. Create a new profile, say, 'testprofile'. 3. While keeping the launched Nightly open in the main page, do: 4. navigate to the user profile directory, e.g. 'cd C:\Users\Jukka\AppData\Roaming\Mozilla\Firefox\Profiles\zwgzkcmp.testprofile\storage' 5. 'mkdir temporary' 6. unzip the contents of the downloaded file http+++beta.unity3d.com.zip to the directory 'temporary', so that it is structured like '...\Profiles\zwgzkcmp.testprofile\storage\temporary\http+++beta.unity3d.com\asmjs\' 7. Visit 'http://localhost:8000/' in Nightly. On Windows, this will cause the dialog with the UnknownError failure to show up. Note in particular how unzipping the new data to the cache in step 6 adds new files only to a directory that should relate to the domain 'http://beta.unity3d.com/', but in the STR, the unrelated domain 'http://localhost:8000/' is visited, so this failure causes an error to occur "cross-domain". It looks like the error that is raised does not come from IndexedDB after all, but from asm.js caching machinery. Luke, can you give this a peek?
Flags: needinfo?(luke)
I can reproduce the console "Unable to find type [UnityEngine.dll]UnityEngine.AssemblyIsEditorAssembly" error on Chrome and FF release/nightly, so that doesn't seem related. The InvalidStateError exception looks related to DOM event-handling internals: https://w3c.github.io/dom/#dom-domexception-invalid_state_err This UnknownError thing in the last comments on first glance seems unrelated and I'm guessing caused by messing around with the storage dir directly, so I'd rather stick with investigating the InvalidStateError initially. Martin, do you also see the InvalidStateError in your console? Alon/Jukka; if you're able to repro still, could you print the stack of the 'err' object in UnityErrorHandler in UnityConfig.js? That way we can see what operation is throwing. I'm still trying to find a platform that can repro; can't in any config on Linux so far, I'll try Mac/Windows next.
Flags: needinfo?(luke)
I'm also unable to repro with nightly/beta 32/64-bit builds on Win/Mac. If anyone can reproduce still, some useful data, in addition to the error stack required above, would be whether reproduces with javascript.options.asmjs and/or parallel_parsing set to false.
Let me know if there is a better component for this than Canvas:WebGL...
The stack comes from inside the engine code, "Unable to find type [UnityEngine.dll]UnityEngine.AssemblyIsEditorAssembly " WebGLBenchmark.js:1:228468 _JS_Log_Dump() WebGLBenchmark.js:1 hEd() WebGLBenchmark.js:13 fEd() WebGLBenchmark.js:13 Nmd() WebGLBenchmark.js:13 ryc() WebGLBenchmark.js:9 ppd() WebGLBenchmark.js:13 lpd() WebGLBenchmark.js:13 Vpd() WebGLBenchmark.js:13 $pd() WebGLBenchmark.js:13 zJb() WebGLBenchmark.js:29 ZOb() WebGLBenchmark.js:29 oWf() WebGLBenchmark.js:53 callMain() WebGLBenchmark.js:110 doRun() WebGLBenchmark.js:110 run/<() WebGLBenchmark.js:110 I actually can not currently see the error on my normal nighty profile. But on another (which I used to bisect in the range from before), I can. It still reproduces with asm or parallel parsing turned off. I can also reproduce the bug on my normal profile (where I don't currently see it) in a private browsing window, perhaps that helps to reproduce?
The 'Unable to find...' message can be safely ignored. The UnknownError/InvalidStateError is the actual error in this bug report, and I believe they are caused by the same root problem, but manifest as different messages on different OSes. It is not caused by messing around with storage directory directly, but I don't have any other STR to give to you to reliably reproduce the message otherwise. I did not manually edit the storage files, but just copied the directory off from an existing profile. Yes, there is a chance that copying the directory is not valid and that it is giving the error for a different reason, but there's also a good chance it is carrying the original error along with it, since the error message is preserved. Luke, did you try my STR? I did change the message to print the stack, but it just says undefined in both Windows and Linux, and the stack trace in the console shows only the windows.onerror handler in function UnityErrorHandler().
(In reply to Alon Zakai (:azakai) from comment #11) I meant the InvalidStateError exception; as Jukka said, that's the real bug. That the error repros with asmjs/parallel_parsing turned off likely rules out JS. I'm still expecting this to either be IDB or a timing-related issue (e.g. if a certain download finishes before/after a certain IDB operation completes). (In reply to Jukka Jylänki from comment #12) > Luke, did you try my STR? Yes and indeed it is a red herring caused by manual storage-dir modification corrupting the internal metadata files the FF quota management system maintains. When attempting to use the asm.js cache, the FF temporary quota system is initialized which reads all the metadata for all the origins (that's why this effect is visible cross-origin) and throws. I'd like to add that this is the general *origin* metadata file. For the origin's *asm.js* metadata and cache files, we embed the FF buildid in the metadata/cache file and, upon mismatch/failure, clobber. The argument could be made to make the general FF quota system more robust in the face of ad hoc corruption; but that's a separate bug. > I did change the message to print the stack, but it just says undefined in > both Windows and Linux, and the stack trace in the console shows only the > windows.onerror handler in function UnityErrorHandler(). I think that means that the error is occurring asynchronously and then being reported directly from the event loop.
Alon, can you confirm that the error doesn't manifest in a fresh profile on any of your FF builds? If so, this SO issue http://stackoverflow.com/questions/13972385/invalidstateerror-while-opening-indexeddb-in-firefox suggests that this could be an IDB versioning issue. I'm going to speculatively move this to DOM:IDB since WebGL doesn't seem to be the issue. Even if this is a Unity/Emscripten bug, perhaps they could help us diagnose this so we could resolve invalid.
Component: Canvas: WebGL → DOM: IndexedDB
Can you confirm that something breaks if one copies files in the asmjs cache from one profile to another? In the original profile, I get the UnknownError without any modifications made to the profile files. I just copied the files from this one directory in the bad profile to a fresh profile, and that seems to carry the UnknownError error message over that the original profile also had. Is there a reason to think that after this process, the new UnknownError that is received would be somehow different from the UnknownError that the original profile gave?
Yeah, if I mess around with the contents of $ORIGIN/asmjs, there is no error, you just get new cache files written. I don't know what happened to your original metadata file. That is a file written by the general quota system, not the asmjscache, so perhaps it was originally caused by a bug (maybe janv wants to take a look at the metadata file in the attachment?). I still expect this is different than what Martin/Alon are seeing.
Does anyone have a copy of the original unity benchmark build? If so, a great experiment would be to create a fresh profile, run original, close tab, then run new.
I tested on 2 more machines. I do *not* see the bug on a new profile. However, I **always** see the bug when I open a private browsing window. It seems in private browsing that less is loaded from the cache (slower startup over slow wifi), but not sure how exactly that would cause the difference. Not sure why I could see it without private browsing on one machine (maybe less disk space free, less caching?). But, at least opening a private browsing windows seems like a predictable STR, on 3/3 of my machines. Luke, did you try that? Benchmark/metrics people might have a local copy of the original unity build here.
(In reply to Luke Wagner [:luke] from comment #14) > If so, this SO issue > http://stackoverflow.com/questions/13972385/invalidstateerror-while-opening- > indexeddb-in-firefox suggests that this could be an IDB versioning issue. So much has changed since FF17, I don't know if that is really relevant...
Can someone record this on Linux with rr (http://rr-project.org/)?
Good point Alon, I can finally see this reproduce in private browsing.
Luke, also, InvalidStateError is used by several components... IDB does use it, but we call it NS_ERROR_DOM_INDEXEDDB_NOT_ALLOWED_ERR for historical reasons... http://mxr.mozilla.org/mozilla-central/ident?i=NS_ERROR_DOM_INDEXEDDB_NOT_ALLOWED_ERR is all the places we throw it. Usually it's a real exception because you misused the API. It's rare that we fire an error event with that code.
I can actually see the InvalidStateError (on the main URL http://beta.unity3d.com/jonas/WebGLBenchmark/) in private browsing in Nightly through Release.
Darn, Ben tells me that IDB basically just doesn't work in private browsing. So I think we still need some work to find some good STR for the real issue here.
:mschifer, we need some help with STR. Can you work some QE magic?
Flags: needinfo?(mschifer)
In private browsing, I can reproduce this problem on 35 (release), as well. I was also able to reproduce it *without* private browsing on 35. I had to create a fresh profile, use the profile in a later version for a while, then use it in 35. Something happens that puts the profile data in a bad state. When using a brand new profile that has not been used in other versions, I do not see the problem. So perhaps IDB is the issue here, as shown in private browsing, and somehow we can end up in a bad state in the profile, causing the problem outside of private browsing as well?
Looks IDB related. When I go into the profile directory, if I remove storage/persistent/http+++beta.unity3d.com/ (which contains a subdir idb), then the problem goes away. The directory is then created, and subsequent runs are fine. But, if I restore that directory to the state it was before I removed it (i.e., when the bug was present) then the bug comes right back. So the error is shown due to content in that directory, which looks like just IDB data.
Alon, it looks like there are 'url' and 'line' args to the onerror function; what do they show for one of these InvalidStateErrors?
Good idea! On a local non-minified build, I see the error arise in try { req = IDBFS.indexedDB().open(name, IDBFS.DB_VERSION); // <-- here } catch (e) { return callback(e); } The problem therefore appears to be that we fire window.onerror (which Unity hooks into) even though an exception should be caught.
I may have a partial testcase. Running this in a script tag, window.onerror = function(x, y, z) { console.log('error! ' + [x, y, z]); }; try { var req = indexedDB.open('something', 1); console.log('no problem'); } catch(e) { console.log('nothing to see here'); }; I see the expected result on the main thread, i.e., "no problem". Nothing is thrown, nothing is caught. But when run in private browsing, I see "no problem" as expected, but the console *also* shows InvalidStateError. I also verified in the game that a partially-similar thing happens. That try-catch in the previous comment does *not* catch anything. Execution proceeds as if no error was thrown, but the console does show InvalidStateError, and later window.onerror fires. So what seems to happen is that 1. InvalidStateError is "set internally" in indexedDB.open() in some cases (always in private browsing, other situations too outside of it, if the IDB data in the profile is "bad"). This happens even though no error is visible externally, nothing is thrown. 2. By "set internally" in the previous comment I mean that it shows up in the web console. 3. Sometimes, in addition - in the Unity codebase, but not in my testcase above - window.onerror is fired later, on that InvalidStateError.
(In reply to Alon Zakai (:azakai) from comment #30) > But when run in private browsing, I see "no > problem" as expected, but the console *also* shows InvalidStateError. IndexedDB will *always* fire an error event with |InvalidStateError| when run in private browsing mode. We don't support PB yet. > I also verified in the game that a partially-similar thing happens. That > try-catch in the previous comment does *not* catch anything. Execution > proceeds as if no error was thrown, but the console does show > InvalidStateError, and later window.onerror fires. What's happening here is not an exception being thrown from the |open| method. Rather, an error event is being fired at the request object and not being handled. This code will prevent the message from showing up in the console: var req = indexedDB.open('something', 1); req.onerror = function(event) { // log? event.preventDefault(); };
After those clarifications and discussion on irc, it looks like there is an IndexedDB error here. One possible cause is moving with the same profile between versions of firefox, back and forth (bug 1092090 as pointed out by bent). However the symptoms there are not exactly what we see here. So there is still some mystery about what causes the IDB error. Since we don't see the problem on new profiles, though, it seems like not a common issue. Perhaps all of us here are more likely to (ab)use profiles in weird ways, like moving versions on them, so several of us could reproduce it. In any case, the reason we noticed this is that (1) there is an error, and (2) it is reported to window.onerror, which unity notice and report in a dialog box. Fixing (1) isn't immediately possible, but (2) is arguably a bug in emscripten - we allowed IDB errors to propagate to window.onerror, but we also do handle them internally as best we can. I changed that in emscripten now, so when unity update, the problem should not be visible as it is now. (However, the error still remains, and data might not be successfully stored/loaded from IDB.)
Priority: -- → P5

I do not expect to have STR here anymore.

Flags: needinfo?(mschifer)
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.