1049138 - crash in VisitNextEdgeBetweenRect

Status: RESOLVED FIXED

(Core :: Graphics: Layers, defect)

Description

[Aaron Train [:aaronmt]]

This bug was filed from the Socorro interface and is 
report bp-128afe4b-0b2a-484f-9527-a920e2140730.
=============================================================

Comment 1

[Aaron Train [:aaronmt]]

First crash report is on 07/26/2014

Comment 2

[Robert Kaiser]

Might be related to bug 1045122

Comment 3

[Kevin Brosnan [Ex-Mozilla]]

[Tracking Requested - why for this release]: new crash in 34 beta and topcrash.

First appearance of this crash 2014-07-24.

Comment 4

[Aaron Train [:aaronmt]]

Trying out the most reported URLS against a Nexus 5. Top device is the GT-I9300	(S3), which I don't have.

Comment 5

[Mark Finkle (:mfinkle) (use needinfo?)]

Top crash in 36, 35 and 34

Comment 6

[Lawrence Mandel [:lmandel] (use needinfo)]

Mark/Brad - Milan tells me that his team has no time to look at this bug in the 34 time frame. Do you have anyone who can help out with the investigation?

Comment 7

[Brad Lassey [:blassey] (use needinfo?)]

Snorp, do you have someone that can look at this?

Comment 8

[James Willcox (:snorp) ([e-mail]) (he/him)]

