If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Assertion failure "Should not have an exception set here!" in OperationCallback

RESOLVED WORKSFORME

Status

()

Core
DOM: Workers
RESOLVED WORKSFORME
4 years ago
4 years ago

People

(Reporter: Yoric, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

See https://tbpl.mozilla.org/php/getParsedLog.php?id=27082009&tree=Try&full=1#error1

Note that the error message is not standard, I have replaced it with something else while attempting to pinpoint the error. The original assertion failure was "Should not have an exception set here!"

STR: Attempting to land bug 891300 makes this a frequent error in xpcshell tests that use OS.File.

From the point of view of JavaScript, the error seems to be sent by the following sequence:

        let xhr = new XMLHttpRequest();
        xhr.open("GET", uri, false);
        xhr.responseType = "text";
        xhr.send(); // Assertion fails here

The code is executed on a worker.
Note: I suspect that the issue is actually caused by XHR and not by webrtc. Cc-ing bent.
This is probably caused by some buffer overflow in js land that cause VoEMediaProcess to appear here. Having VoEMediaProcess in this code makes absolutely no sense anyways. Changing component to JS engine.
Assignee: nobody → general
Component: WebRTC → JavaScript Engine
I strongly suspect that this is a bug in the implementation of XHR for workers. Re-classifying in Workers.
Assignee: general → nobody
Component: JavaScript Engine → DOM: Workers
Summary: Assertion failure "Should not have an exception set here!" in OperationCallback called from webrtc::VoEMediaProcess::VoEMediaProcess → Assertion failure "Should not have an exception set here!" in OperationCallback
Marking as blocker, as this bug prevents me from proceeding with the OS.File refactoring.
Severity: normal → blocker
"blocks something" does not mean the severity is a blocker.
Severity: blocker → normal
Looks like the operation callback is firing during the middle of exception handling?
(In reply to Kyle Huey [:khuey] (khuey@mozilla.com) from comment #5)
> "blocks something" does not mean the severity is a blocker.

True. This bug is still quite annoying for me as it prevents a pile of refactorings from landing.
The STR cannot be reproduced anymore, so I guess something was fixed somewhere.
Closing.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Resolution: FIXED → WORKSFORME
You need to log in before you can comment on or make changes to this bug.