Unfortunately there is some little misalignment between the stack trace and the source files in the pernosco session, in particular at `ServiceWorkerJob::InvokeResultCallbacks () at /ServiceWorkerJob.cpp:157`, which contains the most interesting pieces. The assertion happens during the destruction of an `ErrorResult` somewhere within `ServiceWorkerJob::InvokeResultCallbacks ()` (and not in any called-from-there function, it seems). But looking at the current code in searchfox the local rv seems to be safe, as `rv.SuppressException();` is being called before it leaves the scope boundary. And I see no way how this destructor could have been called earlier on that local object, unless the compiler optimized out `rv.SuppressException()`, which I cannot believe but did not check. Or maybe yes, I can believe, as this code might be inlined and sets a value, that is never used inside the loop except inside the destructor, which might not be relevant for the compiler for this kind of optimization? Anyway, :tsmith, is there a chance to get an aligned pernosco trace? Thank you!
Bug 1606157 Comment 19 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Unfortunately there is some little misalignment between the stack trace and the source files in the pernosco session, in particular at `ServiceWorkerJob::InvokeResultCallbacks () at /ServiceWorkerJob.cpp:157`, which contains the most interesting pieces. The assertion happens during the destruction of an `ErrorResult` somewhere within `ServiceWorkerJob::InvokeResultCallbacks ()` (and not in any called-from-there function, it seems). But looking at the current code in searchfox the local rv seems to be safe, as `rv.SuppressException();` is being called before it leaves the scope boundary. And I see no way how this destructor could have been called earlier on that local object, unless the compiler optimized out `rv.SuppressException()`, which I cannot believe but did not check. Or maybe yes, I can believe, as this code might be inlined and sets a value that is never used inside the loop except inside the destructor, which might not be relevant for the compiler for this kind of optimization? Anyway, :tsmith, is there a chance to get an aligned pernosco trace? Thank you!