(In reply to Brad Lassey [:blassey] (use needinfo?) from comment #7)
> Snorp, do you have someone that can look at this?

Not really...it would help if we had STR, though.

Comment 9

[Kevin Brosnan [Ex-Mozilla]]

I've been loading the URLs on the most affected device (GT-I9300) without success.

Comment 10

[Robert Kaiser]

This seems to be pretty well-distributed between devices and graphics adapters, not specific to any of them. That said, it remains the stability #1 issue left on beta at this time.

Comment 11

[James Willcox (:snorp) ([e-mail]) (he/him)]

Eugen can you please see if you can figure out what's going on here?

Comment 12

[Eugen Sawin [:esawin]]

This crashes on calling LockedBits::visitor (same as bug 1045122) from TiledContentClient.cpp, which was introduced in bug 1023473.

Comment 13

[Lawrence Mandel [:lmandel] (use needinfo)]

At this point this is wontfix for 34.

Comment 14

[Mark Finkle (:mfinkle) (use needinfo?)]

Jeff & Botond - This is the #1 crasher on Fx34. Can you take a look at this?

Comment 15

[Botond Ballo [:botond]]

This crash is in code introduced in bug 1023473. I'm not familiar with that code, and Jeff (who wrote it) is on PTO.

BenWa, you reviewed the patch in bug 1023473. Do you think this problem is easy to fix, or alternately, do you know if it would be risky to back bug 1023473 out until Jeff can fix this problem?

Comment 16

[Milan Sreckovic [:milan] (needinfo for best results)]

Jeff, do we have devices that reproduce this?

Comment 17

[Kevin Brosnan [Ex-Mozilla]]

This is not reproducible. According to crash stats the following devices account for 30% of crashes with a long tail of devices that have crashed only a few times. I have tried loading URLs from crash stats on a GT-I9300 without any success. 

samsung GT-I9300 18 (REL)
samsung GT-I9100 16 (REL)
asus 	Nexus 7  19 (REL)
samsung GT-I9305 18 (REL)
samsung GT-N8000 16 (REL)
samsung GT-N8010 16 (REL)
samsung GT-P3100 16 (REL)
samsung SM-T111  17 (REL)
samsung SM-T110  17 (REL)
LGE 	Nexus 4  19 (REL)

Comment 18

[Jeff Muizelaar [:jrmuizel]]

Is this the same as bug 1045122?

Comment 19

[Jeff Muizelaar [:jrmuizel]]

Attachment: Try to catch the crash earlier

Comment 20

[Mark Finkle (:mfinkle) (use needinfo?)]

FYI: I think blassey has started a backout of bug 1023473, which seems to have introduced the crash, and also fixes bug 1073554.

Comment 21

[Milan Sreckovic [:milan] (needinfo for best results)]

If bug 1023473 is being backed out, it was a 2.0/2.1/2.2 blocker, so let's be careful.

Comment 22

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/4e0b66fa178b

Comment 23

[Nick Thomas [:nthomas] (UTC+12)]

I've been hitting the VisitAbove crashes several times a day since the landing in comment #22. Today I bit the bullet installed a debug build of mozilla-central f14dcd1c8c0b (from tbpl), loaded http://www.geekzone.co.nz/ (not the mobile version) and scrolled up and down until:

12-15 23:30:17.517 I/Gecko   (22408): [22408] WARNING: Subdocument container has no frame: file /builds/slave/m-cen-and-api-11-d-00000000000/build/layout/base/nsDocumentViewer.cpp, line 2505
12-15 23:30:17.517 I/Gecko   (22408): ++DOMWINDOW == 18 (0x6edfdc00) [pid = 22408] [serial = 18] [outer = 0x6e8bfa00]
12-15 23:30:17.540 W/GeckoConsole(22408): [JavaScript Warning: "This site makes use of a SHA-1 Certificate; it's recommended you use certificates with signature algorithms that use hash functions stronger than SHA-1." {file: "https://googleads.g.doubleclick.net/xbbe/pixel?d=CPcCENFCGKCAhwM&v=APEucNXi3KEXTPas95lo9lQg654KuOF3Z97TUysheW-A0SJkRa1sjqj_1-9_cEYyH6H2inG9Lox3" line: 0}]
12-15 23:30:17.782 I/Gecko   (22408): void mozilla::AndroidBridge::HandleGeckoMessage(JSContext*, JS::HandleObject)
12-15 23:30:17.837 I/Gecko   (22408): void mozilla::AndroidBridge::HandleGeckoMessage(JSContext*, JS::HandleObject)
12-15 23:30:18.173 D/dalvikvm(22408): GC_CONCURRENT freed 1448K, 13% free 10419K/11904K, paused 3ms+6ms, total 42ms
12-15 23:30:18.446 I/Gecko   (22408): void mozilla::AndroidBridge::HandleGeckoMessage(JSContext*, JS::HandleObject)
12-15 23:30:18.798 F/MOZ_CRASH(22408): Hit MOZ_CRASH(long src memcpy) at /builds/slave/m-cen-and-api-11-d-00000000000/build/gfx/layers/client/TiledContentClient.cpp:994
12-15 23:30:18.798 F/libc    (22408): Fatal signal 11 (SIGSEGV) at 0x00000000 (code=1), thread 22425 (Gecko)
12-15 23:30:18.899 I/DEBUG   (22389): unexpected waitpid response: n=22425, status=00000b00
12-15 23:30:18.899 I/DEBUG   (22389): ptrace detach from 22425 failed: No such process
12-15 23:30:18.899 I/DEBUG   (22389): debuggerd committing suicide to free the zombie!
12-15 23:30:18.899 I/ActivityManager(  372): Process org.mozilla.fennec (pid 22408) has died.
12-15 23:30:18.899 I/WindowState(  372): WIN DEATH: Window{4293de60 u0 org.mozilla.fennec/org.mozilla.fennec.App}

Repeated it a few times and it was a long src memcpy each time.

Comment 24

[James Willcox (:snorp) ([e-mail]) (he/him)]

(In reply to Nick Thomas [:nthomas] from comment #23)
> Repeated it a few times and it was a long src memcpy each time.

If you can reproduce this with a local build, it would help if you printed out all the arguments in the visitor function when we crash. Use printf_stderr, as that always goes to logcat on Android.

Thanks a lot for looking into this! I still can't reproduce it locally at all. What device are you using?

Comment 25

[Kartikaya Gupta (email:[e-mail])]

Really we should just write better tests for this region visitor code. It's really easy to write gtests for this using differently shaped regions.

Comment 26

[James Willcox (:snorp) ([e-mail]) (he/him)]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #25)
> Really we should just write better tests for this region visitor code. It's
> really easy to write gtests for this using differently shaped regions.

Yeah, also that.

Comment 27

[Jeff Muizelaar [:jrmuizel]]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #25)
> Really we should just write better tests for this region visitor code. It's
> really easy to write gtests for this using differently shaped regions.

There are already some tests. If you have suggestions for more please add.

Comment 28

[Kartikaya Gupta (email:[e-mail])]

Attachment: WIP - Update gtests to match production code

Comment 29

[Kartikaya Gupta (email:[e-mail])]

Attachment: WIP - Add some gtests, one of which fails

Comment 30

[Kartikaya Gupta (email:[e-mail])]

Here you go. None of the existing tests exercise the boundary conditions and one of the new ones I added fails. (assuming I did the "update gtests" patch correctly)

Comment 31

[Jeff Muizelaar [:jrmuizel]]

Attachment: Fix the test failure

We we're being too conservative in our clamping.

I don't think this will fix the crash.

Comment 32

[Jeff Muizelaar [:jrmuizel]]

Attachment: Clamp y1 more

But perhaps insufficiently conservative in clamping height

Comment 34

[Jeff Muizelaar [:jrmuizel]]

Attachment: Clamp y1 more for reals

Comment 35

[Jeff Muizelaar [:jrmuizel]]

https://tbpl.mozilla.org/?tree=Try&rev=b80e42c86578

Comment 36

[Nick Thomas [:nthomas] (UTC+12)]

(In reply to James Willcox (:snorp) ([e-mail]) from comment #24)
> Thanks a lot for looking into this! I still can't reproduce it locally at
> all. What device are you using?

Galaxy Nexus, so old.

(In reply to Jeff Muizelaar [:jrmuizel] from comment #35)
> https://tbpl.mozilla.org/?tree=Try&rev=b80e42c86578

Unfortunately this only has an x86 Android build. The arm builders got split recently into two builds for different API levels, and trychooser isn't quite updated yet (bug 1108058). I've used https://wiki.mozilla.org/ReleaseEngineering/How_To/Trigger_arbitrary_jobs to try to fill the gaps. We'll have to wait and see if the tests start.

Comment 37

[Jeff Muizelaar [:jrmuizel]]

(In reply to Nick Thomas [:nthomas] from comment #36)
> (In reply to James Willcox (:snorp) ([e-mail]) from comment #24)
> > Thanks a lot for looking into this! I still can't reproduce it locally at
> > all. What device are you using?
> 
> Galaxy Nexus, so old.
> 
> (In reply to Jeff Muizelaar [:jrmuizel] from comment #35)
> > https://tbpl.mozilla.org/?tree=Try&rev=b80e42c86578
> 
> Unfortunately this only has an x86 Android build. The arm builders got split
> recently into two builds for different API levels, and trychooser isn't
> quite updated yet (bug 1108058). I've used
> https://wiki.mozilla.org/ReleaseEngineering/How_To/Trigger_arbitrary_jobs to
> try to fill the gaps. We'll have to wait and see if the tests start.

Any luck with these builds?

Comment 38

[Nick Thomas [:nthomas] (UTC+12)]

Still hitting 

12-17 16:44:19.912 F/MOZ_CRASH(10818): Hit MOZ_CRASH(long src memcpy) at /builds/slave/try-and-api-11-d-0000000000000/build/gfx/layers/client/TiledContentClient.cpp:994

with the debug build from b80e42c86578. Happy to try other builds, eg with the suggestion in comment #24.

Comment 39

[Jeff Muizelaar [:jrmuizel]]

(In reply to Nick Thomas [:nthomas] from comment #38)
> Still hitting 
> 
> 12-17 16:44:19.912 F/MOZ_CRASH(10818): Hit MOZ_CRASH(long src memcpy) at
> /builds/slave/try-and-api-11-d-0000000000000/build/gfx/layers/client/
> TiledContentClient.cpp:994
> 
> with the debug build from b80e42c86578. Happy to try other builds, eg with
> the suggestion in comment #24.

Any chance you can get this in this in debugger and print all of the arguments to ensure_memcpy?

Comment 40

[Jeff Muizelaar [:jrmuizel]]

Otherwise, I've pushed a build that should print them to stderr.
https://tbpl.mozilla.org/?tree=Try&rev=64edf7b05d0d

Comment 41

[Nick Thomas [:nthomas] (UTC+12)]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #39)
> Any chance you can get this in this in debugger and print all of the
> arguments to ensure_memcpy?

Sorry, I don't have that sort of dev environment handy or any experience with it.

Comment 42

[Jeff Muizelaar [:jrmuizel]]

Here's a build that should actually build:
https://tbpl.mozilla.org/?tree=Try&rev=cacc4c65ab2b

Comment 43

[James Willcox (:snorp) ([e-mail]) (he/him)]

I have a Galaxy Nexus now that reproduces this bug. Jeff and Bas helped me determine what's going on on IRC. The cairo format (RGB16) does not agree with the SurfaceFormat of the DrawTarget (BGRX). This results in us having a bogus stride and overrunning things.

Comment 44

[James Willcox (:snorp) ([e-mail]) (he/him)]

Attachment: Use the cairo surface format to determine gfx format when able

I don't know if this fixes all of the possible issues with using the content as the surface format, but it does fix this bug.

Comment 45

[James Willcox (:snorp) ([e-mail]) (he/him)]

Attachment: Use the cairo surface format to determine gfx format when able

Some cleanup

Comment 46

[James Willcox (:snorp) ([e-mail]) (he/him)]

Passes try, so gonna go ahead and get this in.

https://treeherder.mozilla.org/#/jobs?repo=try&revision=73893e090020

Comment 47

[James Willcox (:snorp) ([e-mail]) (he/him)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/cc7b14ff7bdb

Comment 48

[James Willcox (:snorp) ([e-mail]) (he/him)]

Comment on attachment 8537942 [details] [diff] [review]
Use the cairo surface format to determine gfx format when able

Approval Request Comment
[Feature/regressing bug #]: bug 1023473
[User impact if declined]: crashes
[Describe test coverage new/current, TBPL]: local testing and CI
[Risks and why]: low
[String/UUID change made/needed]: none

It looks like we already WONTFIXed this for 34, but thought I'd give it a shot.

Comment 49

[Nick Thomas [:nthomas] (UTC+12)]

The inbound build on cc7b14ff7bdb is working great for me.

Comment 50

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/cc7b14ff7bdb

Comment 51

[Robert Kaiser]

(In reply to James Willcox (:snorp) ([e-mail]) from comment #48)
> It looks like we already WONTFIXed this for 34, but thought I'd give it a
> shot.

If this is confirmed to fix the Visit* crashes on ICS-based B2G devices, we definitely should try to get it into FxOS 2.1 as the ICS-based Geeksphones are still the most reliable crash reporting devices for B2G next to the Flames.

Comment 52

[James Willcox (:snorp) ([e-mail]) (he/him)]

(In reply to Robert Kaiser (:[e-mail]) from comment #51)
> (In reply to James Willcox (:snorp) ([e-mail]) from comment #48)
> > It looks like we already WONTFIXed this for 34, but thought I'd give it a
> > shot.
> 
> If this is confirmed to fix the Visit* crashes on ICS-based B2G devices, we
> definitely should try to get it into FxOS 2.1 as the ICS-based Geeksphones
> are still the most reliable crash reporting devices for B2G next to the
> Flames.

I think we probably use gralloc-backed tiles everywhere on B2G, so this cairo-related thing should not affect it. Sotaro can you confirm that?

Comment 53

[Jeff Muizelaar [:jrmuizel]]

(In reply to James Willcox (:snorp) ([e-mail]) from comment #52)
> (In reply to Robert Kaiser (:[e-mail]) from comment #51)
> > (In reply to James Willcox (:snorp) ([e-mail]) from comment #48)
> > > It looks like we already WONTFIXed this for 34, but thought I'd give it a
> > > shot.
> > 
> > If this is confirmed to fix the Visit* crashes on ICS-based B2G devices, we
> > definitely should try to get it into FxOS 2.1 as the ICS-based Geeksphones
> > are still the most reliable crash reporting devices for B2G next to the
> > Flames.
> 
> I think we probably use gralloc-backed tiles everywhere on B2G, so this
> cairo-related thing should not affect it. Sotaro can you confirm that?

Whether we use gralloc or not should be unrelated to whether this crashes. The crashes can happen anywhere we use cairo and 565.

Comment 54

[Sotaro Ikeda [:sotaro]]

(In reply to James Willcox (:snorp) ([e-mail]) from comment #52)
> > 
> > If this is confirmed to fix the Visit* crashes on ICS-based B2G devices, we
> > definitely should try to get it into FxOS 2.1 as the ICS-based Geeksphones
> > are still the most reliable crash reporting devices for B2G next to the
> > Flames.
> 
> I think we probably use gralloc-backed tiles everywhere on B2G, so this
> cairo-related thing should not affect it. Sotaro can you confirm that?

For tiling buffer allocation, TextureClient::CreateForDrawing() is used. On b2g, it first try to allocate TextureClient, if the allocation failed, then it try to fallback to BufferTextureClient allocation(ShmemTextureClient/MemoryTextureClient).

Therefore, if the device is out of gralloc buffer situation, BufferTextureClient is used for it.

ICS device is very easy to become out of gralloc. Since JB, android supports ion memory and out of gralloc becomes less often. geekphone is most easily become out of gralloc situation even within b2g ics devices. geekphone uses very old codeaurora code(ics_chocolate) that is not provided for b2g support. All other b2g ics devices uses newer code (ics_strawberry) that has support for b2g by codeaurora. Therefore, geekphone has a lot of problems related to graphics and media.


Bug 1036905 is one example bug that is related to out of gralloc on geekphone.

Comment 55

[James Willcox (:snorp) ([e-mail]) (he/him)]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #53)
> (In reply to James Willcox (:snorp) ([e-mail]) from comment #52)
> > (In reply to Robert Kaiser (:[e-mail]) from comment #51)
> > > (In reply to James Willcox (:snorp) ([e-mail]) from comment #48)
> > > > It looks like we already WONTFIXed this for 34, but thought I'd give it a
> > > > shot.
> > > 
> > > If this is confirmed to fix the Visit* crashes on ICS-based B2G devices, we
> > > definitely should try to get it into FxOS 2.1 as the ICS-based Geeksphones
> > > are still the most reliable crash reporting devices for B2G next to the
> > > Flames.
> > 
> > I think we probably use gralloc-backed tiles everywhere on B2G, so this
> > cairo-related thing should not affect it. Sotaro can you confirm that?
> 
> Whether we use gralloc or not should be unrelated to whether this crashes.
> The crashes can happen anywhere we use cairo and 565.

Oops, that's exactly right. We probably do want this on B2G then. What determines whether or not we use 565? Screen depth, right?

Comment 56

[James Willcox (:snorp) ([e-mail]) (he/him)]

Comment on attachment 8537942 [details] [diff] [review]
Use the cairo surface format to determine gfx format when able

NOTE: Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): bug 1023473
User impact if declined: crashes
Testing completed: m-c, try
Risk to taking this patch (and alternatives if risky): low
String or UUID changes made by this patch: none

Comment 57

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/1538e452e408
https://hg.mozilla.org/releases/mozilla-beta/rev/bfc940387e3f

[Blocking Requested - why for this release]:
Based on the recent comments, this sounds like a very-real possibility for causing crashes on v2.0 and v2.1.

Comment 58

[James Willcox (:snorp) ([e-mail]) (he/him)]

Comment on attachment 8537942 [details] [diff] [review]
Use the cairo surface format to determine gfx format when able

We do indeed need this on b2g32 as well.

Comment 59

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

This may cut down on a number of large crashes involving Visit*; I'm not sure if there's a risk for any of our partners to take this patch.

Comment 60

[Jayme Mercado [:JMercado] (Inactive 3/4/2016)]

Removing the steps-wanted tag as the cause of this issue is known now.

Comment 64

[bhavana bajaj [:bajaj]]

(In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from comment #59)
> This may cut down on a number of large crashes involving Visit*; I'm not
> sure if there's a risk for any of our partners to take this patch.

We can certainly backport given the low-risk and land on our trees. That way any future builds that are created by partners from this branch could avoid this. Can you help monitor the crash-reports that we are seeing or see if there is any way to reproduce and verify the fix here?

Comment 65

[Robert Kaiser]

We have regular very visible crash reports from Geeksphones on those signatures and GP creates new builds from those branches daily (I think even for 2.0 still, but surely for 2.1 and 2.2) so we will probably see just from stats within a week if the crashes still happen.

It's so nice when the affected devices actually have regular updates and working crash reporting, I'd so love to see that for more FxOS devices...

Comment 66

[bhavana bajaj [:bajaj]]

Comment on attachment 8537942 [details] [diff] [review]
Use the cairo surface format to determine gfx format when able

Approving as this is a low risk patch helping with stabiliy. QA will help monitor the crash data post landing.

Comment 67

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Waiting for things to land on 2.1; visit crash doesn't seem to be happening on 2.2 any more.

Comment 68

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/d567f6f5003c
https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/4dd6d9b58f42

Comment 69

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g32_v2_0m/rev/4dd6d9b58f42

Comment 71

[alex_mayorga]

(In reply to Robert Kaiser (:[e-mail]) from comment #65)
> We have regular very visible crash reports from Geeksphones on those
> signatures and GP creates new builds from those branches daily (I think even
> for 2.0 still, but surely for 2.1 and 2.2) so we will probably see just from
> stats within a week if the crashes still happen.
> 
> It's so nice when the affected devices actually have regular updates and
> working crash reporting, I'd so love to see that for more FxOS devices...

Is there a bug on file for that? Having bought a commercially available device down here in Mexico that it's still stuck on 1.1 it's a real PITA...

Comment 72

[Robert Kaiser]

(In reply to alex_mayorga from comment #71)
> Is there a bug on file for that? Having bought a commercially available
> device down here in Mexico that it's still stuck on 1.1 it's a real PITA...

Not sure what you mean, you'd need to file bugs against the partners that deliver those phones. There is nothing Mozilla can do there unfortunately. What I said is that it's nice that we at least the Geeksphones that actually do have current versions available so that we do get data from that.

Comment 73

[Robert Kaiser]

Hmm, on Android, this signature went down from ~3.5% in 35.0b4 and 35.0b6 to ~2% in 35.0b8, but it's not gone completely. I guess we'll need to clone this bug to a new one for the remaining crashes.

On B2G, I haven't seen the Visit* signatures in any build after this landed (12/22 on 2.0 and 2.1) but given holiday time, we should monitor for a bit longer until we can be sure.

Comment 74

[Dirkjan Ochtman (:djc)]

I just saw this crash twice in rapid succession on http://178.175.135.122/ (Pirate Bay countdown) with Beta 35 on Android 5 (Nexus 4).

Comment 75

[Robert Kaiser]

(In reply to Dirkjan Ochtman (:djc) from comment #74)
> I just saw this crash twice in rapid succession on http://178.175.135.122/
> (Pirate Bay countdown) with Beta 35 on Android 5 (Nexus 4).

If that's the latest beta and this is reproducable, can you please file a new bug (ideally via the "Report this bug in ... Core" link of one of your crash reports) and refernece that new bug here? We seem to have fixed something here but it looks like there's more cases we need to look into.

Comment 76

[Dirkjan Ochtman (:djc)]

Done, see bug 1117338.

Comment 77

[Lukas Blakk [:lsblakk] use ?needinfo]

Comment on attachment 8537942 [details] [diff] [review]
Use the cairo surface format to determine gfx format when able

Now that we've shipped 35.0 there's no need for this to be approved for mozilla-release.

Comment 80

[Josh Cheng [:josh]]

Hi James,
The problem still exist on 2.0M branch per bug 1126644. Could you please help to check again? Thanks!

Comment 81

[James Willcox (:snorp) ([e-mail]) (he/him)]

Looks like some good work in bug 1126644 finding out what's going on here

Comment 82

[David Weir (satdav)]

This is back as had 2 crashes today

Comment 83

[Kartikaya Gupta (email:[e-mail])]

Please file a new bug with details. Tracking gecko versions for patches gets confusing if bugs are reopened like this.