Closed Bug 1165686 Opened 9 years ago Closed 9 years ago

Constantly crash on Windows taskbar preview [@ gfxContext::gfxContext(mozilla::gfx::DrawTarget*, mozilla::gfx::PointTyped<mozilla::gfx::UnknownUnits> const&) ]

Categories

(Core :: General, defect)

41 Branch
x86_64
Windows 7
defect
Not set
critical

Tracking

()

RESOLVED FIXED

People

(Reporter: semtex2, Unassigned, NeedInfo)

References

Details

(Keywords: crash, regression, topcrash)

Crash Data

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:41.0) Gecko/20100101 Firefox/41.0
Build ID: 20150516030207

Steps to reproduce:

Since 15.05 I'm able to crash Nightly: https://crash-stats.mozilla.com/report/index/ecc7c7a4-b0ab-4b3e-9302-cbf282150516

Enable takbar Tabs preview in Windows 7, hover on it, try to select other tab, Nightly will crash with above crash sig, important, this STR don't works for first run, You need to minimize Nightly and then try to recover window with other than selected tab.



Actual results:

My first report: http://forums.mozillazine.org/viewtopic.php?p=14157281#p14157281
Other confirms problem as well: http://forums.mozillazine.org/viewtopic.php?p=14157809#p14157809
http://forums.mozillazine.org/viewtopic.php?p=14159087#p14159087
Severity: normal → critical
Crash Signature: [@ gfxContext::gfxContext(mozilla::gfx::DrawTarget*, mozilla::gfx::PointTyped<mozilla::gfx::UnknownUnits> const&) ]
Keywords: crash, topcrash
OS: Unspecified → Windows 7
Hardware: Unspecified → x86_64
Confirmed, setting to NEW
Status: UNCONFIRMED → NEW
Ever confirmed: true
My crashes occurred first when trying to restore/maximize Nightly from a Taskbar Preview, but subsequently when (re)starting thereafter including when attempting to start in Safe Mode.

https://crash-stats.mozilla.com/report/index/bp-8a198037-dbe5-4f8d-99a7-fa1fb2150516
https://crash-stats.mozilla.com/report/index/bp-10b58f05-c55f-4883-9a41-c23862150516
https://crash-stats.mozilla.com/report/index/bp-3af6e19f-e97f-49a6-84f9-5534b2150516 (Safe Mode attempt)
Status: NEW → UNCONFIRMED
Ever confirmed: false
Status: UNCONFIRMED → NEW
Ever confirmed: true
I seems as though my posting of my comment inadvertently switched the bug back to UNCONFIRMED from NEW, thus I corrected this.
Partial regression window from m-c win32 builds:

20150514143801 cset 91617ce3c770 ok
20150514153404 cset 07e2e15703cb bad

Not sure I did this right, always have trouble with syntax:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=91617ce3c770&tochange=07e2e15703cb
[Tracking Requested - why for this release]:
tracking-fennec: --- → ?
tracking-e10s: --- → ?
tracking-p11: --- → ?
tracking-fennec: ? → ---
tracking-e10s: ? → ---
tracking-p11: ? → ---
I noticed this morning that this crash is occurring in 'plugin-container'-> mozglue.dll according to win7 Event Viewer. 

