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
I strongly suspect that this is a bug in the implementation of XHR for workers. Re-classifying in Workers.
Assignee: general → nobody
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] (email@example.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: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.