Crashes on MemBench with incremental GC enabled

RESOLVED FIXED in mozilla15

Status

()

Core
DOM
--
critical
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: gwagner, Assigned: billm)

Tracking

({crash, regression})

15 Branch
mozilla15
crash, regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(crash signature, URL)

Attachments

(1 attachment)

(Reporter)

Description

5 years ago
This bug was filed from the Socorro interface and is 
report bp-51004ce3-ccbe-4451-90f0-237052120504 .
============================================================= 

Just start http://gregor-wagner.com/tmp/mem and wait a few sec.
(Reporter)

Comment 1

5 years ago
I also see this signatures:
https://crash-stats.mozilla.com/report/index/bp-a1df900b-2ad0-4d2f-9c30-d026c2120504
 https://crash-stats.mozilla.com/report/index/bp-8486489e-8582-47f9-b055-6b3692120504

I hope that's just one bug....
(Reporter)

Comment 2

5 years ago
Important detail: IGC is enabled.
Seems stable without IGC.
I just tried this with a debug Mac build from changeset 40a901a6e733.  No crash....

With igc, is it possible for an object to be finalized more than once?  I'd assume not, right?
(Assignee)

Comment 4

5 years ago
(In reply to Boris Zbarsky (:bz) from comment #3)
> With igc, is it possible for an object to be finalized more than once?  I'd
> assume not, right?

They're only called once.

The second crash seems to be bug 752081.
(Reporter)

Comment 5

5 years ago
A few other signatures I see:
https://crash-stats.mozilla.com/report/index/bp-14cd6291-a85e-462a-9231-5490a2120505
https://crash-stats.mozilla.com/report/index/bp-ed708741-4f91-4f0f-9b89-d264d2120505
https://crash-stats.mozilla.com/report/index/bp-3dd410d9-c428-47da-af69-91a462120505
https://crash-stats.mozilla.com/report/index/bp-b27d692a-2c0a-4ba7-9327-811422120505
https://crash-stats.mozilla.com/report/index/bp-337e32f3-7627-40b5-aa39-0f06e2120505
Duplicate of this bug: 752191
Blocks: 735099
Summary: crash in mozilla::dom::binding::ListBase → Crashes on MemBench with incremental GC enabled
Danial Horton narrowed down the range a bit, but there are around 200 changesets in the range he found, so it is still fairly wide.
I got a similar crash just now with incremental enabled.  Just on Google Reader.

https://crash-stats.mozilla.com/report/index/bp-77c96c0e-9f96-4bc9-bef8-198572120505

Comment 9

5 years ago
if we both started seeing it roughly around the same changesets, then it could be the same thing, especially if his tests was on inbound where the CPG and other stuff was already landed.

for me, 20120503142649 is the last build i could open my usual session on with iGC enabled.

my DSL is flaky at nights atm, which makes diving into the inbound builds a problem.(In reply to Andrew McCreight [:mccr8] from comment #8)

> I got a similar crash just now with incremental enabled.  Just on Google
> Reader.
> 
> https://crash-stats.mozilla.com/report/index/bp-77c96c0e-9f96-4bc9-bef8-
> 198572120505

Yeah, thats pretty much exactly what i had been seeing
I was just using membench in the bug i opened to exacerbate the situation and bring a crash on quicker.

In some cases, all i have to do is merely interact with the ui, even as slight as minimising the window and it might crash while iGC is on.
Yeah, this is pretty terrible.  I'm going to disable incremental GC for now.  There are one or two other reports of crashy IGC in bug 654903.

Comment 11

5 years ago
alright, i just dropped my sync speed a bit, i'll get a few inbound zips downloading and set up a profile with igc enabled to run through membench till i find where it stops crashing
Well, there's already one patch in that range that is known to have caused a regression (bug 730208), and there's a patch to fix it, but it just hasn't landed yet.  Probably a good place to start would be to look at builds before that landed.

Comment 13

5 years ago
Regression window(m-i)

Works:
http://hg.mozilla.org/integration/mozilla-inbound/rev/c3813fbb1c9a
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/15.0 Firefox/15.0a1
ID:20120502040217

Fails:
http://hg.mozilla.org/integration/mozilla-inbound/rev/de5745bce8bc
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/15.0 Firefox/15.0a1
ID:20120503040220

Comment 14

5 years ago
installed memchaser and nightly tools to be sure of my findings... which had the effect of making the regression appear quicker in 20120503040220

Updated

5 years ago
Keywords: regression
Version: unspecified → 15 Branch

Comment 15

5 years ago
This doesn't appear to be osx only, so platform might do with changing to All All?

now all we need is someone to test iGC on a droid and see if it happens there for a trifecta....

Updated

5 years ago
OS: Mac OS X → All
(Assignee)

Comment 16

5 years ago
I'll work on this soon. It sounds like it's affecting a lot of people.
Blocks: 654903

Comment 17

5 years ago
You sure Andrew?, that crash seems to predate this particular regression.
Bug 654903 likely has many causes.  This bug is one of them, for people who have incremental GC turned on.

Comment 19

5 years ago
initial report in bug 654903 is not likely to be caused by incremental GC at all, the last 4 or so comments in it are related to this issue, but that doesn't mean the overall bug is.

I remember getting that particular crash earlier last year though and thought it had since been resolved (something specific to JIT and certain extensions?)
(Reporter)

Updated

5 years ago
Duplicate of this bug: 752327
(Assignee)

Comment 21

5 years ago
Created attachment 621785 [details] [diff] [review]
patch

Thanks for the bisection, Daniel. It helped a lot.

The main problem is that, while the gcIsFull flag is set during BeginMarkPhase, we're using it during the sweep phase. So it's possible for a compartment to be created in between and not have its script filenames marked, but it will get them swept.

One possible solution is to change the gcIsFull flag so that it's set during sweeping. But then we might set mark bits but not sweep, which is sort of bad, although only theoretically. Generally I think it's better to set flags like this in the first slice and then leave them alone. Otherwise it gets really confusing what should be marked.

The solution I've chosen is to ensure that all new script filenames are marked. This includes ones created for new compartments.

The right solution for this is bug 751618.
Assignee: nobody → wmccloskey
Status: NEW → ASSIGNED
Attachment #621785 - Flags: review?(luke)

Comment 22

5 years ago
Comment on attachment 621785 [details] [diff] [review]
patch

Thanks to you both!
Attachment #621785 - Flags: review?(luke) → review+
(Assignee)

Comment 23

5 years ago
https://hg.mozilla.org/mozilla-central/rev/cf9354f3a976
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED

Comment 24

5 years ago
Ok so Lukes patch is a temporary fix till bug 751618 is looked into and implemented? (coz if thats the full fix, it just did my head in... a single line... xD)
(Assignee)

Comment 25

5 years ago
(In reply to Danial Horton from comment #24)
> Ok so Lukes patch is a temporary fix till bug 751618 is looked into and
> implemented? (coz if thats the full fix, it just did my head in... a single
> line... xD)

This is a real fix for the problem. Bug 751618 would just solve it in a cleaner way. Sometimes scary bugs have simple fixes :-).

Comment 26

5 years ago
be nice if 20120507 could get a respin just for this, understandably we don't always get nice things :-(

i'll check out the hourly if i remember. thanks for the quick fix guys

Updated

5 years ago
Target Milestone: --- → mozilla15

Updated

5 years ago
Blocks: 702531
Duplicate of this bug: 752392
You need to log in before you can comment on or make changes to this bug.