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
: 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: 2016-01-29 01:28 PST (History)
45 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 | Review
Add some debugging help (2.99 KB, patch)
2009-10-06 17:35 PDT, Peter Van der Beken [:peterv]
no flags Details | Diff | Review
Add some debugging help (4.02 KB, patch)
2009-10-15 11:14 PDT, Peter Van der Beken [:peterv]
no flags Details | Diff | Review
Add some debugging help (4.73 KB, patch)
2009-10-23 09:47 PDT, Peter Van der Beken [:peterv]
dbaron: review+
Details | Diff | 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 | Review

Description 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 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 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 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 Samuel Sidler (old account; do not CC) 2009-06-25 18:44:20 PDT
See also bug 437449, another cycle collector topcrash.
Comment 6 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 Dirkjan Ochtman (:djc) 2009-07-28 00:39:32 PDT
I got one as well, seemingly without interaction. (Internal URLs only, sorry.)
Comment 8 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 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 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 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 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 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 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 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 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 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 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 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 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 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 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 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 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 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 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2009-11-02 09:22:11 PST
Are you sure they wouldn't show up under a different signature?
Comment 23 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 Damon Sicore (:damons) 2009-11-02 11:41:47 PST
What's next here?
Comment 25 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 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 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 Peter Van der Beken [:peterv] 2009-11-08 03:03:12 PST
No new crash reports on trunk or 3.6b2pre :-(.
Comment 29 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2009-11-08 12:03:01 PST
Might these be useful?
Comment 30 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 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 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 Peter Van der Beken [:peterv] 2009-11-10 06:15:31 PST
Well, MarkRoots doesn't have any of the debugging code.
Comment 33 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 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 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 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 Damon Sicore (:damons) 2009-11-23 16:05:44 PST
Comment 38 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 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 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 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 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 Johnny Stenback (:jst, 2010-01-28 14:51:52 PST
Not blocking the first alpha on this bug.
Comment 43 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 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 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 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 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 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 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 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 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 Peter Van der Beken [:peterv] 2010-07-30 07:04:32 PDT
I just backed this out.
Comment 52 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 Benjamin Smedberg [:bsmedberg] 2010-10-05 12:02:57 PDT
*** Bug 569688 has been marked as a duplicate of this bug. ***
Comment 54 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 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 Matthias Versen [:Matti] 2010-10-24 10:19:40 PDT
*** Bug 606820 has been marked as a duplicate of this bug. ***
Comment 57 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 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 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 Edgar Hatchel 2010-10-24 12:05:04 PDT
Thanks at least I have an answer to the question.
Comment 60 Scoobidiver (away) 2011-01-08 01:01:18 PST
It is #9 top crasher in 4.0b8 for the last week.
Comment 61 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 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 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 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 Robert Kaiser (not working on stability any more) 2011-06-07 11:41:48 PDT
#10 on 5.0b3 right now, FWIW.
Comment 66 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 Andrew McCreight [:mccr8] 2011-09-19 14:24:13 PDT
*** Bug 682598 has been marked as a duplicate of this bug. ***
Comment 68 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 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 Kyle Huey [:khuey] ( (Away until 6/13) 2012-02-10 11:46:34 PST
Comment 72 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 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 Sheila Mooney 2012-02-14 13:04:18 PST
mccr8, that would be awesome.
Comment 75 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 Robert Kaiser (not working on stability any more) 2012-04-10 07:35:28 PDT
Still a topcrash - mccr8, did you get somewhere with what you mentioned in comment #73?
Comment 77 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 Sheila Mooney 2012-05-14 15:03:33 PDT
Still in the top 20 for crashes on release, Fx12.
Comment 79 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 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 Wayne Mery (:wsmwk, NI for questions) 2012-12-18 11:20:43 PST
top 50 crash for TB17
Comment 82 Andrew McCreight [:mccr8] 2014-05-05 10:27:11 PDT
Currently about #288 on Nightly.
Comment 83 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 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 quaden89 2016-01-29 01:28:25 PST
there is a crash on the trunk looks like

Frame  	Module  	Signature [Expand]  	Source
0 	xul.dll 	GraphWalker<scanVisitor>::DoWalk

not much on the stack but maybe some where around..

looks like it first might have started to appear during the week of 2010 01 16 in builds from  the 14th or 15th.

checking --- GraphWalker.scanVisitor.::DoWalk 20100601-crashdata.csv
found in: 3.7a5pre 3.7a4
release total-crashes
              GraphWalker.scanVisitor.::DoWalk crashes
all     378282  15      3.9653e-05
3.7a5pre        1748    9       0.00514874
3.7a4   702     6       0.00854701

os breakdown
GraphWalker.scanVisitor.::DoWalkTotal 15
Win5.1  0.53
Win6.0  0.00
Win6.1  0.40
Mac10.4 0.00
Mac10.5 0.00
Mac10.6 0.00
Lin2.4  0.07

not correlated to startup.

Correlation to startup or time of session
15 total crashes for GraphWalker.scanVisitor.::DoWalk on 20100601-crashdata.csv
1 start up crashes inside 30 seconds of startup
2 start up crashes inside 3 minutes of startup

some test urls look like

   1 wyciwyg://10/
   1 jar:file:///home/merhai/Downloads/firefox/chrome/toolkit.jar!/content/mozapps/extensions/extensions.xul
   1 h

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