Closed Bug 1395390 Opened 7 years ago Closed 7 years ago

Permafailing CCov dom/indexedDB/test/unit/test_wasm_serialize_tiering.js | xpcshell return code: -11

Categories

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

Product:
Core
Component:
Storage: IndexedDB
Type:
defect

Tracking

()

Status:
RESOLVED INCOMPLETE

People

(Reporter: intermittent-bug-filer, Unassigned)

References

Details

(Keywords: intermittent-failure, Whiteboard: [stockwell needswork:owner])

Depends on: 1393723
Summary: Permafailing dom/indexedDB/test/unit/test_wasm_serialize_tiering.js | xpcshell return code: -11 → Permafailing CCov dom/indexedDB/test/unit/test_wasm_serialize_tiering.js | xpcshell return code: -11
Hi Jan, the failure rate of this newly added test case is quite high. Could you please take a look and propose a solution? Thank you.
Flags: needinfo?(jvarga)
For a bit of context, we've had web assembly tests fail in the past on jsdcov and they have been disabled - bug 1336727. (Though this is the first, that I know of, that fails on ccov).
does it make sense to not run this test in code coverage mode?  often the act of collecting code coverage can cause some tests to act in unfortunate ways.
Luke wrote this test so maybe he has an idea?
Flags: needinfo?(luke)
Priority: -- → P2
Looking at the logs there is a very simple crash:
  PID 9771 | Hit MOZ_CRASH(nsObserverService not thread-safe)
which would probably be pretty easy to understand if we could get the C++ crash stack.  I usually see those in logs; is there anything we can do to get one here?

(In general, I'm fine just disabling the test if there's something weird about CCov, but I'd be interested to try a bit to understand who's calling the observer service off the main thread and if this can happen in non-CCov runs.)
Flags: needinfo?(luke)
(In reply to Luke Wagner [:luke] from comment #8)
> Looking at the logs there is a very simple crash:
>   PID 9771 | Hit MOZ_CRASH(nsObserverService not thread-safe)
> which would probably be pretty easy to understand if we could get the C++
> crash stack.  I usually see those in logs; is there anything we can do to
> get one here?

Maybe we don't have the crash stack because of the presence of "ac_add_options --disable-crashreporter" or the absence of "ac_add_options --enable-debug-symbols" in the ccov mozconfig [1]?

Ted, do you know?

Joel, do you know why we build with the crash reporter disabled?

[1]: https://dxr.mozilla.org/mozilla-central/source/browser/config/mozconfigs/linux64/code-coverage

> (In general, I'm fine just disabling the test if there's something weird
> about CCov, but I'd be interested to try a bit to understand who's calling
> the observer service off the main thread and if this can happen in non-CCov
> runs.)

There are sometimes differences, but the main one is that the ccov build is slower, so often it can unearth failures which depend on timing.
Flags: needinfo?(ted)
Flags: needinfo?(jmaher)
Yes, if you --disable-crash-reporter you won't get crash stacks.
Flags: needinfo?(ted)
See Also: → 1401814
I see :marco had a patch up to build with crashreporter, lets go with that!
Flags: needinfo?(jmaher)
Interesting, the stream transport service doesn't exist so its created and nsStreamTransportService::Init needs to add an observer via the observer service
It means the stream transport service must be initialized on the main thread.
Flags: needinfo?(jvarga)
Thanks Marco!  Jan: could this bug appear under normal FF runs?
Flags: needinfo?(luke) → needinfo?(jvarga)
(In reply to Luke Wagner [:luke] from comment #14)
> Thanks Marco!  Jan: could this bug appear under normal FF runs?

I guess not, it's probably an xpcshell weirdness.
Flags: needinfo?(jvarga)
Ah, ok.  So is there an easy fix for this?   (Sorry, I'm unfamiliar with all the pieces you mentioned in comment 13.)
We have a place for stuff like this:
https://dxr.mozilla.org/mozilla-central/source/dom/indexedDB/ActorsParent.cpp#20816

It you add stream transport service there it might fix this bug.
Priority: -- → P2
You need to log in before you can comment on or make changes to this bug.