1114034 - crash in nsTArray_base<nsTArrayInfallibleAllocator, nsTArray_CopyWithMemutils>::IncrementLength(unsigned int) | _PR_NativeRunThread | pr_root

Status: RESOLVED INCOMPLETE

(Core :: General, defect)

Description

[Jim Mathies [:jimm]]

Spin off from bug 1100260.

This bug was filed from the Socorro interface and is 
report bp-7fc8d103-377e-4e6b-861a-812aa2141212.

Comment 1

[Jim Mathies [:jimm]]

This was the shutdown crash I originally reported.

https://crash-stats.mozilla.com/report/list?product=Firefox&signature=nsTArray_base%3CnsTArrayInfallibleAllocator%2C+nsTArray_CopyWithMemutils%3E%3A%3AIncrementLength%28unsigned+int%29+|+_PR_NativeRunThread+|+pr_root#tab-sigsummary

I think this is the bug we want to track on, this is the #7 top crasher in nightly.

Comment 2

[Jim Mathies [:jimm]]

Comments:

disable e10s
Submitted: 2014-12-17T16:11:36+00:00
restart after update is crashed
Submitted: 2014-12-17T20:19:49+00:00
was restarting after turning off the not read y from prime time E10S
Submitted: 2014-12-18T19:09:52+00:00

Comment 3

[IU]

I just got this same shutdown crash (I was restarting Firefox after updating to today's nightly).  It happened when Firefox was taking a really long time to shutdown.  All the windows had closed and the Firefox process was down to 0 % CPU utilization and about 750 MB (for about a minute) but not exiting.  Then there was a brief sign of life with the process, followed about 4-5 seconds later with the crash reporter.

Comment 4

[Robert Kaiser]

I don't understand how this is marked for e10s when it happens in huge volume on 36 Dev Edition, which does not have e10s enabled.

Comment 5

[Jim Mathies [:jimm]]

(In reply to Robert Kaiser (:[e-mail]) from comment #4)
> I don't understand how this is marked for e10s when it happens in huge
> volume on 36 Dev Edition, which does not have e10s enabled.

I marked it as such due to the comments on nightly. This may not be e10s related, but I wanted to get it into our e10s triage so the team can discuss. Please don't let e10s tracking prevent drivers from blocking on this and finding an owner.

Comment 6

[IU]

Definitely not e10s. I run with that disabled.

That said, I haven't encountered this again for about 3 days now.

Comment 7

[Robert Kaiser]

This signature is still #1 with >10% of all DevEd 36 crashes in the last 3 days.

Comment 8

[Robert Kaiser]

David, I have no clue who to contact for this, can you take a look as to what's going on there and where we can direct this?

Comment 9

[(Away)]

Looking. "IncrementLength" is usually code for "compiler merged a bunch of MOZ_CRASHes together" so it's going to take some extra work to figure out which one this was.

What's interesting given the non-e10s comments is that this signature began with nightly 20141116030212, which points to https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=acbd7b68fa8c&tochange=a52bf59965a0, which contains:
	Bug 1089008 - Enable e10s on Windows when acceleration is disabled. r=Mossop, r=felipe

Comment 10

[(Away)]

> "compiler merged a bunch of MOZ_CRASHes together" 
...in this case 216 of them. :( Time for a different approach.

Comment 11

[Robert Kaiser]

Please never remove the crash keyword from crash bugs, we have lots of stuff queued from it.

Comment 12

[(Away)]

With the fix for bug 1119030, the IncrementLength signature disappeared from nightly. Comparing EXCEPTION_BREAKPOINT crashes between the 0108 and 0109 builds, I don't see any obvious replacements. As far as I can tell, the crash merely dispersed into a ton of tiny signatures. It's not a satisfying answer, but I guess it makes sense, given that IncrementLength was basically a catch-all for hundreds of issues.

(A remote possibility is that the crash just so happened to be fixed by one of the other changes in that build, but I don't buy it)

I'll be curious to see whether the same thing is true of aurora once we get bug 1119030 uplifted.

Comment 13

[Jim Mathies [:jimm]]

I see a few new signatures showing up, a number of them related to OOM crashes.

Comment 14

[(Away)]

> I see a few new signatures showing up, a number of them related to OOM crashes.

I don't think those could be "the new IncrementLength", as previously the IncrementLength crashes didn't have an OOM Allocation Size annotation. Similarly, I also ignored the new signatures in other libraries (e.g. mozglue!mozalloc_abort, kernelbase!WaitForSingleObjectEx) since previously they wouldn't have been part of the xul deduping madness.

Comment 15

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

Is this signature still present? Do we have bugs filed to follow up on the many tiny signatures that mentioned in comment 12? Is there anything left to do in this bug?

Comment 16

[(Away)]

This signature is long gone. IIRC the replacement crashes were individually such low volume that they weren't worth filing. If any of them rise back up we'll see it in the nightly lists and file at that point.

I don't really want to call this "fixed", sooo...

Comment 17

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

I'm marking 36 and 37 as fixed. (We don't have an incomplete option for status flags.)