startup crash in liboxygen-gtk.so@0x in firefox 46

RESOLVED WORKSFORME

Status

()

--
critical
RESOLVED WORKSFORME
2 years ago
10 months ago

People

(Reporter: philipp, Unassigned)

Tracking

({crash, regression, topcrash-linux})

46 Branch
Unspecified
Linux
crash, regression, topcrash-linux
Points:
---

Firefox Tracking Flags

(firefox46+ wontfix, firefox47 wontfix, firefox48 fix-optional, firefox49 fix-optional, firefox50 fix-optional)

Details

(crash signature)

(Reporter)

Description

2 years ago
This bug was filed from the Socorro interface and is 
report bp-a6ee7485-147e-4583-98f9-658e72160427.
=============================================================
Related Bugs

Crashing Thread (0)
Frame 	Module 	Signature 	Source
Ø 0 	liboxygen-gtk.so 	liboxygen-gtk.so@0xfd283 	
Ø 1 	liboxygen-gtk.so 	liboxygen-gtk.so@0x33577f 	
Ø 2 	libxcb.so.1.1.0 	libxcb.so.1.1.0@0xb5f9 	
3 	firefox 	malloc 	memory/mozjemalloc/jemalloc.c
Ø 4 	libglib-2.0.so.0.3600.4 	libglib-2.0.so.0.3600.4@0x4cd50 	
Ø 5 	liboxygen-gtk.so 	liboxygen-gtk.so@0x3357af 	
Ø 6 	liboxygen-gtk.so 	liboxygen-gtk.so@0x33578f 	
Ø 7 	libgtk-3.so.0.800.2 	libgtk-3.so.0.800.2@0x2129e1 	
8 	libxul.so 	moz_gtk_widget_paint 	widget/gtk/gtk3drawing.c
9 	libxul.so 	nsNativeThemeGTK::DrawWidgetBackground(nsRenderingContext*, nsIFrame*, unsigned char, nsRect const&, nsRect const&) 	widget/gtk/nsNativeThemeGTK.cpp
10 	libxul.so 	nsDisplayThemedBackground::PaintInternal(nsDisplayListBuilder*, nsRenderingContext*, nsRect const&, nsRect*) 	layout/base/nsDisplayList.cpp
11 	libxul.so 	mozilla::FrameLayerBuilder::PaintItems(nsTArray<mozilla::FrameLayerBuilder::ClippedDisplayItem>&, mozilla::gfx::IntRectTyped<mozilla::gfx::UnknownUnits> const&, gfxContext*, nsRenderingContext*, nsDisplayListBuilder*, nsPresContext*, mozilla::gfx::IntPointTyped<mozilla::gfx::UnknownUnits> const&, float, float, int) 	layout/base/FrameLayerBuilder.cpp
12 	libxul.so 	mozilla::FrameLayerBuilder::DrawPaintedLayer(mozilla::layers::PaintedLayer*, gfxContext*, mozilla::gfx::IntRegionTyped<mozilla::gfx::UnknownUnits> const&, mozilla::gfx::IntRegionTyped<mozilla::gfx::UnknownUnits> const&, mozilla::layers::DrawRegionClip, mozilla::gfx::IntRegionTyped<mozilla::gfx::UnknownUnits> const&, void*) 	layout/base/FrameLayerBuilder.cpp
13 	libxul.so 	mozilla::layers::ClientPaintedLayer::PaintThebes() 	gfx/layers/client/ClientPaintedLayer.cpp
14 	libxul.so 	mozilla::layers::ClientPaintedLayer::RenderLayerWithReadback(mozilla::layers::ReadbackProcessor*) 	gfx/layers/client/ClientPaintedLayer.cpp
15 	libxul.so 	mozilla::layers::ClientContainerLayer::RenderLayer() 	gfx/layers/client/ClientContainerLayer.h
16 	libxul.so 	mozilla::layers::ClientLayerManager::EndTransactionInternal(void (*)(mozilla::layers::PaintedLayer*, gfxContext*, mozilla::gfx::IntRegionTyped<mozilla::gfx::UnknownUnits> const&, mozilla::gfx::IntRegionTyped<mozilla::gfx::UnknownUnits> const&, mozilla::layers::DrawRegionClip, mozilla::gfx::IntRegionTyped<mozilla::gfx::UnknownUnits> const&, void*), void*, mozilla::layers::LayerManager::EndTransactionFlags) 	gfx/layers/client/ClientLayerManager.cpp
17 	libxul.so 	mozilla::layers::ClientLayerManager::EndTransaction(void (*)(mozilla::layers::PaintedLayer*, gfxContext*, mozilla::gfx::IntRegionTyped<mozilla::gfx::UnknownUnits> const&, mozilla::gfx::IntRegionTyped<mozilla::gfx::UnknownUnits> const&, mozilla::layers::DrawRegionClip, mozilla::gfx::IntRegionTyped<mozilla::gfx::UnknownUnits> const&, void*), void*, mozilla::layers::LayerManager::EndTransactionFlags) 	gfx/layers/client/ClientLayerManager.cpp
18 	libxul.so 	nsDisplayList::PaintRoot(nsDisplayListBuilder*, nsRenderingContext*, unsigned int) 	layout/base/nsDisplayList.cpp
19 	libxul.so 	nsLayoutUtils::PaintFrame(nsRenderingContext*, nsIFrame*, nsRegion const&, unsigned int, unsigned int) 	layout/base/nsLayoutUtils.cpp
20 	libxul.so 	PresShell::Paint(nsView*, nsRegion const&, unsigned int) 	layout/base/nsPresShell.cpp
21 	libxul.so 	nsViewManager::ProcessPendingUpdatesPaint(nsIWidget*) 	view/nsViewManager.cpp
22 	libxul.so 	nsViewManager::ProcessPendingUpdatesForView(nsView*, bool) 	view/nsViewManager.cpp
23 	libxul.so 	nsRefreshDriver::Tick(long, mozilla::TimeStamp) 	layout/base/nsRefreshDriver.cpp
24 	libxul.so 	mozilla::RefreshDriverTimer::TickRefreshDrivers(long, mozilla::TimeStamp, nsTArray<RefPtr<nsRefreshDriver> >&) 	layout/base/nsRefreshDriver.cpp
25 	libxul.so 	mozilla::RefreshDriverTimer::Tick(long, mozilla::TimeStamp) 	layout/base/nsRefreshDriver.cpp
26 	libxul.so 	mozilla::VsyncRefreshDriverTimer::RefreshDriverVsyncObserver::TickRefreshDriver(mozilla::TimeStamp) 	layout/base/nsRefreshDriver.cpp
27 	libxul.so 	nsRunnableMethodImpl<void (mozilla::VsyncRefreshDriverTimer::RefreshDriverVsyncObserver::*)(mozilla::TimeStamp), true, mozilla::TimeStamp>::Run() 	xpcom/glue/nsThreadUtils.h
28 	libxul.so 	nsThread::ProcessNextEvent(bool, bool*) 	xpcom/threads/nsThread.cpp
29 	libxul.so 	NS_ProcessNextEvent(nsIThread*, bool) 	xpcom/glue/nsThreadUtils.cpp
30 	libxul.so 	mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) 	ipc/glue/MessagePump.cpp
31 	libxul.so 	MessageLoop::Run() 	ipc/chromium/src/base/message_loop.cc
32 	libxul.so 	nsBaseAppShell::Run() 	widget/nsBaseAppShell.cpp
33 	libxul.so 	nsAppStartup::Run() 	toolkit/components/startup/nsAppStartup.cpp
34 	libxul.so 	XREMain::XRE_mainRun() 	toolkit/xre/nsAppRunner.cpp
35 	libxul.so 	XREMain::XRE_main(int, char**, nsXREAppData const*) 	toolkit/xre/nsAppRunner.cpp
36 	libxul.so 	XRE_main 	toolkit/xre/nsAppRunner.cpp
37 	firefox 	do_main 	browser/app/nsBrowserApp.cpp
38 	firefox 	main 	browser/app/nsBrowserApp.cpp
Ø 39 	libc-2.17.so 	libc-2.17.so@0x21d04 	
40 	firefox 	_init 	
41 	firefox 	firefox@0x853b 	
42 	firefox 	__libc_csu_fini 	
43 	firefox 	firefox@0x853b 	
44 	firefox 	_start

