Open Bug 1657025 Opened 1 year ago Updated 7 months ago

Intermittent Assertion failure: gcTotal == rtStats.gcHeapChunkTotal, at /builds/worker/checkouts/gecko/js/xpconnect/src/XPCJSRuntime.cpp:2035

Categories

(Core :: XPConnect, defect, P3)

defect

Tracking

()

People

(Reporter: intermittent-bug-filer, Unassigned)

References

Details

(Keywords: assertion, intermittent-failure, leave-open, Whiteboard: [stockwell unknown])

Attachments

(3 files)

Filed by: geoff [at] darktrojan.net
Parsed log: https://treeherder.mozilla.org/logviewer.html#?job_id=311932359&repo=comm-central
Full log: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/UvK01YR6TpGuPpTh96np9g/runs/0/artifacts/public/logs/live_backing.log


This has been happening on (Thunderbird) Windows 7 debug for a long time, although hidden by other problems. As far as I can see the first instance was in early July, putting it somewhere in this range:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=d2c40e8317a7115c3858c977383363593d9c318e&tochange=2d709e60c76ec75960054105fae65a758d7a5e78

I mean Windows 32-bit.

Any chance of some action here?

It looks like these are all happening on Win32, in a specific test comm/mail/test/browser/composition/browser_forwardedEmlActions.js

This assertion means that the different pieces of JS engine memory reporting didn't add up to what it told us the total was, but I don't know why that would work differently in Thunderbird.

Could this be just a symptom of running out of memory? Given where it's happening that wouldn't surprise me at all.

Flags: needinfo?(continuation)

Maybe we end up allocating a new chunk or running a GC in between when we do these two measurements? If this test is known to be tight on memory that could be the case. I'm not familiar enough with how this reporter works to know if that's possible. Any ideas, Jon?

Flags: needinfo?(continuation) → needinfo?(jcoppeard)

Probably some background task is still allocating/freeing memory. Let's try waiting for all these to finish before collecting stats.

Assignee: nobody → jcoppeard
Flags: needinfo?(jcoppeard)

This adds a new function to wait for all background tasks after a GC has
finished. It does remove the wait on background free task from FinishGC but I
couldn't see anywhere that would matter and try is green with this patch.

I'll do a try-comm-central run with your patch applied. It won't stop the jobs in question failing (I'm pretty sure they're running out of memory) but this assertion should go away.

(In reply to Geoff Lankow (:darktrojan) from comment #17)
Thanks for the update. I'll land the patch anyway and see if anything else comes to mind.

Keywords: leave-open
Pushed by jcoppeard@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/e9b797f6d7db
Wait for all background GC tasks to finish before collecting memory stats r=sfink

Another thing that could be causing this mismatch is off-thread parsing, which
currently allocates GC things.

Pushed by jcoppeard@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/480a0b10c49a
Wait for off-thread parsing to finish before collecting runtime stats r=sfink
Regressions: 1672760

Does this still happen with the second patch applied? You'll want to take the patch bug 1672760 too BTW.

Flags: needinfo?(geoff)

Yes. We build from m-c tip so I assume all of the patches are there now.

Here's a recent failure log, if that helps at all:
https://treeherder.mozilla.org/logviewer?job_id=321945078&repo=comm-central&lineNumber=26171

Flags: needinfo?(geoff)
Priority: -- → P3
Pushed by jcoppeard@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/6c762044624f
Wait for all helper threads to finish before collecting memory stats r=sfink

I'm out of ideas for this.

Assignee: jcoppeard → nobody
You need to log in before you can comment on or make changes to this bug.