Closed Bug 1058567 Opened 10 years ago Closed 10 years ago

crash in gfxContext::PushNewDT ( and OOM|small signature) while browsing on fr.wiktionary.org

Categories

(Core :: Graphics, defect)

Product:
Core
Component:
Graphics
Platform:
All
Linux
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1053934

People

(Reporter: fredbezies, Unassigned)

Details

(Keywords: crash, topcrash)

Crash Data

This bug was filed from the Socorro interface and is 
report bp-1ecb231e-cbfb-4e13-bead-d8b482140826.
=============================================================

I was just browsing on this site - fr.wiktionary.org/wiki/clope - while doing some search and firefox just crashed.

Extensions : 

* adblock edge 2.1.4
* ghostery 5.3.2

Will try to reproduce this bug with a clean profile.
Firefox crashes with a clean profile too : bp-e1e0b4a8-923e-4788-b96f-99b922140826
This is again in gfxContext::PushNewDT(gfxContentType) like the other reproducible cases of OOM»small that we have.
Summary: crash in OOM | small while browsing on fr.wiktionary.org → crash in gfxContext::PushNewDT ( and OOM|small signature) while browsing on fr.wiktionary.org
Component: Untriaged → Graphics
Out of all of these reports, this one is the one I have the most luck reproducing.  I will attempt to get meaningful hg bisect results.
56ff6d55-e672-4708-8be0-90f4e2140827

In case you can't reproduce with the wiktionary example, http://www.sytadin.fr is another example that crashes (just double-click on the map).
I can reproduce this problem since the Nightly build 2014-08-26.

Regression range:

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=daa84204a11a&tochange=dc352a7bf234

I think this is a regression from bug 948265.
(In reply to blinky from comment #5)
> I think this is a regression from bug 948265.

I'm having trouble correlating the stack trace and crashing sites to bug 948265. That bug touches the internals of SVG and CSS filters. The crashing sites don't seem to enter the touched code paths- I put a breakpoint on the constructor of nsFilterInstance, which doesn't get hit. (nsFilterInstance is always created if there is a filter on the page.)

I also can't repro on either site on nightly 2014-08-27 on OS X, but I see the trace was from a Linux box.

The crash is at:
http://hg.mozilla.org/mozilla-central/annotate/dc352a7bf234/gfx/thebes/gfxContext.cpp#l1636
// If even this fails.. we're most likely just out of memory!
NS_ABORT_OOM(BytesPerPixel(format) * 64 * 64);

Bas added that comment- I'll CC him to see if he has some ideas.
(In reply to blinky from comment #5)
> http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=daa84204a11a&tochange=dc352a7bf234

Bug 1043560 is in that range, and in bug 1053934 (which is about a very similar crash) an invalid matrix from DrawImageInternal was identified as the cause. So my money is on bug 1043560.
We're having a large spike of OOM|small crashes in yesterday's data (2014-08-26) on Nightly, is the investigation here focused on that or on the crashes we already had before this date (and on other trains)?
Oddly my hg bisect attempt identified:

The first bad revision is:
changeset:   201437:3ef28e381ad6
user:        Ryan VanderMeulen <ryanvm@gmail.com>
date:        Mon Aug 25 13:22:44 2014 -0400
summary:     Bug 1057803 - Skip bug-1055034.js if ParallelJS isn't supported. r=terrence

I will try backing that out to see what happens.
OK was test only, but makes me think but makes me think bug 1055034 is the regressor.
I was "dragging" en.wikipedia.org-tabs around and arranging them...have crashed multiple times
I've ran into a very similar crash when opening http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:32000L0043:en:PDF and waiting a while.
Can you verify it also crashes with the same signature? I've seen a couple of these crashes, some of them are random, but in some sites they are constant.
Here is (one of my several) crash reports: https://crash-stats.mozilla.com/report/index/36d0ca48-22af-46ae-a2e7-31a752140828
Flags: needinfo?(fredbezies)
This is likely the cause of the recent spike in crashes on OOM|small in Nightly that started with the 2014082520 build, though it's hard to differentiate from the other OOM|small crashes.  We went from a couple of hundred crashes a day to thousands -- currently 7875/15568 crashes in the last 7 days. 

I'm marking it as a topcrash and will comment in bug 1058567 as well.
Flags: needinfo?(ryanvm)
Keywords: topcrash
Not sure why I'm being needinfo'd here. My push was a test-only change that couldn't possibly have caused this.
Flags: needinfo?(ryanvm)
I think I have the same problem when trying to search something on Google https://crash-stats.mozilla.com/report/index/d9fb0950-281b-41e7-9e1d-0de9f2140827 Is this the same problem?
What infos are needed from me ? I thought both crashes dump were enough ?!

Both were created with "official nightlies". Crashes started with 20140826030203 nightly. Previous one was OK.
Flags: needinfo?(fredbezies)
I'd be interested if this still happens with nightlies from today or later as we landed a fix for a case like this yesterday.
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #20)
> I'd be interested if this still happens with nightlies from today or later
> as we landed a fix for a case like this yesterday.

I could reproduce before and can't anymore with the latest nightly.
I can confirm that the last Nightly-update fixed my issues related to this bug!
Flags: needinfo?(fredbezies)
My crashes with drag & drop of google search tabs are fixed with todays nightly.
In that case, let's dupe it to bug 1053934 which has the patch that landed.
Status: NEW → RESOLVED
Closed: 10 years ago
Flags: needinfo?(fredbezies)
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.