Closed Bug 531961 Opened 16 years ago Closed 13 years ago

top crash [@ nsCycleCollector::MarkRoots(GCGraphBuilder&)]

Categories

(Core :: XPCOM, defect)

Product:
Core
Component:
XPCOM
Version:
1.9.1 Branch
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: peterv, Assigned: mccr8)

References

Details

(Keywords: crash, topcrash, Whiteboard: [crashkill])

Crash Data

Bug 437449 probably fixed a bunch of these on 1.9.2 and trunk, but this is also a topcrash on 1.9.1 and there must be a different cause for those. Interestingly the correlation data for November 29th show this: _purecall | nsCycleCollector::MarkRoots(GCGraphBuilder&)|No crash (11 crashes) 82% (9/11) vs. 1% (1369/94002) {6E19037A-12E3-4295-8915-ED48BC341614} (*xg.dll (RelevantKnowledge), http://www.relevantknowledge.com/) It's a small sample, and the reports from other days don't show such a correlation, so it might just be a coincidence.
We don't know that the remaining problem doesn't happen on 1.9.2 as well, right? Should know better once we have a release out with bug 437449 fixed.
We don't currently know, no.
here is a crack at where the nsCycleCollector::MarkRoots crashes are happening across the main releases that we are tracking. looks pretty uniform across all releases that have +200k users checking --- 20091130-crashdata.csv nsCycleCollector::MarkRoots release total-crashes nsCycleCollector::MarkRoots crashes pct. total 233706 1231 0.0052673 3.0.15 50334 218 0.00433107 3.5.5 122547 724 0.00590794 3.6b4 16576 128 0.00772201 3.6b3 2703 19 0.00702923 3.6b2 1193 3 0.00251467 3.6b1 2776 6 0.00216138
This is still showing up in b5.
ranks #14 for 3.5.6, #8 for 3.6b4, and currently #5 for very early 3.6b5 data.
Peter, are you still on this? Still #5 top crasher.
Yeah, still looking at this. Unfortunately we don't have a testcase, so I'm trying to figure it out from looking at assembly in minidumps. I'm not making a lot of progress, maybe IDA will help me understand the assembly better :-/.
Hi there, I am a regular Firefox user who experiences this problem on a regular basis. I am more than willing to help if I can. I have sent an e-mail to PeterV with more details - just wanted to also post here in case it is a dummy e-mail address. I'm rooting for you guys to fix this, and let me know if I can help.
I just got this crash and was reading through my reports. It lists my CPU as an x86 when it is a 64-bit proc. I'm not sure if it's just because I'm using the 32-bit version of the browser but it seems incorrect to label my CPU as an x86 since maybe me using a 64-bit processor and the 32bit/x86 version of FF affects whether this causes a crash or not.
Severity: normal → critical
#22 crash for FF 3.6.13 I mistook this bug as being only for 1.9.1 and filed bug 622411. But rereading some comments I see that isn't necessarily the case. (In reply to comment #1) > We don't know that the remaining problem doesn't happen on 1.9.2 as well, > right? Should know better once we have a release out with bug 437449 fixed. (In reply to comment #2) > We don't currently know, no.
#31 on 5.0 on its current beta state...
Crash Signature: [@ nsCycleCollector::MarkRoots(GCGraphBuilder&)]
See Also: → 622411
There seems to be a user sending such crashes in bug 695029.
Depends on: 695029
This is still a valid top crasher. Appearing at #29 on 8.0 over the past week.
Still high on our list. At #17 on 10.0.1 and #20 on 10.0.
At a glance, this looks similar to bug 500105: lots of null derefs, probably on stuff being pulled out of a NodePool enumerator.
I guess I'll look into it at the same time I look into 500105.
Assignee: peterv → continuation
Depends on: 727604
No longer depends on: 695029
Hey Andrew, did we ever identify anything useful to do here?
No, my changes didn't turn up anything particularly interesting. I was going to see if anything would turn up on Aurora.
This is sitting at #55 on Fx12. The interesting thing is that it no longer shows up on Fx13, 14 or 15. Could this signature have morphed to something else?
I'm not really sure. Bug 727604 (which I landed just to investigate crashes) changed how some things were inlined, and I noticed after that that a lot of crashes went away, but I never figured out where they went, as that bug shouldn't have eliminated any crashes. I could believe that the signature changed, but I peruse the crash list every few weeks and I never found any one thing it seemed to have turned into. I guess it is possible there was some weird compiler bug that my patch avoided.
(In reply to Andrew McCreight [:mccr8] from comment #22) > I guess it is possible > there was some weird compiler bug that my patch avoided. That said, 13 and higher also are being compiled on a different compiler (version), MSVC10 instead of MSVC8 for 12 and before, so the compiler bug could even be fixed. Should we close this as WFM on the basis of 13+ or should we wait until that is released?
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #23) > Should we close this as WFM on the basis of 13+ or should we wait until that > is released? Whatever you think is best is fine with me. As I said, I have no idea what happened.
Another possibility is that some cycle collector optimization that we landed in 13 somehow avoids touching some particular mangled class.
OK, let's mark it WFM for now, then, we can reopen if it comes back some time.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.