This bug was filed from the Socorro interface and is report bp-3008bf31-dd77-4fe6-a4b1-26a230171005. ============================================================= There are 269 crashes in nightly 58 starting with buildid 20170929220356. In looking at the pushlog (see [1]), this regression could be a consequence of fix for bug 1403935. By the way, there are crashes with this signature in beta 57 (175 crashes in 57.0b13), release 56 and esr 52, but it's probably a different issue. :bas.schouten, could you investigate please ? [1] https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=946b9c995ec331f4f96360409fd8d2fc49e46838&tochange=57f68296c350469d73d788eb3695a898947b4acb

(the reports spiking up on 57.0b13 are all from the problematic/crashy AuthenticAMD family 20 model 1/2 processor family and should be unrelated to this regression on nightly - bug 772330)

Hrm, my guess is this is somehow related to OMTP. David, have you seen this before? I vaguely recall seeing something like this in another bug but I don't remember which it was.

This is the #3 Window topcrash in Nightly 20171103100331, with 79 occurrences.

Did this regress recently? I don't remember seeing this crash be as common just after bug 1403935 landed?

(In reply to Bas Schouten (:bas.schouten) from comment #4) > Did this regress recently? I don't remember seeing this crash be as common > just after bug 1403935 landed? My main thought is, to clarify, could this have regressed again with the landing of bug 1412850?

There were 26 crashes in 57.0a1. There are 712 crashes in 58.0a1: - from buildid 20170929220356 to 20170930220116: 227 crashes - from 20171005220204 to 20171023220222: 5 crashes - from 20171031220132 to 20171105100353: 480 crashes

[Tracking Requested - why for this release]: sec-high UAF - virtually all 58a1 crashes are UAFs or 0xfffffffff, which is "I can't determine the address". Many of the rest are random/wildptrs which matches a UAF signature. Moving release to another thread seems *very* likely as a cause of the 58 UAF. The AMD 57bN crashes are all wildptr crashes, and thus probably sec-high as well. Is there any way to fix that before 57 goes to release?

(In reply to Randell Jesup [:jesup] from comment #7) > [Tracking Requested - why for this release]: > > sec-high UAF - virtually all 58a1 crashes are UAFs or 0xfffffffff, which is > "I can't determine the address". Many of the rest are random/wildptrs which > matches a UAF signature. > > Moving release to another thread seems *very* likely as a cause of the 58 > UAF. > > The AMD 57bN crashes are all wildptr crashes, and thus probably sec-high as > well. Is there any way to fix that before 57 goes to release? I don't think the AMD ones are in any way related to this bug (I don't know anything about that bug, it's CPU related aiui, bug 772330 should be about something like this), 57 didn't even have any OMTP code in there.

After extensively auditing the code this is the only idea I can come up with. We should land this soon, check the next nightly, if this bug persists I will backout bug 1412850 until I can come up with a new theory.

There are some similar crashes with "SkImage::peekPixels" signature starting around the same time. Seems likely to be the same underlying cause.

There were at least 3 signatures in the list that seemed related; I'll look for the other one

Perhaps also [@ mozilla::gfx::ReadSkImage ] or [@ mozilla::gfx::DrawTargetSkia::FillRect ]?

Two patches have landed on inbound for this bug and the related ones, let's see if things are better once they have been merged to central.

Track 58+ as the volume of crashes is high.

The spike starting around 11/1 or so is where the signature for SkRefCntBase::unref() shows up (and maybe PeekPixel too), and it's a big spike.

Let's monitor to see if the original failures go away... should we leave it open for now?

(In reply to Randell Jesup [:jesup] from comment #17) > Let's monitor to see if the original failures go away... should we leave it > open for now? Sure, I think the chances are really good it will go away.

It appears this has been effective, 0 crashes in last night's nightly.

Confirmed by more longer term data, no crashes in nightly after the 8th.