this is a theme related startup crash affecting linux users after the update to firefox 46. in early 46.0 crash data these signatures crash makes up the absolute majority of crashes on linux.
tracking-firefox46: ? → +
Karl, any ideas? I'm pinging you since the stack says gtk3. Is this a particular theme?
Flags: needinfo?(karlt)

Comment 2

2 years ago
I have the same issue on the KDE distro, this only affects oxygen-gtk theme.
This is a startup crash and in the top 10 of the Firefox 46 top crashers, so pretty serious.
Keywords: topcrash-linux
(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #1)
> Is this a particular theme?

FYI, https://en.wikipedia.org/wiki/Oxygen_Project
"The Oxygen theme set is used by default for Plasma Workspaces in most Linux distributions, like Fedora,[2] Kubuntu,[3] and openSUSE."
Component: General → Widget: Gtk
This is https://bugs.kde.org/show_bug.cgi?id=331020
which was fixed in 
https://quickgit.kde.org/?p=oxygen-gtk.git&a=shortlog&h=vgtk3-1.3.4

Ubuntu have back-ported the fix [1], and so crash rates should be dropping.
Fedora took the fix long ago. [2]

The oxygen-gtk engine was assuming that the cairo_context_t passed to
gtk_render_frame() is the same as previously passed with a "draw" signal
emission on the widget.  The rendering API was designed to not even need a
widget [3] and so Gecko does not emit a "draw" signal on a widget.

The engine registers an "OxygenVersionContainer" type with
"VersionString" qdata, so it would possible to detect old versions and switch to a fallback theme, but we wouldn't know whether old versions have a back-ported fix.

[1] https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1575781
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1065099
[3] https://bugzilla.gnome.org/show_bug.cgi?id=735211#c7
Flags: needinfo?(karlt)
Duplicate of this bug: 1267988
I don't see this in the top crashes for 46.0.1 any more. 
Is there still something more to do from our side (a bit late to be asking this for beta, but, say, for 48)  or would you call this fixed?
Flags: needinfo?(mcastelluccio)
Flags: needinfo?(karlt)
We could call this WORKSFORME.

I would probably take a patch to fallback to the default GTK theme, even though that would affect users with fixed oxygen-gtk, but writing the patch is not a priority.
Flags: needinfo?(karlt)
The crash still exists, so I wouldn't call it WORKSFORME (but WONTFIX if we don't plan to fix it).