Faulting application name: plugin-container.exe, version: 41.0.0.5614, time stamp: 0x55578318
Faulting module name: mozglue.dll, version: 41.0.0.5614, time stamp: 0x555781a1
Exception code: 0x80000003
Fault offset: 0x00002620
Faulting process id: 0x1170
Faulting application start time: 0x01d090a3cd82fb7e
Faulting application path: J:\Program Files (x86)\Nightly\plugin-container.exe
Faulting module path: J:\Program Files (x86)\Nightly\mozglue.dll
Report Id: 3cbe9f1c-fc97-11e4-9bd6-00242155d461
(In reply to Jim Jeffery not reading bug-mail 1/2/11 from comment #6)
> I noticed this morning that this crash is occurring in 'plugin-container'->

True, I forgot to mention about "plugin-container" crash in same time when Nightly crash.
Also, disabling tabs preview in options fix problem for me, maybe some workaround for others before proper patch is out.
(In reply to Semtex from comment #7)
> True, I forgot to mention about "plugin-container" crash in same time when
> Nightly crash.
> Also, disabling tabs preview in options fix problem for me, maybe some
> workaround for others before proper patch is out.

I wonder if the tab previews is why I could not find a regression range with mozregression. I only had one tab preview instead of all of them. Multiple tab previews may be the threshold to trigger the crash.
Null mDT (so, null aTarget) here:
00 00000000`00225db0 000007fe`e8a5adb9 xul!gfxContext::gfxContext+0x1ba
01 00000000`00225e30 000007fe`e87f9f8d xul!mozilla::dom::CanvasRenderingContext2D::DrawWindow+0x2c9
02 00000000`00225fa0 000007fe`e781694d xul!mozilla::dom::CanvasRenderingContext2DBinding::drawWindow+0x2d5
03 00000000`00226130 000007fe`e76d211a xul!mozilla::dom::GenericBindingMethod+0xf5

Given the stack and regression range, I am tentatively suspecting:
Bug 857895 - Run canvas rendering asynchronously on OSX.
These crashes are not OSX, but there was some other refactoring in that change.

Matt could your change have caused this?
Flags: needinfo?(matt.woodrow)
Some more triage on m-i builds, I have found that the check-in for bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1163878

is causing the crash.
Blocks: 1163878
No longer blocks: 116878
Flags: needinfo?(matt.woodrow) → needinfo?(seth)
Sorry to ping-pong this, but I'm probably not the right person to debug this.
Flags: needinfo?(seth) → needinfo?(matt.woodrow)
FYI: A workaround for those of us being affected by this bug is to uncheck Tools>Options>General>Show tab previews in the Windows taskbar or toggling the pref browser.taskbar.previews.enable to false.
(In reply to WildcatRay from comment #12)
> FYI: A workaround for those of us being affected by this bug is to uncheck
> Tools>Options>General>Show tab previews in the Windows taskbar or toggling
> the pref browser.taskbar.previews.enable to false.

Confirmed this behaviour on Windows 8.1 as well. I experience the crash when Taskbar previews are enabled, and toggling this to false seems to fix the problem. This could be a workaround for now.
Installed latest Win64 build (Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:41.0) Gecko/20100101 Firefox/41.0 ID:20150519030202 CSet: 4fb7ff694bf5) and I can switch tabs using Windows taskbar previews.
Confirmed, no crashes with cset noted in comment #14 using latest Tinderbox m-c win32 builds.
Quick testing on m-i builds I find that this was fixed by backout of:

https://bugzilla.mozilla.org/show_bug.cgi?id=857895
Not sure how to resolve this since I found that crashes were being caused by 

https://bugzilla.mozilla.org/show_bug.cgi?id=1163878 

Yet today, seems fixed by backout of bug in comment #16,

Not being a coder, I myself don't see a link from those two bugs as to the root cause.
(In reply to Jim Jeffery not reading bug-mail 1/2/11 from comment #17)
> Not sure how to resolve this since I found that crashes were being caused by 
> 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1163878 
> 
> Yet today, seems fixed by backout of bug in comment #16,
> 
> Not being a coder, I myself don't see a link from those two bugs as to the
> root cause.

Was the backout in time for today's Nightly?
I got a deferment regression range.

Regression pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=d11b9d29d909&tochange=e01d80922187

Regressed by: Bug 857895


And Fixed Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=f2a751b7bbc7&tochange=55b0b5c5f18c

Fixed by:
 55b0b5c5f18c	Matt Woodrow — Backout e01d80922187 (Bug 857895) for causing crashes
> Fixed by:
>  55b0b5c5f18c	Matt Woodrow — Backout e01d80922187 (Bug 857895) for causing crashes

Indeed. No reports of this crash on the 0519 nightly.
Blocks: 857895
No longer blocks: 1163878
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.