Last Comment Bug 500105 - Crash @ GraphWalker
: Crash @ GraphWalker
Status: NEW
[crashkill][crashkill-debug][tbird cr...
: crash
Product: Core
Classification: Components
Component: XPCOM (show other bugs)
: Trunk
: All All
P2 critical with 8 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
: Nathan Froyd [:froydnj]
: 569688 606820 682598 (view as bug list)
Depends on: 500189 727604
Blocks: 557161
  Show dependency treegraph
Reported: 2009-06-23 18:57 PDT by Samuel Sidler (old account; do not CC)
Modified: 2017-01-18 04:13 PST (History)
46 users (show)
dsicore: blocking1.9.2-
samuel.sidler+old: wanted1.9.0.x+
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

v1 (549 bytes, patch)
2009-09-30 23:29 PDT, Peter Van der Beken [:peterv]
dbaron: review-
Details | Diff | Splinter Review
Add some debugging help (2.99 KB, patch)
2009-10-06 17:35 PDT, Peter Van der Beken [:peterv]
no flags Details | Diff | Splinter Review
Add some debugging help (4.02 KB, patch)
2009-10-15 11:14 PDT, Peter Van der Beken [:peterv]
no flags Details | Diff | Splinter Review
Add some debugging help (4.73 KB, patch)
2009-10-23 09:47 PDT, Peter Van der Beken [:peterv]
dbaron: review+
Details | Diff | Splinter Review
Make debugging code bring up breakpad (986 bytes, patch)
2009-12-03 02:34 PST, Peter Van der Beken [:peterv]
dbaron: review+
Details | Diff | Splinter Review

Description User image Samuel Sidler (old account; do not CC) 2009-06-23 18:57:38 PDT
The current #7 topcrash occurs with a signature of GraphWalker::DoWalk(nsDeque&).

This crash occurs across platforms (Mac and Windows so far).

All crash signatures look like this one, taken from bp-a6c2a662-3402-487e-b4b7-a45442090623, sometimes ending on frame 0, sometimes with the GraphWalker::DoWalk line not repeated:

Frame  	Module  	Signature  	Source
0 	xul.dll 	GraphWalker::DoWalk(nsDeque&) 	xpcom/base/nsCycleCollector.cpp:1186
1 	xul.dll 	GraphWalker::DoWalk(nsDeque&) 	xpcom/base/nsCycleCollector.cpp:1182
2 	xul.dll 	GraphWalker::WalkFromRoots(GCGraph&) 	xpcom/base/nsCycleCollector.cpp:1170
3 	xul.dll 	nsCycleCollector::BeginCollection() 	xpcom/base/nsCycleCollector.cpp:2469 

Lars: Can you grab some URLs for this issue from Socorro?
Comment 1 User image K Lars Lohn [:lars] [:klohn] 2009-06-24 07:45:27 PDT
Bug 500189 has URLs for Firefox 3.5, 3.5pre and 3.5b99 (in that order)
Comment 3 User image Daniel Veditz [:dveditz] 2009-06-25 12:05:49 PDT
Haven't people learned by now? Porn kills (your computer). Seriously -- ask yourself. If some porn costs a lot of money or a subscription fee, why is some of it free? Is it perhaps because they have an alternate revenue stream: installing malware?
Comment 4 User image Samuel Sidler (old account; do not CC) 2009-06-25 14:53:25 PDT
Note: This also happens on 1.9.0 (currently #12 overall).
Comment 5 User image Samuel Sidler (old account; do not CC) 2009-06-25 18:44:20 PDT
See also bug 437449, another cycle collector topcrash.
Comment 6 User image Samuel Sidler (old account; do not CC) 2009-06-25 19:08:32 PDT
Peterv: Can you take a look at the crash reporter stack above and see if there's any problem we can fix here?
Comment 7 User image Dirkjan Ochtman (:djc) 2009-07-28 00:39:32 PDT
I got one as well, seemingly without interaction. (Internal URLs only, sorry.)
Comment 8 User image mobqueen184 2009-07-30 22:37:00 PDT
Hmmnnnn, my laptop seemed to have crashed on a specific link ({%22show_user_id%22%3A%22152617042%22})
THis is the crashing thread i got:

Frame  	Module  	Signature [Expand]  	Source
0 	xul.dll 	GraphWalker::DoWalk 	xpcom/base/nsCycleCollector.cpp:1186
1 	xul.dll 	GraphWalker::DoWalk 	xpcom/base/nsCycleCollector.cpp:1182
2 	xul.dll 	GraphWalker::WalkFromRoots 	xpcom/base/nsCycleCollector.cpp:1170
3 	xul.dll 	nsCycleCollector::BeginCollection 	xpcom/base/nsCycleCollector.cpp:2469

Show/hide other thread
Comment 9 User image mixxster 2009-08-24 08:45:06 PDT
We have a Windows XP desktop suffering from these crashes when it runs Firefox 3.5.2, at least twice a day we encounter the problem.
The only way we have been able to avoid this bug is to downgrade to the Firefox 3.0.xx branch.

Often this occurs as soon as a link is clicked, but we find this hard to reproduce, it seems to be a very unpredictable occurrence.

We may be having a related BSOD that crashes the entire system, which we never get while running Firefox 3.0.13 or earlier builds.
Comment 10 User image Mike Beltzner [:beltzner, not reading bugmail] 2009-09-25 12:37:57 PDT
Johnny/Jonas: we need to figure this out before we ship Firefox 3.6
Comment 11 User image Peter Van der Beken [:peterv] 2009-09-30 23:29:08 PDT
Created attachment 403974 [details] [diff] [review]

I'm not completely sure this is what causes the crash, but it seems like it potentially could. The iterator always increments mPointer, even after it just jumped to the start of a new block. I think one potential crash is that if mLastChild is set to the first pointer of the block, we could end up reading uninitialized memory because the iterator wouldn't stop since it would skip over the first pointer when doing operator++ (we do |child = pi->mFirstChild, child_end = pi->mLastChild; child != child_end; ++child|). When writing we don't use an iterator, so we do write to the first pointer of the block.
Comment 12 User image David Baron :dbaron: ⌚️UTC-8 2009-09-30 23:40:24 PDT
Comment on attachment 403974 [details] [diff] [review]

I think the code looks correct to me as it is now; the idea here is that iterators never point to the first pointer in a block; instead they point to the null sentinel at the end of the previous block (or in the pool itself) and dereferencing an iterator pointing to the sentinel (see operator*) returns the first pointer in that next block.  I think this simplified things in other ways, e.g., by allowing us to create a valid iterator for the position after the end of a block before we've created the next block.  I certainly should have documented that better, though.
Comment 13 User image Peter Van der Beken [:peterv] 2009-10-06 17:35:21 PDT
Created attachment 404970 [details] [diff] [review]
Add some debugging help

This adds a number of aborts when certain conditions fail (pointers outside of blocks, null pointers where we didn't expect it, ...). I think we should try to land this on trunk to get some more data out of crash reports. I'm also still looking into adding more stuff on the stack, so we can get more out of minidumps.
Comment 14 User image Peter Van der Beken [:peterv] 2009-10-15 11:14:09 PDT
Created attachment 406482 [details] [diff] [review]
Add some debugging help

I'd like to land this on trunk (only), but only until we have a couple of crash reports and minidumps. The aborts will probably move the crash to a different spot, but that should give us slightly more data to go on.
Comment 15 User image David Baron :dbaron: ⌚️UTC-8 2009-10-23 09:11:47 PDT
How is this going to help; NS_ABORT_IF_FALSE is DEBUG-only.  Don't you want runtime aborts?
Comment 16 User image David Baron :dbaron: ⌚️UTC-8 2009-10-23 09:17:12 PDT
Other than that, this looks fine, though.  Hopefully it won't be a performance hit.  Sorry for the delay in getting to it...
Comment 17 User image Peter Van der Beken [:peterv] 2009-10-23 09:21:19 PDT
Grmbl, I misread nsDebug.h, I'll switch to NS_RUNTIMEABORT.
As for performance, I ran this through tryserver. Most of the numbers didn't really change, shutdown numbers changed a bit but some were down, so not sure how much I need to care about the ones that went up.
Comment 18 User image David Baron :dbaron: ⌚️UTC-8 2009-10-23 09:37:23 PDT
OK, r=dbaron with NS_RUNTIMEABORT (you need to write your own if-statements with that).
Comment 19 User image Peter Van der Beken [:peterv] 2009-10-23 09:47:37 PDT
Created attachment 408038 [details] [diff] [review]
Add some debugging help

I actually went with a CC_RUNTIME_ABORT_IF_FALSE. I'll run this through tryserver again.
Comment 20 User image Peter Van der Beken [:peterv] 2009-10-28 08:27:37 PDT
Debugging help landed (in two pieces):

I think the second piece missed today's nightly.
Comment 21 User image Peter Van der Beken [:peterv] 2009-11-02 09:16:53 PST
Since landing this on trunk there have not been no new reports submitted on this crash, so I don't have any data yet from the logging patches.
Comment 22 User image David Baron :dbaron: ⌚️UTC-8 2009-11-02 09:22:11 PST
Are you sure they wouldn't show up under a different signature?
Comment 23 User image Peter Van der Beken [:peterv] 2009-11-02 11:17:06 PST
I check for signatures GraphWalker::DoWalk(nsDeque&), EdgePool::CheckIterator(Iterator&) and NodePool::CheckPtrInfo(PtrInfo*). I think that should catch them.
Comment 24 User image Damon Sicore (:damons) 2009-11-02 11:41:47 PST
What's next here?
Comment 25 User image Peter Van der Beken [:peterv] 2009-11-02 12:48:46 PST
Comment on attachment 408038 [details] [diff] [review]
Add some debugging help

On the beta the frequency of this crash is slightly higher (though not very high either). If we have a quick new beta I'd like to take this on the branch so it rides along, and we actually get some data.
Comment 26 User image Samuel Sidler (old account; do not CC) 2009-11-02 12:58:54 PST
Peter: This bug is blocking1.9.2. You don't need approval to land that. :)

(We're also planning to update current beta users to a new beta next week, iirc.)
Comment 27 User image Peter Van der Beken [:peterv] 2009-11-03 11:31:08 PST
Comment on attachment 408038 [details] [diff] [review]
Add some debugging help

I asked for approval because this isn't really a fix. But anyway, landed on 1.9.2:

Let's hope we get some reports.
Comment 28 User image Peter Van der Beken [:peterv] 2009-11-08 03:03:12 PST
No new crash reports on trunk or 3.6b2pre :-(.
Comment 29 User image David Baron :dbaron: ⌚️UTC-8 2009-11-08 12:03:01 PST
Might these be useful?
Comment 30 User image Peter Van der Beken [:peterv] 2009-11-09 05:52:33 PST
David, wouldn't those be for bug 437449? That one seemed related to thread-safety issues?
Comment 31 User image David Baron :dbaron: ⌚️UTC-8 2009-11-09 08:49:21 PST
No, the MarkRoots crash has an almost identical statistical profile (core count distribution, module correlations) to this one, and I've been presuming it's the same underlying problem as this one.  It's definitely not a threadsafety problem.
Comment 32 User image Peter Van der Beken [:peterv] 2009-11-10 06:15:31 PST
Well, MarkRoots doesn't have any of the debugging code.
Comment 33 User image Peter Van der Beken [:peterv] 2009-11-12 09:41:45 PST
Two reports on 3.6b2:

I have the minidumps, the debugging code doesn't seem to have helped much. Back to trying to figure things out from the assembly.
Comment 34 User image puffin 2009-11-12 09:54:32 PST
This bug causes frequent intermittent crashes on our Windows XP (SP3) box. There's no single action that precipitates a crash, appearing to be completely random.
Comment 35 User image Peter Van der Beken [:peterv] 2009-11-16 03:59:06 PST
We seem to sometimes have a bogus pointer to the next block. At first I thought we might have a bogus mFirstChild/mLastChild, so we'd walk randomly in the blocks and mistake a null PtrInfo* for the sentinel. But one of the crashes seems to be in the debug code I added, when walking the blocks. We walk the blocks using the blocksize, so in that case we just seem to have a bogus pointer at the right spot (last item in the array). I've looked at the block code again, don't see how it could happen. Maybe something else is corrupting our blocks' memory.
Comment 36 User image Peter Van der Beken [:peterv] 2009-11-17 10:45:25 PST
(In reply to comment #34)
> This bug causes frequent intermittent crashes on our Windows XP (SP3) box.

How frequent? Any chance we could get you to generate a full dump when it crashes (I think we can use DrWatson for that)?
Comment 37 User image Damon Sicore (:damons) 2009-11-23 16:05:44 PST
Comment 38 User image Ted Mielczarek [:ted.mielczarek] 2009-12-02 10:42:57 PST
(In reply to comment #18)
> OK, r=dbaron with NS_RUNTIMEABORT (you need to write your own if-statements
> with that).

The NS_RUNTIMEABORT comments are scary, they sound to me like we wouldn't be able to trigger Breakpad on all platforms with that. Is that really what you want?
Comment 39 User image David Baron :dbaron: ⌚️UTC-8 2009-12-02 12:35:48 PST
I think we should back out the debugging code on m-c and 1.9.2.
Comment 40 User image Peter Van der Beken [:peterv] 2009-12-03 02:21:04 PST
I agree about 1.9.2 ( pushed earlier this week), but I don't see why we want to remove it from m-c yet. I think we should make sure it brings up breakpad, and see if anything shows up on crash-stats then.
Comment 41 User image Peter Van der Beken [:peterv] 2009-12-03 02:34:44 PST
Created attachment 415830 [details] [diff] [review]
Make debugging code bring up breakpad

I'd like to take this on trunk right now (unless we get a patch for bug 532490 in the meantime), and see if anything shows up in crash-stats.
Comment 42 User image Johnny Stenback (:jst, 2010-01-28 14:51:52 PST
Not blocking the first alpha on this bug.
Comment 43 User image Felix Miata 2010-02-25 17:50:03 PST
I got this reported yesterday using Mozilla/5.0 (X11; U; Linux i686; rv: Gecko/20100208 SeaMonkey/2.0.4pre but when it happened again (I presume the same) today the reporter apparently ignored it. Today's current URL was  and I was attempting to return to when the crash occurred. As I was attempting to count the number of tabs open (after restore/restart; 23 counted, 2 left to count, total 25) so as to proceed with this comment, it crashed again, and again reported failed to come up. SM was started from Konsole, and this is that window's resulting output:
The program 'seamonkey-bin' received an X Window System error.
This probably reflects a bug in the program.
The error was 'RenderBadPicture (invalid Picture parameter)'.
  (Details: serial 1998858 error_code 182 request_code 155 minor_code 5)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)
Comment 44 User image Felix Miata 2010-02-26 00:28:00 PST
In 8 or so hours since comment 43 it crashed again, and again. Then the machine locked up and would not reboot into Linux. Main memory failed in a big way according to Memtest86+ 4.0.
Comment 45 User image Damon Sicore (:damons) 2010-06-21 16:12:23 PDT
Moving this to beta2.  Not seeing a lot of movement here, but yell if you think this should block the first beta.
Comment 46 User image chris hofmann 2010-06-21 17:57:10 PDT
is the debugging code talked about in comment 39 - 41 still on mozilla-central? that means it would be going out in beta.  we should figure out if that's a good idea even if we don't have a good understanding of the cause of the crash or the fix yet.
Comment 47 User image Mike Beltzner [:beltzner, not reading bugmail] 2010-07-19 09:05:09 PDT
Moving this to beta3, where it will block hard at least on ensuring that the debugging code has been removed - not sure where it lands as a blocker for the fix.
Comment 48 User image Mike Beltzner [:beltzner, not reading bugmail] 2010-07-29 12:32:05 PDT
Has the debugging code been removed? Can we get an answer to comment 46, please?
Comment 49 User image David Baron :dbaron: ⌚️UTC-8 2010-07-29 15:40:41 PDT
The debugging code is still present in mozilla-central (and thus still needs to be removed).
Comment 50 User image Mike Beltzner [:beltzner, not reading bugmail] 2010-07-30 06:21:49 PDT
PeterV: can we get that debugging code removed by Monday, Aug 2 at 23:00 PT please so we can bump this back off the blocking list as per comment 47
Comment 51 User image Peter Van der Beken [:peterv] 2010-07-30 07:04:32 PDT
I just backed this out.
Comment 52 User image Mike Beltzner [:beltzner, not reading bugmail] 2010-07-30 07:50:51 PDT
Peter's backout is: - thanks!

Moving back to blocking2.0:? for retriage on the crash issue.
Comment 53 User image Benjamin Smedberg [:bsmedberg] 2010-10-05 12:02:57 PDT
*** Bug 569688 has been marked as a duplicate of this bug. ***
Comment 54 User image chris hofmann 2010-10-05 12:33:43 PDT
about 1500 crashes per day.  current volumes per release look like.

checking --- GraphWalker::DoWalk.nsDeque.. 20101003-crashdata.csv
found in: 3.6.10 3.5.13 3.6.8 3.0.19 3.6.3 3.6.6 3.6 3.6.9 3.6.4 3.5b4 3.5.7 3.6b5 3.6.2 3.5.5 3.5.11 3.5.3 3.1b2 3.5.9 3.5.2 3.0b2 3.6b1 3.6.7 3.5.6 3.5.10 3.5 3
.0b5 3.0.5 3.0.17 3.0.10 3.5.8 3.5.12 3.5.1 3.1b3 3.0.9 3.0.6 3.0.18 3.0.15 3.0.14 3.0
release total-crashes
              GraphWalker::DoWalk.nsDeque.. crashes
all     353258  1213    0.00343375
3.6.10  211184  822     0.00389234
3.5.13  17578   112     0.0063716
3.6.8   19390   65      0.00335224

checking --- GraphWalker.scanVisitor.::DoWalk.nsDeque.. 20101003-crashdata.csv
found in: 4.0b6 4.0b2 4.0b4 4.0b7pre 4.0b1 4.0b5 4.0b3 3.7a1
release total-crashes
              GraphWalker.scanVisitor.::DoWalk.nsDeque.. crashes
all     353258  127     0.000359511
4.0b6   24891   87      0.00349524
4.0b2   1209    12      0.00992556
4.0b4   1853    10      0.00539665
4.0b7pre2328    5       0.00214777
Comment 55 User image Benjamin Smedberg [:bsmedberg] 2010-10-14 12:50:59 PDT
Not a serious regression, and without clues as how to reproduce probably not a blocker. I'd love to have more information, though. Correlation reports would be especially helpful.
Comment 56 User image Matthias Versen [:Matti] 2010-10-24 10:19:40 PDT
*** Bug 606820 has been marked as a duplicate of this bug. ***
Comment 57 User image Edgar Hatchel 2010-10-24 10:59:34 PDT
So is this saying that the bug still exists from all the way back to 2009-06-23 18:57:38 PDT? That it still hasn't been fixed? If so is there an ETA of a fix?
Comment 58 User image David Baron :dbaron: ⌚️UTC-8 2010-10-24 11:19:14 PDT
Nobody knows how to cause the crash to happen, and as a result no developer has been able to observe the crash happening and figure out why.
Comment 59 User image Edgar Hatchel 2010-10-24 12:05:04 PDT
Thanks at least I have an answer to the question.
Comment 60 User image Scoobidiver (away) 2011-01-08 01:01:18 PST
It is #9 top crasher in 4.0b8 for the last week.
Comment 61 User image Scoobidiver (away) 2011-01-17 01:36:59 PST
Still #9 in 4.0b9.

GraphWalker<scanVisitor>::DoWalk(nsDeque&)|EXCEPTION_ACCESS_VIOLATION_READ (85 crashes)
     18% (15/85) vs.   6% (805/14431) {AB2CE124-6272-4b12-94A9-7303C7397BD1} (Skype)
     26% (22/85) vs.  14% (2016/14431) {d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d} (Adblock Plus,
     25% (21/85) vs.  16% (2373/14431)
     13% (11/85) vs.   7% (1020/14431) {CAFEEFAC-0016-0000-0022-ABCDEFFEDCBA} (Java console)
     92% (78/85) vs.  87% (12517/14431) (Mozilla Labs - Test Pilot,
Comment 62 User image Brian Carpenter [:geeknik] 2011-02-13 15:25:23 PST
Minefield just crashed on me while I was away from my PC, the crash report pointed me here.
Comment 63 User image chris hofmann 2011-03-07 10:10:26 PST
doesn't seem to be associated with start up (only about 10% of crashes are within first 3 minutes of start up.

also no pattern in urls.  looks like just general browsing.

domains of sites
 105 \N//
   6 about:blank//

I notice about 50% of reports might have unversioned .dll's around FFExternalAlert.dll zipfldra.dll UnlockerHook.dll MGKBHook.dll FFExternalAlert.dll AlotXpcom.dll BRNstFF.dll Iminent.XPCOM.dll GrabXpcom.dll GrabKernel.dll UnlockerHook.dll ActWndHk.dll frozen.dll googletoolbar-ff3.dll googletoolbar-ff3.dll frozen.dll GrabKernel.dll GrabXpcom.dll GrabXpcom.dll GrabKernel.dll googletoolbar-ff3.dll frozen.dll BTKeyInd.dll RadioWMPCore.dll FFExternalAlert.dll newdll.dll UnlockerHook.dll dll.dll UKHook40.dll lpxpcom.dll googletoolbar-ff3.dll frozen.dll UKHook40.dll FFExternalAlert.dll
Comment 64 User image Scoobidiver (away) 2011-03-12 09:19:23 PST
It starts showing up as #4 top crasher in 4.0 RC1.

Some comments say:
"I was on the Addons page, and had clicked to go to top rated personas when it crashed."
"was downloading some stuff and got booted off the internet"
"Just looking around on Amazon"
Comment 65 User image Robert Kaiser 2011-06-07 11:41:48 PDT
#10 on 5.0b3 right now, FWIW.
Comment 66 User image Scoobidiver (away) 2011-06-07 11:48:50 PDT
(In reply to comment #65)
> #10 on 5.0b3 right now, FWIW.
And #3 top crasher without hangs.
Comment 67 User image Andrew McCreight [:mccr8] 2011-09-19 14:24:13 PDT
*** Bug 682598 has been marked as a duplicate of this bug. ***
Comment 68 User image Phil Ringnalda (:philor) 2011-11-24 00:40:51 PST - so there's one way to repro, run mochitest-other 50K times (or however many pushes we've actually triggered builds for), you'll hit it once.
Comment 69 User image Sheila Mooney 2011-12-07 10:22:15 PST
Still appears consistently in the top 20 crashes for releases. Can we investigate this further?
Comment 71 User image Kyle Huey [:khuey] (Exited; not receiving bugmail, email if necessary) 2012-02-10 11:46:34 PST
Comment 72 User image Sheila Mooney 2012-02-13 15:08:30 PST
This has been a top crash for a long time. The stack that's consistently high is GraphWalker<scanVisitor>::DoWalk(nsDeque&). We have just over 3500 on 10.0 in the past week. It's not a startup crash.

Is there anything we can do to investigate this further?
Comment 73 User image Andrew McCreight [:mccr8] 2012-02-13 15:21:36 PST
About half of them are null-derefs.  Maybe we can add some release-mode assertions to push around the crash to an earlier point where it would be more useful.  I can take a look at that after I finish with a NoteXPCOMChild crashes.
Comment 74 User image Sheila Mooney 2012-02-14 13:04:18 PST
mccr8, that would be awesome.
Comment 75 User image Andrew McCreight [:mccr8] 2012-02-21 20:19:56 PST
WalkFromRoots is a similar signature that has shown up recently.  Probably the same thing, just showing up differently in the crash reports due to different inlining.
Comment 76 User image Robert Kaiser 2012-04-10 07:35:28 PDT
Still a topcrash - mccr8, did you get somewhere with what you mentioned in comment #73?
Comment 77 User image Andrew McCreight [:mccr8] 2012-04-10 09:16:09 PDT
I landed some assertions and un-inlining, that are currently on Nightly and Aurora.  No progress in figuring out what the problem is.  I don't know if I should back out the changes or not.  I don't think it will affect performance to any measurable extent, but I could check.

It isn't that common on Nightly.  If you add the two GraphWalker signatures up on Nightly, you get a ranking of around 65.  On Aurora, around 45.  On beta, it shows up at 16.  In release 11 it is at 12.  I'm not sure why there is a such a large difference.  I've noticed it before.  It could be malware/junkware related, or perhaps our cycle collector optimizations, which make the CC touch less things in memory, just avoid touching bad things, so it isn't showing up here.
Comment 78 User image Sheila Mooney 2012-05-14 15:03:33 PDT
Still in the top 20 for crashes on release, Fx12.
Comment 79 User image Sheila Mooney 2012-07-03 22:32:37 PDT
This has gone way down in volume on all channels. Still a valid crash but removing the top crash keyword.
Comment 80 User image Andrew McCreight [:mccr8] 2012-11-09 08:20:54 PST
Currently this is around #90 on 16, #80 on 17. Either the move to a new compiler fixed a compiler bug, or with our CC optimizations we're touching bad memory less.
Comment 81 User image Wayne Mery (:wsmwk, NI for questions) 2012-12-18 11:20:43 PST
top 50 crash for TB17
Comment 82 User image Andrew McCreight [:mccr8] 2014-05-05 10:27:11 PDT
Currently about #288 on Nightly.
Comment 83 User image Jesper Hansen 2015-06-28 01:16:37 PDT
Different crashes:
Accounts for 1824 crashes the last 7 days. Adding Thunderbird to the mix raises the number to 1860.

Currently placed as #104 for 38.0.5 for GraphWalker<T>::DoWalk(nsDeque&)
Top-crashes however only counts 948 of these, meaning half of them are other versions of firefox.

Using the search numbers would place it in top 50 for Firefox top-crashes.
Comment 85 User image alex_mayorga 2015-12-10 10:26:10 PST

Ended up here from

4317 crashes in the past month per

Updating flags accordingly FWIW.

Comment 86 User image quaden89 2016-01-29 01:28:25 PST Comment hidden (spam)
Comment 87 User image NGUYEN PHUONG 2016-09-04 08:17:09 PDT Comment hidden (spam)
Comment 88 User image Nguyen Phat 2017-01-17 23:00:39 PST Comment hidden (spam)

Note You need to log in before you can comment on or make changes to this bug.