It isn't a top crasher anymore on Firefox 46 (expected, since the Linux population is extremely small on Release compared to the Windows one), but it isn't a top crasher in Firefox 47 either.

This means that either the affected users managed to update oxygen-gtk, or that they stopped using Firefox (since it crashed on startup and so they couldn't use it anymore).
Crash Signature: [@ liboxygen-gtk.so@0xfd283] [@ liboxygen-gtk.so@0xf0e4d] [@ liboxygen-gtk.so@0xf9c3c] [@ liboxygen-gtk.so@0x1009e6] [@ liboxygen-gtk.so@0x1021a1] [@ liboxygen-gtk.so@0x102bb6] [@ liboxygen-gtk.so@0x103b80] [@ liboxygen-gtk.so@0xf7456] → [@ liboxygen-gtk.so@0xfd283] [@ liboxygen-gtk.so@0xf0e4d] [@ liboxygen-gtk.so@0xf9c3c] [@ liboxygen-gtk.so@0x1009e6] [@ liboxygen-gtk.so@0x1021a1] [@ liboxygen-gtk.so@0x102bb6] [@ liboxygen-gtk.so@0x103b80] [@ liboxygen-gtk.so@0xf7456] [@ liboxyge…
Flags: needinfo?(mcastelluccio)
Thanks.  Leaving the bug open is fine.  WONTFIX is only if we would not take a patch.  The Linux port depends on contributors offering to fix bugs, and so we don't close bugs just because no Mozilla employees are fixing them.
(In reply to Karl Tomlinson (ni?:karlt) from comment #8)
> I would probably take a patch to fallback to the default GTK theme, even
> though that would affect users with fixed oxygen-gtk, but writing the patch
> is not a priority.

To clarify, fallback would only occur in old versions of oxygen-gtk (even though some of those old versions may be patched by the distribution).

This situation is a little complex because different versions of GTK require different theming engines and so there are several branches of oxygen-gtk.  I don't know exactly how many were affected, or at which stage.
Should we do more evangelism on this one?
Problems with oxygen-gtk include this and bug 1268395.
They are each fixed by changes to oxygen-gtk.

Reporting bugs to the distributions that are still shipping affected versions seems appropriate.  It would be helpful if people experiencing the problems could do that.
Updating status flags.
status-firefox46: affected → wontfix
status-firefox47: --- → wontfix
status-firefox48: --- → affected
status-firefox49: --- → affected
Can we call this fixed? Marking fix-optional for now.  There are a few scattered crashes remaining and I don't think anyone is planning on submitting a patch to fix anything on our side of things.
status-firefox48: affected → fix-optional
status-firefox49: affected → fix-optional
status-firefox50: --- → fix-optional
Flags: needinfo?(karlt)
Resolution WFM meaning fixed in oxygen-gtk.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Flags: needinfo?(karlt)
Resolution: --- → WORKSFORME

Comment 17

2 years ago
I've reported this for RHEL 7:
https://bugzilla.redhat.com/show_bug.cgi?id=1376205

Comment 18

2 years ago
This is fixed even in RHEL / Centos 7 now.
You need to log in before you can comment on or make changes to this bug.