Closed Bug 1400478 Opened 7 years ago Closed 6 years ago

Intermittent devtools/client/netmonitor/test/browser_net_filter-04.js | application crashed [@ js::GCMarker::processMarkStackTop]

Categories

(Core :: JavaScript: GC, defect, P5)

Product:
Core
Component:
JavaScript: GC
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: intermittent-bug-filer, Assigned: jonco)

References

(Blocks 1 open bug)

Details

(Keywords: crash, intermittent-failure, Whiteboard: [stockwell unknown])

Crash Data

Attachments

(1 file)

bug1400478-comp-mismatch-info
1.94 KB, patch
sfink
: review+
Details | Diff | Splinter Review
Blocks: GCCrashes
Component: Developer Tools: Netmonitor → JavaScript: GC
Product: Firefox → Core
Not a fix.  This looks like the compartment checking assertion failing, so here's a patch to dump some more useful info if it happens again.
Assignee: nobody → jcoppeard
Attachment #8909879 - Flags: review?(sphink)
Keywords: leave-open
Comment on attachment 8909879 [details] [diff] [review]
bug1400478-comp-mismatch-info

Review of attachment 8909879 [details] [diff] [review]:
-----------------------------------------------------------------

::: js/src/gc/Marking.cpp
@@ +1668,5 @@
> +#ifdef DEBUG
> +    if (MOZ_UNLIKELY(obj->compartment() != obj2->compartment())) {
> +        fprintf(stderr, "Compartment mismatch in from %s object slot to %s object\n",
> +                obj->getClass()->name, obj2->getClass()->name);
> +        MOZ_CRASH("Compartment mismatch");

"in from"? "in pointer from", maybe?

Does stderr go somewhere useful on eg Windows? I'm pretty sure it doesn't on Android, but we probably don't care.

I suppose you could use MOZ_CRASH_UNSAFE_PRINTF, but then you'd need to get data review. stderr is fine with me.
Attachment #8909879 - Flags: review?(sphink) → review+
Pushed by jcoppeard@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/38375565ef08
Dump object class info if we find a compartment mismatch during marking r=sfink
(In reply to OrangeFactor Robot from comment #11)
None of the crashes in comment 11 match this signature.
Whiteboard: [stockwell needswork]
There have been 32 failures in the last week.
All the failures occur on debug build type.

Failures per platform:
-	windows10-64: 12
-	linux64-stylo-disabled: 4
-	Linux: 4
-	Linux x64: 3
-	linux32-stylo-disabled: 3
-	Windows 7: 3
-	OS X 10.10: 2
-	windows10-64-ccov: 1

Here is a recent relevant log file and a snippet with the failure:
https://treeherder.mozilla.org/logviewer.html#?repo=mozilla-inbound&job_id=165940177&lineNumber=17282

09:42:03     INFO -  GECKO(8340) | ++DOMWINDOW == 17 (0000017DE1D93400) [pid = 8340] [serial = 20] [outer = 0000000000000000]
09:42:04     INFO -  GECKO(8340) | ++DOMWINDOW == 18 (0000017DED9AC000) [pid = 8340] [serial = 21] [outer = 0000017DE755B800]
09:42:04     INFO -  GECKO(8340) | ++DOMWINDOW == 19 (0000017DEB6D4000) [pid = 8340] [serial = 22] [outer = 0000017DE1D93400]
09:42:04     INFO -  GECKO(8340) | Assertion failure: mPresContext->mLayoutPhaseCount[eLayoutPhase_FrameC] == 0 (display list building in the middle of frame construction), at z:/build/build/src/layout/base/nsAutoLayoutPhase.cpp:51
09:42:04     INFO -  GECKO(8340) | #01: nsAutoLayoutPhase::nsAutoLayoutPhase(nsPresContext *,nsLayoutPhase) [layout/base/nsAutoLayoutPhase.cpp:22]
09:42:04     INFO -  GECKO(8340) | #02: nsDisplayListBuilder::EnterPresShell(nsIFrame *,bool) [layout/painting/nsDisplayList.cpp:1332]
09:42:04     INFO -  GECKO(8340) | #03: nsSubDocumentFrame::BuildDisplayList(nsDisplayListBuilder *,nsDisplayListSet const &) [layout/generic/nsSubDocumentFrame.cpp:425]
09:42:04     INFO -  GECKO(8340) | #04: nsIFrame::BuildDisplayListForStackingContext(nsDisplayListBuilder *,nsDisplayList *,bool *) [layout/generic/nsFrame.cpp:3066]
The last association is wrong (should be bug 1454751).  No reports for four months so maybe we can close this.  Please reopen if necessary.
Status: NEW → RESOLVED
Closed: 6 years ago
Keywords: leave-open
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: