Crash @ GraphWalker

NEW
Unassigned

Status

()

Product:
Core
Component:
XPCOM
Importance:
P2
critical
Reported:
10 years ago
Modified:
4 months ago

People

(Reporter: samuel.sidler+old, Unassigned)

Tracking

({crash})

Version:
Trunk
Keywords:
crash
Points:
---
Dependency tree / graph
Duplicates:
569688, 606820, 682598, 1490016
Bug Flags:
blocking1.9.2 -
wanted1.9.0.x +

Firefox Tracking Flags

(firefox42 affected, firefox43 affected, firefox44 affected, firefox45 affected, blocking2.0 -, status1.9.1 wanted, firefox-esr52 wontfix, firefox56 wontfix, firefox57 wontfix, firefox58 wontfix, firefox62 wontfix, firefox63 affected, firefox64 affected)

Details

(Whiteboard: [crashkill][crashkill-debug][tbird crash], crash signature, URL)

Attachments

(2 attachments, 3 obsolete attachments)

Add some debugging help
4.73 KB, patch
dbaron
: review+
Details | Diff | Splinter Review
Make debugging code bring up breakpad
986 bytes, patch
dbaron
: review+
Details | Diff | Splinter Review
(Reporter)

Description

•
10 years ago 
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?
Flags: wanted1.9.1.x+
Depends on: 500189

Comment 1

•
10 years ago 
Bug 500189 has URLs for Firefox 3.5, 3.5pre and 3.5b99 (in that order)

Comment 3

•
10 years ago 
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?
 (Reporter)

Comment 4

•
10 years ago 
Note: This also happens on 1.9.0 (currently #12 overall).
Flags: wanted1.9.0.x+
 (Reporter)

Comment 5

•
10 years ago 
See also bug 437449, another cycle collector topcrash.
 (Reporter)

Comment 6

•
10 years ago 
Peterv: Can you take a look at the crash reporter stack above and see if there's any problem we can fix here?
Assignee: nobody → peterv
status1.9.1: --- → wanted
Flags: wanted1.9.1.x+

Comment 7

•
10 years ago 
I got one as well, seemingly without interaction. (Internal URLs only, sorry.)

http://crash-stats.mozilla.com/report/index/54237630-c199-4b5b-af6e-63f462090728?p=1

Comment 8

•
10 years ago 
Hmmnnnn, my laptop seemed to have crashed on a specific link (http://profile.myspace.com/Modules/Applications/Pages/Canvas.aspx?appId=104283&appParams={%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

•
10 years ago 
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.
http://crash-stats.mozilla.com/report/index/46d27c8b-1809-4f90-bb17-9eff12090824

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

•
10 years ago 
Johnny/Jonas: we need to figure this out before we ship Firefox 3.6
Flags: blocking1.9.2+
Priority: -- → P2

Comment 11

•
10 years ago
Posted patch v1 (obsolete) — — Splinter 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.
Attachment #403974 - Flags: review?(dbaron)

Comment 12

•
10 years ago 
Comment on attachment 403974 [details] [diff] [review]
v1

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.
Attachment #403974 - Flags: review?(dbaron) → review-
Keywords: topcrash

Comment 13

•
10 years ago
Posted patch Add some debugging help (obsolete) — — Splinter Review 
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.
Attachment #403974 - Attachment is obsolete: true

Comment 14

•
10 years ago
Posted patch Add some debugging help (obsolete) — — Splinter Review 
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.
Attachment #404970 - Attachment is obsolete: true
Attachment #406482 - Flags: review?(dbaron)
Whiteboard: [crashkill]

Comment 15

•
10 years ago 
How is this going to help; NS_ABORT_IF_FALSE is DEBUG-only.  Don't you want runtime aborts?

Comment 16

•
10 years ago 
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

•
10 years ago 
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

•
10 years ago 
OK, r=dbaron with NS_RUNTIMEABORT (you need to write your own if-statements with that).

Comment 19

•
10 years ago 
I actually went with a CC_RUNTIME_ABORT_IF_FALSE. I'll run this through tryserver again.
Attachment #406482 - Attachment is obsolete: true
Attachment #408038 - Flags: review?(dbaron)
Attachment #406482 - Flags: review?(dbaron)
Whiteboard: [crashkill] → [crashkill] ready to land debugging help code?

Comment 20

•
10 years ago 
Debugging help landed (in two pieces):

http://hg.mozilla.org/mozilla-central/rev/9bb5e2a5c1ac
http://hg.mozilla.org/mozilla-central/rev/80831c195191

I think the second piece missed today's nightly.

Comment 21

•
10 years ago 
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 23

•
10 years ago 
I check for signatures GraphWalker::DoWalk(nsDeque&), EdgePool::CheckIterator(Iterator&) and NodePool::CheckPtrInfo(PtrInfo*). I think that should catch them.

Comment 24

•
10 years ago 
What's next here?

Comment 25

•
10 years ago 
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.
Attachment #408038 - Flags: approval1.9.2?
 (Reporter)

Comment 26

•
10 years ago 
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.)
Whiteboard: [crashkill] ready to land debugging help code? → [crashkill][crashkill-fix] ready to land debugging help code?
Whiteboard: [crashkill][crashkill-fix] ready to land debugging help code? → [crashkill][crashkill-debug] ready to land debugging help code?

Comment 27

•
10 years ago 
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:

http://hg.mozilla.org/releases/mozilla-1.9.2/rev/297f674eb90f
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/6b79d9973d7b

Let's hope we get some reports.
Attachment #408038 - Flags: approval1.9.2?

Updated

•
10 years ago
Whiteboard: [crashkill][crashkill-debug] ready to land debugging help code? → [crashkill][crashkill-debug][debugging code landed on trunk and 1.9.2]

Comment 28

•
10 years ago 
No new crash reports on trunk or 3.6b2pre :-(.

Comment 30

•
10 years ago 
David, wouldn't those be for bug 437449? That one seemed related to thread-safety issues?

Comment 31

•
10 years ago 
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

•
10 years ago 
Well, MarkRoots doesn't have any of the debugging code.

Comment 33

•
10 years ago 
Two reports on 3.6b2:

http://crash-stats.mozilla.com/report/index/bfbedc89-ca77-4783-a519-124532091111
http://crash-stats.mozilla.com/report/index/1e1f7869-c343-46c7-b5d5-163632091112

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

•
10 years ago 
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

•
10 years ago 
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

•
10 years ago 
(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

•
10 years ago 
-'ing.
blocking2.0: --- → alpha1
Flags: blocking1.9.2+ → blocking1.9.2-

Comment 38

•
9 years ago 
(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 40

•
9 years ago 
I agree about 1.9.2 (http://hg.mozilla.org/releases/mozilla-1.9.2/rev/96a497f82546 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

•
9 years ago 
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.
Attachment #415830 - Flags: review?(dbaron)
Whiteboard: [crashkill][crashkill-debug][debugging code landed on trunk and 1.9.2] → [crashkill][crashkill-debug][debugging code landed on trunk]

Comment 42

•
9 years ago 
Not blocking the first alpha on this bug.
blocking2.0: alpha1 → beta1

Comment 43

•
9 years ago 
I got this reported yesterday using Mozilla/5.0 (X11; U; Linux i686; rv:1.9.1.9pre) 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 http://us.imdb.com/media/rm1043761920/nm0209289  and I was attempting to return to http://us.imdb.com/name/nm0209289/mediaindex 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

•
9 years ago 
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.

Updated

•
9 years ago
Blocks: 557161

Comment 45

•
9 years ago 
Moving this to beta2.  Not seeing a lot of movement here, but yell if you think this should block the first beta.
blocking2.0: beta1+ → beta2+

Comment 46

•
9 years ago 
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

•
9 years ago 
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.
blocking2.0: beta2+ → beta3+

Comment 48

•
9 years ago 
Has the debugging code been removed? Can we get an answer to comment 46, please?

Comment 49

•
9 years ago 
The debugging code is still present in mozilla-central (and thus still needs to be removed).

Comment 50

•
9 years ago 
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

•
9 years ago 
I just backed this out.

Comment 52

•
9 years ago 
Peter's backout is: http://hg.mozilla.org/mozilla-central/rev/01877f113dab - thanks!

Moving back to blocking2.0:? for retriage on the crash issue.
blocking2.0: beta3+ → ?

Updated

•
9 years ago
Duplicate of this bug: 569688

Updated

•
9 years ago
Summary: top crash [@ GraphWalker::DoWalk(nsDeque&)] → top crash [@ GraphWalker::DoWalk(nsDeque&)][@ GraphWalker<scanVisitor>::DoWalk(nsDeque&)]

Comment 54

•
9 years ago 
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
                         pct.
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
                         pct.
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

•
9 years ago 
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.
blocking2.0: ? → -
Duplicate of this bug: 606820

Comment 57

•
9 years ago 
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

•
9 years ago 
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

•
9 years ago 
Thanks at least I have an answer to the question.

Comment 60

•
8 years ago 
It is #9 top crasher in 4.0b8 for the last week.

Updated

•
8 years ago
Keywords: crash

Comment 61

•
8 years ago 
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, https://addons.mozilla.org/addon/1865)
     25% (21/85) vs.  16% (2373/14431) engine@conduit.com
     13% (11/85) vs.   7% (1020/14431) {CAFEEFAC-0016-0000-0022-ABCDEFFEDCBA} (Java console)
     92% (78/85) vs.  87% (12517/14431) testpilot@labs.mozilla.com (Mozilla Labs - Test Pilot, https://addons.mozilla.org/addon/13661)

Comment 62

•
8 years ago 
Minefield just crashed on me while I was away from my PC, the crash report pointed me here.

https://crash-stats.mozilla.com/report/index/bp-ea34b673-743a-44e2-ad7a-729f22110213

Comment 63

•
8 years ago 
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
 228 http://www.facebook.com
 105 \N//
  57 http://www.youtube.com
  55 http://apps.facebook.com
  29 http://www.orkut.com.br
  29 http://vkontakte.ru
  14 https://mail.google.com
   9 http://nk.pl
   8 http://www.google.com
   6 http://www.google.de
   6 http://my.mail.ru
   6 about:blank//
   5 https://www.google.com
   5 http://www.odnoklassniki.ru
   4 http://www.xvideos.com
   4 http://www.google.com.br
   4 http://us.mg1.mail.yahoo.com
   4 http://en.wikipedia.org
   3 https://www.facebook.com
   3 https://login.yahoo.com
   3 http://www.tuenti.com
   3 http://www.meinvz.net
   3 http://www.google.co.in
   3 http://vnexpress.net
   3 http://us.mg5.mail.yahoo.com
   3 http://twitter.com
   3 http://kino.to
   3 http://foto.mail.ru
   3 http://a.adwolf.ru

I notice about 50% of reports might have unversioned .dll's around


http://crash-stats.mozilla.com/report/index/9b98bd1f-d91f-4666-9699-2aa312110306 FFExternalAlert.dll 
http://crash-stats.mozilla.com/report/index/7e552492-9189-411d-8dfe-d2c502110306 
http://crash-stats.mozilla.com/report/index/f6539ce3-c857-447f-ad7f-4ec4c2110306 zipfldra.dll 
http://crash-stats.mozilla.com/report/index/5b0ff3be-1662-4489-8896-e40912110306 UnlockerHook.dll 
http://crash-stats.mozilla.com/report/index/bc98fcd3-0177-4494-b0ff-b4ff82110306 
http://crash-stats.mozilla.com/report/index/016e47d1-971a-4f33-a8df-951022110306 
http://crash-stats.mozilla.com/report/index/a219ccdc-14c0-4121-9b70-89f3e2110306 
http://crash-stats.mozilla.com/report/index/7d223bb8-3558-4bbb-8aed-b36852110306 MGKBHook.dll FFExternalAlert.dll 
http://crash-stats.mozilla.com/report/index/fcef3988-b3c6-4dd5-b1c4-f47c82110306 
http://crash-stats.mozilla.com/report/index/d2484921-a187-42ad-8a50-c99842110306 
http://crash-stats.mozilla.com/report/index/aa66f9a0-4e4d-486c-bc1b-de40e2110306 
http://crash-stats.mozilla.com/report/index/26e031be-8f17-479a-bf60-b44972110306 AlotXpcom.dll BRNstFF.dll Iminent.XPCOM.dll 
http://crash-stats.mozilla.com/report/index/1108d236-967f-4453-bc0c-bfb5f2110306 
http://crash-stats.mozilla.com/report/index/3e83e53d-17c8-4d2b-bd22-874a32110306 
http://crash-stats.mozilla.com/report/index/311dc382-619d-47e5-8349-4a38a2110306 
http://crash-stats.mozilla.com/report/index/eee5710a-9109-4449-809a-3fce82110306 GrabXpcom.dll GrabKernel.dll 
http://crash-stats.mozilla.com/report/index/77cdb656-ce4b-40e5-9698-1fd7b2110306 
http://crash-stats.mozilla.com/report/index/8a9e290b-d60b-4676-a409-2aaeb2110306 UnlockerHook.dll ActWndHk.dll 
http://crash-stats.mozilla.com/report/index/6cc26abd-6033-4a0d-8ff0-01add2110306 frozen.dll googletoolbar-ff3.dll 
http://crash-stats.mozilla.com/report/index/5ffefa1d-d2fb-4b62-b788-7ec652110306 googletoolbar-ff3.dll frozen.dll 
http://crash-stats.mozilla.com/report/index/16511654-9864-43af-9cb5-c71d62110306 
http://crash-stats.mozilla.com/report/index/17826542-f8c7-4a4b-82f1-74f542110306 GrabKernel.dll GrabXpcom.dll 
http://crash-stats.mozilla.com/report/index/787e7779-446a-4d08-9abe-8d91e2110306 
http://crash-stats.mozilla.com/report/index/9d8aab45-ccf9-44ac-8530-f954d2110306 
http://crash-stats.mozilla.com/report/index/84f1c8e8-b420-4b07-b893-acb622110306 
http://crash-stats.mozilla.com/report/index/a5ea2b64-fb9b-4d05-8737-c57052110306 
http://crash-stats.mozilla.com/report/index/0c325356-a9df-4f8b-953e-c45ac2110306 GrabXpcom.dll GrabKernel.dll 
http://crash-stats.mozilla.com/report/index/4a28d16c-91c1-4ba5-a293-ac0d82110306 
http://crash-stats.mozilla.com/report/index/4e82b168-a933-415b-9d30-0dc9f2110306 
http://crash-stats.mozilla.com/report/index/8d1595ca-4a3e-4a3d-8523-f35e62110306 
http://crash-stats.mozilla.com/report/index/bdc74bb5-5a87-4125-875d-e241f2110306 
http://crash-stats.mozilla.com/report/index/003cc31f-1c6f-427c-b99d-698442110306 googletoolbar-ff3.dll frozen.dll 
http://crash-stats.mozilla.com/report/index/510dda1d-c6f0-4f40-8c34-c8e332110306 BTKeyInd.dll 
http://crash-stats.mozilla.com/report/index/5e1a4445-537e-43b6-9358-390382110306 
http://crash-stats.mozilla.com/report/index/af9ad84b-4208-4177-8581-5f6002110306 
http://crash-stats.mozilla.com/report/index/db4928c5-484e-45aa-ab1b-17a962110306 
http://crash-stats.mozilla.com/report/index/1dd145d9-782c-4121-b4e5-d41842110306 
http://crash-stats.mozilla.com/report/index/f4200636-0bed-4a2b-9fc0-624b42110306 RadioWMPCore.dll FFExternalAlert.dll 
http://crash-stats.mozilla.com/report/index/70107fad-dd42-43bd-b558-191da2110306 
http://crash-stats.mozilla.com/report/index/d90ab2c1-00d7-432a-8e60-9c7a62110306 
http://crash-stats.mozilla.com/report/index/853fdee6-a245-425a-a63a-88fa12110306 newdll.dll 
http://crash-stats.mozilla.com/report/index/e1d2ea02-e7c0-4a65-b96d-957e42110306 
http://crash-stats.mozilla.com/report/index/9e8966cd-2bbe-4763-ae5c-8d3632110306 
http://crash-stats.mozilla.com/report/index/d3f4599c-6b14-4f82-aeba-7c9a62110306 
http://crash-stats.mozilla.com/report/index/5a748cee-3988-4043-8fe6-f0d7d2110306 
http://crash-stats.mozilla.com/report/index/cd78e5ca-6390-4be0-8a7b-b53b12110306 UnlockerHook.dll 
http://crash-stats.mozilla.com/report/index/6563c12f-e1df-47c5-ad19-d57c82110306 
http://crash-stats.mozilla.com/report/index/651a50e3-b979-440e-a1d6-82f1c2110306 dll.dll UKHook40.dll 
http://crash-stats.mozilla.com/report/index/2e7d6d85-7467-4b95-b2bb-41b332110306 lpxpcom.dll 
http://crash-stats.mozilla.com/report/index/946db64b-1277-4e45-a0d1-c8d572110306 
http://crash-stats.mozilla.com/report/index/eb18fb21-3db5-42db-8584-6b4802110306 
http://crash-stats.mozilla.com/report/index/22026bdf-e305-4625-9bb8-7d96b2110306 
http://crash-stats.mozilla.com/report/index/c84acfec-898c-4c39-ae55-aa8392110306 
http://crash-stats.mozilla.com/report/index/37d55f55-736f-4c06-9504-1bbb02110306 googletoolbar-ff3.dll frozen.dll 
http://crash-stats.mozilla.com/report/index/010fb54c-34ad-4714-9784-248362110306 UKHook40.dll 
http://crash-stats.mozilla.com/report/index/291202e5-0991-439e-92db-471d82110306 FFExternalAlert.dll

Comment 64

•
8 years ago 
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

•
8 years ago 
#10 on 5.0b3 right now, FWIW.

Comment 66

•
8 years ago 
(In reply to comment #65)
> #10 on 5.0b3 right now, FWIW.
And #3 top crasher without hangs.
Crash Signature: [@ GraphWalker::DoWalk(nsDeque&)] [@ GraphWalker<scanVisitor>::DoWalk(nsDeque&)]
Duplicate of this bug: 682598

Updated

•
7 years ago
Crash Signature: [@ GraphWalker::DoWalk(nsDeque&)] [@ GraphWalker<scanVisitor>::DoWalk(nsDeque&)] → [@ GraphWalker::DoWalk(nsDeque&)] [@ GraphWalker<scanVisitor>::DoWalk(nsDeque&)] [@ GraphWalker<ScanBlackVisitor>::DoWalk(nsDeque&) ]

Comment 68

•
7 years ago 
https://tbpl.mozilla.org/php/getParsedLog.php?id=7562031&tree=Mozilla-Inbound - 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

•
7 years ago 
Still appears consistently in the top 20 crashes for releases. Can we investigate this further?

Comment 72

•
7 years ago 
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

•
7 years ago 
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.
Whiteboard: [crashkill][crashkill-debug][debugging code landed on trunk] → [crashkill][crashkill-debug]
Assignee: peterv → continuation

Comment 74

•
7 years ago 
mccr8, that would be awesome.
Depends on: 727604

Comment 75

•
7 years ago 
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.
Crash Signature: [@ GraphWalker::DoWalk(nsDeque&)] [@ GraphWalker<scanVisitor>::DoWalk(nsDeque&)] [@ GraphWalker<ScanBlackVisitor>::DoWalk(nsDeque&) ] → [@ GraphWalker::DoWalk(nsDeque&)] [@ GraphWalker<scanVisitor>::DoWalk(nsDeque&)] [@ GraphWalker<ScanBlackVisitor>::DoWalk(nsDeque&) ] [@ GraphWalker<scanVisitor>::WalkFromRoots(GCGraph&)]

Updated

•
7 years ago
Crash Signature: [@ GraphWalker::DoWalk(nsDeque&)] [@ GraphWalker<scanVisitor>::DoWalk(nsDeque&)] [@ GraphWalker<ScanBlackVisitor>::DoWalk(nsDeque&) ] [@ GraphWalker<scanVisitor>::WalkFromRoots(GCGraph&)] → GraphWalker<ScanBlackVisitor>::Walk] [@ GraphWalker<scanVisitor>::WalkFromRoots(GCGraph&)] [@ GraphWalker<scanVisitor>::WalkFromRoots] [@ GraphWalker::DoWalk(nsDeque&)] [@ GraphWalker<scanVisitor>::DoWalk(nsDeque&)] [@ GraphWalker<scanVisitor>::DoWalk…
Summary: top crash [@ GraphWalker::DoWalk(nsDeque&)][@ GraphWalker<scanVisitor>::DoWalk(nsDeque&)] → Crash @ GraphWalker

Comment 76

•
7 years ago 
Still a topcrash - mccr8, did you get somewhere with what you mentioned in comment #73?

Comment 77

•
7 years ago 
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

•
7 years ago 
Still in the top 20 for crashes on release, Fx12.

Comment 79

•
7 years ago 
This has gone way down in volume on all channels. Still a valid crash but removing the top crash keyword.
Keywords: topcrash

Comment 80

•
7 years ago 
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.
Version: 1.9.1 Branch → Trunk

Comment 81

•
6 years ago 
top 50 crash for TB17
Whiteboard: [crashkill][crashkill-debug] → [crashkill][crashkill-debug][tbird crash]

Comment 82

•
5 years ago 
Currently about #288 on Nightly.
Assignee: continuation → nobody

Comment 83

•
4 years ago 
Different crashes:
https://crash-stats.mozilla.com/search/?product=Firefox&signature=DoWalk&_facets=signature&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#facet-signature
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.

Updated

•
4 years ago
Crash Signature: [@ GraphWalker::DoWalk(nsDeque&)] [@ GraphWalker<scanVisitor>::DoWalk(nsDeque&)] [@ GraphWalker<scanVisitor>::DoWalk] [@ GraphWalker<ScanBlackVisitor>::DoWalk(nsDeque&)] [@ GraphWalker<ScanBlackVisitor>::DoWalk] [@ GraphWalker<ScanBlackVisitor>::Walk… → [@ GraphWalker::DoWalk(nsDeque&)] [@ GraphWalker<scanVisitor>::DoWalk(nsDeque&)] [@ GraphWalker<scanVisitor>::DoWalk] [@ GraphWalker<ScanBlackVisitor>::DoWalk(nsDeque&)] [@ GraphWalker<ScanBlackVisitor>::DoWalk] [@ GraphWalker<ScanBlackVisitor>::Walk…

Comment 85

•
3 years ago 
¡Hola!

Ended up here from https://support.mozilla.org/en-US/questions/1098307

4317 crashes in the past month per https://crash-stats.mozilla.com/report/list?product=Firefox&range_unit=days&range_value=28&signature=GraphWalker%3CT%3E%3A%3ADoWalk#tab-sigsummary

Updating flags accordingly FWIW.

¡Gracias!
status-firefox42: --- → affected
status-firefox43: --- → affected
status-firefox44: --- → affected
status-firefox45: --- → affected
Comment hidden (spam)
Comment hidden (spam)
Comment hidden (spam)
Flags: needinfo?(norikachi003)
Comment hidden (spam)
Comment hidden (spam)

Updated

•
a year ago
status-firefox56: --- → affected
status-firefox57: --- → affected
status-firefox58: --- → affected
status-firefox-esr52: --- → affected

Comment 92

•
a year ago 
The bug is back -- 9 (!) years later:

https://crash-stats.mozilla.com/report/index/cbfa60bf-d335-4ace-9e09-939341171106

I was not doing anything, I was away from the browser. The page with YouTube's subscriptions just died on its own.
Duplicate of this bug: 1490016

Comment 94

•
6 months ago 
I was not doing anything, I was away from the browser. maybe the ads script on the site: 
http://wiki.edu.vn/wiki
http://wikideu.com/wiki/

Comment 95

•
6 months ago 
This is now a fairly high volume crash on release 62, for example, for  GraphWalker<T>::DoWalk there are 2400+ crashes in the last week:  https://crash-stats.mozilla.com/signature/?signature=GraphWalker%3CT%3E%3A%3ADoWalk
status-firefox56: affected → wontfix
status-firefox57: affected → wontfix
status-firefox58: affected → wontfix
status-firefox62: --- → wontfix
status-firefox63: --- → affected
status-firefox64: --- → affected
status-firefox-esr52: affected → wontfix
You need to log in before you can comment on or make changes to this bug.