Closed Bug 1264454 Opened 8 years ago Closed 8 years ago

[e10s][GTK+ 3.20] crash in libgobject-2.0.so.0.4800.0@0x34920

Categories

(Core :: Widget: Gtk, defect)

47 Branch
Unspecified
Linux
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla49
Tracking Status
e10s ? ---
firefox46 + disabled
firefox47 + fixed
firefox48 + fixed
firefox49 --- fixed

People

(Reporter: ritu, Assigned: acomminos)

References

Details

(Keywords: crash)

Crash Data

Attachments

(1 file)

This bug was filed from the Socorro interface and is 
report bp-44c1af09-8139-4293-afe8-5bf352160407.
=============================================================

This signature jumped up 66 spots to be #2 top ranked crash on 47.0a2. First appearance: 03-24.

Product 	Version 	Count 	Percentage 	Installations
Firefox 	47.0a2 	           153 	  70.5% 	    90
I used the uplifts dashboard (http://people.mozilla.org/~klahnakoski/platform-history/release-history.html#) to see which patches landed on or before 03-24 and from this crash sign reports, it seems they are gtk related. 

We uplifted Bug 1211892 which was a linux only fix on 03-24 which was in widget: gtk. 

Karlt, could this be related to your patch from that bug?
Flags: needinfo?(karlt)
Thanks for the report.

(In reply to Ritu Kothari (:ritu) from comment #1)
> I used the uplifts dashboard
> (http://people.mozilla.org/~klahnakoski/platform-history/release-history.
> html#) to see which patches landed on or before 03-24 and from this crash
> sign reports, it seems they are gtk related. 

That link shows four empty boxes, each with a "Beta Uplifts by [...]" title.
Do you have another link, or additional instructions?

> We uplifted Bug 1211892 which was a linux only fix on 03-24 which was in
> widget: gtk. 
> 
> Karlt, could this be related to your patch from that bug?

I think that is unlikely, and we have some 47.0a2 reports with build id
20160307063925, which is before uplift of bug 1211892 to aurora
https://crash-stats.mozilla.com/report/index/fdff2bed-4512-4d93-841d-25ff62160413
https://crash-stats.mozilla.com/report/index/06c05ee0-b758-4f03-9e17-b204b2160413

https://crash-stats.mozilla.com/search/?signature=~libgobject-2.0.so.0&release_channel=Nightly&_facets=signature&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#facet-signature
shows that 90% of crashes in libgobject are with version 2.48.0, which was
released 2016-03-22 15:46:41 (GMT).  Arch may have released the changes
2016-03-16:
https://projects.archlinux.org/svntogit/packages.git/log/trunk?h=packages/glib2

I don't know how or if Arch gate their packages for those wanting stable
versions.

I suspect this is triggered by a change for GTK+ 3.20, which was released
2016-03-21 12:03:02 (GMT).
Arch may have even pulled in the change 2016-03-16:
https://projects.archlinux.org/svntogit/packages.git/log/trunk?h=packages/gtk3
Crash Signature: [@ libgobject-2.0.so.0.4800.0@0x34920] → [@ libgobject-2.0.so.0.4800.0@0x34920] [@ libgobject-2.0.so.0.4800.0@0x33e16]
Flags: needinfo?(karlt)
See Also: → 1263791
Component: General → Widget: Gtk
Product: Firefox → Core
(In reply to Nicholas Nethercote [:njn] from bug 1264511 comment #1)
> karlt, is there any hope of diagnosing the problem here, or is the unknown
> location of the top stack frame a show-stopper?

If the debug info packages for libgobject can be found, then addr2line can
give us more info.  See for example
https://bugzilla.mozilla.org/show_bug.cgi?id=1239962#c5

It looks like NativeShow() is calling gtk_widget_hide().  That is not in
libgobject and so the stack is missing info due to tail call optimization.
There may still be some clues from the gobject file and line number.

I considered the possibility of a null mShell, but the first thing
gtk_widget_hide() does is check for a null parameter.
There are exceptions if gtk is built with non-default options, which might
seem conceivable for Arch, but unlikely for Fedora.
[Tracking Requested - why for this release]:
We have a very frequent crash triggered by a change in the latest GTK version released 3 weeks ago.  Most distributions will not be using this version, but some of the more progressive distributions do.

One option we have available to consider is blocking updates to users with GTK 3.20 already installed.  That prevents this looking like a regression from a Mozilla update.  That doesn't prevent the user updating to 3.20 after updating Firefox, but that is only going on happen in on-the-edge distributions.

It doesn't seem quite right to turn back to GTK2 because of what at this stage seems likely to be a bug accidentally released in a GTK3 stable version, which could just as easily have happened after we release a GTK3 port.

ni?Liz to make sure you see this.
Flags: needinfo?(lhenry)
OK. how would we go about implementing that update block? Some sort of bouncer rule or is this a blocklist thing?   bhearsum I am asking you because it occurred to me maybe this is an update/balrog thing.
Flags: needinfo?(lhenry)
Flags: needinfo?(karlt)
Flags: needinfo?(bhearsum)
This would likely also affect 47 and 48. Tracking since this sounds like a high volume crash potentially.
From crash-stats and the signature you list I'm only seeing crashes on 47/48.
(In reply to Karl Tomlinson (ni?:karlt) from comment #6)
> [Tracking Requested - why for this release]:
> We have a very frequent crash triggered by a change in the latest GTK
> version released 3 weeks ago.  Most distributions will not be using this
> version, but some of the more progressive distributions do.
> 
> One option we have available to consider is blocking updates to users with
> GTK 3.20 already installed.  That prevents this looking like a regression
> from a Mozilla update.  That doesn't prevent the user updating to 3.20 after
> updating Firefox, but that is only going on happen in on-the-edge
> distributions.
> 
> It doesn't seem quite right to turn back to GTK2 because of what at this
> stage seems likely to be a bug accidentally released in a GTK3 stable
> version, which could just as easily have happened after we release a GTK3
> port.
> 
> ni?Liz to make sure you see this.

We could block anybody who is already on GTK 3.20 from getting updates to Firefox, but if the _only_ thing required for this crash is GTK 3.20 (ie: this isn't dependent on any specific Firefox version) I don't see how it would be of benefit - anybody already on GTK 3.20 would already be crashing, and preventing further Firefox updates wouldn't prevent users on older GTK versions from updating to GTK 3.20 and starting to crash.

It's easy to do if we want to do it, though.
Flags: needinfo?(bhearsum)
(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #9)
> From crash-stats and the signature you list I'm only seeing crashes on 47/48.

That's good news, thanks.

There are some reports on 46.0a2, but none from beta.
e.g.
https://crash-stats.mozilla.com/report/index/ce829cfc-0aed-46c5-b48e-9734f2160410
https://crash-stats.mozilla.com/report/index/ee500ae7-306a-43d2-898c-a36412160414

That may suggest that something that has been turned off on beta is involved
in triggering this crash.  e10s perhaps.
Flags: needinfo?(karlt)
(In reply to Ben Hearsum (:bhearsum) from comment #10)
> We could block anybody who is already on GTK 3.20 from getting updates to
> Firefox, but if the _only_ thing required for this crash is GTK 3.20 (ie:
> this isn't dependent on any specific Firefox version) I don't see how it
> would be of benefit - anybody already on GTK 3.20 would already be crashing,
> and preventing further Firefox updates wouldn't prevent users on older GTK
> versions from updating to GTK 3.20 and starting to crash.
> 
> It's easy to do if we want to do it, though.

Thanks, Ben.  Users on 45 won't be affected because that is built against GTK2
and so won't be affected by a GTK 3.20 install/"upgrade".

The option that could help users with 3.20 already would be to block
updates to users on 45 with 3.20 installed until we have a solution.

However, given this isn't happening on beta, it seems we have some time to
work out what is happening.
Crash only happens with e10s enabled so we don't need to fix this for 46.
Comment 13 based on https://bugzilla.mozilla.org/show_bug.cgi?id=1263791#c12
Summary: crash in libgobject-2.0.so.0.4800.0@0x34920 → [e10s][GTK+ 3.20] crash in libgobject-2.0.so.0.4800.0@0x34920
(In reply to Karl Tomlinson (back 26 Apr, ni?:karlt) from comment #12)
> (In reply to Ben Hearsum (:bhearsum) from comment #10)
> > We could block anybody who is already on GTK 3.20 from getting updates to
> > Firefox, but if the _only_ thing required for this crash is GTK 3.20 (ie:
> > this isn't dependent on any specific Firefox version) I don't see how it
> > would be of benefit - anybody already on GTK 3.20 would already be crashing,
> > and preventing further Firefox updates wouldn't prevent users on older GTK
> > versions from updating to GTK 3.20 and starting to crash.
> > 
> > It's easy to do if we want to do it, though.
> 
> Thanks, Ben.  Users on 45 won't be affected because that is built against
> GTK2
> and so won't be affected by a GTK 3.20 install/"upgrade".
> 
> The option that could help users with 3.20 already would be to block
> updates to users on 45 with 3.20 installed until we have a solution.
> 
> However, given this isn't happening on beta, it seems we have some time to
> work out what is happening.

Ah, I see. Just let me or someone else in RelEng know if we need to block updates - it's quick to set-up.
This crash signature is now the top-most crash on 47.0a2. I think we should block update on GTK 3.20.
I guess that https://crash-stats.mozilla.com/report/list?signature=libgtk-3.so.0.2000.3%400x393263 is the same thing essentially?

We also could just disable e10s when we detect GTK 3.20, until we actually find a solution to this and will be able to enable it.

That said, GTK system theming is broken with GTK 3.20 in any case, see bug 1234158, so that would make an update block a bit more reasonable. It won't help us much though when we get to release though as most people on Linux actually use distro-provided packages and they will get the new updates in any case, so at best this can only be a temporary disabling of updates to those people, esp. as most people who don't have GTK 3.20 yet will probably update to 3.20 when they already received an update that will crash with e10s on.
Hi Jim, this is a top crasher on 47.0a2. Disabling e10s on machines with GTK 3.20 installation seems like a good mitigation for this issue as it's e10s only. Can you comment on the feasibility of this? If feasible, could we get someone to work on a patch asap given that this is a top crash on Aurora? Thanks!
Flags: needinfo?(jmathies)
(In reply to Ritu Kothari (:ritu) from comment #18)
> Hi Jim, this is a top crasher on 47.0a2. Disabling e10s on machines with GTK
> 3.20 installation seems like a good mitigation for this issue as it's e10s
> only. Can you comment on the feasibility of this? If feasible, could we get
> someone to work on a patch asap given that this is a top crash on Aurora?
> Thanks!

Generally we want to avoid this if possible. Adding exclusions like this prolongs support for non-e10s code paths and testing. So I'd consider disabling e10s a last resort. 

I checked out last experiment and didn't find any crashes like this in it. That ran in beta 46 until April 4th. So it's possible this is tied in some way to a new patch on aurora.

Can we avoid using gtk 3 until they get this fixed?
Can we reach out to the somebody who work on the gtk project and ask them to investigate?
Flags: needinfo?(jmathies)
Hi Felipe, another mitigation for this issue is to eliminate GTK 3.20+ users from Beta47-e10s-eligible end-users so that this issue does not negatively impact e10s stability? Can we fine tune e10s experiment to that level? Thanks!
Flags: needinfo?(felipc)
Karlt: How can I access the gtk version through cpp, and is there a comparison function that I should use to compare it against "3.20"?  Also, is it possible to access it through JS?
Flags: needinfo?(karlt)
The gtk 3.20 check is here for instance, AFAIK is not accessible from JS.

http://mxr.mozilla.org/mozilla-central/source/widget/gtk/nsAppShell.cpp#197

looks like a problem in d&d code, I'll try to test that on Fedora 24 which has gtk3.20. There's a code for async rendering of the moved d&d content which may affect the e10s. There's also a possibility to disable animated d&d on gtk3.20 if it helps.
So the easiest and safest to do would be to add some code in the e10s enabling criteria (not the system add-on), which would basically blacklist users of gtk 3.20 from using e10s (similar to how add-ons, a11y is blocked). There would be a pref to force enable it but it's really not a good idea to recommend it.

Do we expect this to be a temporary thing that should be relatively easy to fix? I don't want to block more users for a significant period of time.

Only problem with this approach is if the test machines that runs our test suites from treeherder use gtk 3.20+. Does anyone know that? If that's the case it would need a workaround to run tests, and then it starts to get messy.
Flags: needinfo?(felipc)
(In reply to :Felipe Gomes (needinfo me!) from comment #23)
> So the easiest and safest to do would be to add some code in the e10s
> enabling criteria (not the system add-on), which would basically blacklist
> users of gtk 3.20 from using e10s (similar to how add-ons, a11y is blocked).
> There would be a pref to force enable it but it's really not a good idea to
> recommend it.

Jimm was not thrilled by this idea.
> 
> Do we expect this to be a temporary thing that should be relatively easy to
> fix? I don't want to block more users for a significant period of time.

Yes it should be a temporary thing. I am trying to find a GTK contact who I can reach out to for investigation of this crash and potential fix.
> 
> Only problem with this approach is if the test machines that runs our test
> suites from treeherder use gtk 3.20+. Does anyone know that? If that's the
> case it would need a workaround to run tests, and then it starts to get
> messy.

I see this crash (which is a top-ranked one) impacting stability/crash rates for e10s. I am not sure how much of an impact this is but if it is really bad and crosses the e10s experiment stability threshold, we might need to consider stopping the experiment before it's planned end date. 47.0b1 is only a week away so we could use this week to come up with ways to not let this crash affect e10s experiment. Hope that helps!
Another question: would you want all gtk 3.20+ users to be blocked from e10s (i.e., including Nightly and Aurora), or just users on Beta 47?
I've done some investigation into this, and the root of our problems appears to be the change in GTK 3.20 to reparent and unrealize the widget provided into gtk_drag_set_icon_widget. This was done to allow it to support non-toplevel widgets in https://git.gnome.org/browse/gtk+/commit/?id=5bb12474d975ee4b790c56e907e4e627120955a0. Prior to 3.20, the widget provided into gtk_drag_set_icon_widget was manipulated directly.

This causes quite a few problems for us- firstly, as mShell is a top level window when dragging tabs, it may not be reparented. More importantly, it is now unrealized, invalidating mXWindow in nsWindow and thus interfering with both our SHM and non-SHM drawing paths, both of which store the underlying X11 drawable.

Non-e10s firefox never goes down this path, as it may draw the source icon in-process.

I'd imagine the way to go (were we to workaround this in gecko) would be to avoid gtk_drag_set_icon_widget entirely, and wrap the window's drawable in a cairo surface and use gtk_drag_set_icon_surface. I'll take a look at hacking together a patch.
STR :
1) Drag a tab
2) release the dragged tab
3) crash
Crash Signature: [@ libgobject-2.0.so.0.4800.0@0x34920] [@ libgobject-2.0.so.0.4800.0@0x33e16] → [@ libgobject-2.0.so.0.4800.0@0x34920] [@ libgobject-2.0.so.0.4800.0@0x33e16] [@ libgobject-2.0.so.0.4800.0@0x348f0]
Crash Signature: [@ libgobject-2.0.so.0.4800.0@0x34920] [@ libgobject-2.0.so.0.4800.0@0x33e16] [@ libgobject-2.0.so.0.4800.0@0x348f0] → [@ libgobject-2.0.so.0.4800.0@0x34920] [@ libgobject-2.0.so.0.4800.0@0x33e16] [@ libgobject-2.0.so.0.4800.0@0x348f0] [@ libgobject-2.0.so.0.4800.0@0x346b0]
Clearing the needinfo that I had set, since Martin answered my question.

(In reply to Andrew Comminos [:acomminos] from comment #26)
> I've done some investigation into this, and the root of our problems appears
> to be the change in GTK 3.20 to reparent and unrealize the widget provided
> into gtk_drag_set_icon_widget. This was done to allow it to support
> non-toplevel widgets in
> https://git.gnome.org/browse/gtk+/commit/
> ?id=5bb12474d975ee4b790c56e907e4e627120955a0. Prior to 3.20, the widget
> provided into gtk_drag_set_icon_widget was manipulated directly.
> 
> This causes quite a few problems for us- firstly, as mShell is a top level
> window when dragging tabs, it may not be reparented. More importantly, it is
> now unrealized, invalidating mXWindow in nsWindow and thus interfering with
> both our SHM and non-SHM drawing paths, both of which store the underlying
> X11 drawable.
> 
> Non-e10s firefox never goes down this path, as it may draw the source icon
> in-process.
> 
> I'd imagine the way to go (were we to workaround this in gecko) would be to
> avoid gtk_drag_set_icon_widget entirely, and wrap the window's drawable in a
> cairo surface and use gtk_drag_set_icon_surface. I'll take a look at hacking
> together a patch.

Awesome! Looking forward to it
Flags: needinfo?(karlt)
Andrew, what's your schedule like - do you have time for this short term?
Flags: needinfo?(andrew)
(In reply to Milan Sreckovic [:milan] from comment #29)
> Andrew, what's your schedule like - do you have time for this short term?

Things are looking good, yes- I'll be going with a different approach than I originally suggested (I'd rather not add an additional execution path for a patch that will likely need to be uplifted), but I hope to get something together by later tonight.
Flags: needinfo?(andrew)
(In reply to Andrew Comminos [:acomminos] from comment #26)
> I've done some investigation into this, and the root of our problems appears
> to be the change in GTK 3.20 to reparent and unrealize the widget provided
> into gtk_drag_set_icon_widget. This was done to allow it to support
> non-toplevel widgets in
> https://git.gnome.org/browse/gtk+/commit/
> ?id=5bb12474d975ee4b790c56e907e4e627120955a0. Prior to 3.20, the widget
> provided into gtk_drag_set_icon_widget was manipulated directly.
> 
> This causes quite a few problems for us- firstly, as mShell is a top level
> window when dragging tabs, it may not be reparented. More importantly, it is
> now unrealized, invalidating mXWindow in nsWindow and thus interfering with
> both our SHM and non-SHM drawing paths, both of which store the underlying
> X11 drawable.
> 
> Non-e10s firefox never goes down this path, as it may draw the source icon
> in-process.

Which path?
Does non-e10s avoid drag popups?
Or how does in-process drawing avoid this? 

> I'd imagine the way to go (were we to workaround this in gecko) would be to
> avoid gtk_drag_set_icon_widget entirely, and wrap the window's drawable in a
> cairo surface and use gtk_drag_set_icon_surface.

Updating animation frames may be a bit trickier that way.

Adding handlers for the realize signal could get complicated, but I don't know
whether there is a better solution.
The way to go here (for now) is to disable drag popups on affected versions of GTK with commit 5bb12474d975ee4b790c56e907e4e627120955a0 until upstream ships a version of gtk_drag_set_icon_widget that does not destroy our provided widget at the end of a drag event (as per the documentation). Karl and I couldn't figure out a way to workaround the destruction in Gecko cleanly.

Once that happens, it should be quite doable to add a patch to deal with the unrealization of our nsWindow's widget.
Assignee: nobody → andrew
Status: NEW → ASSIGNED
Comment on attachment 8745174 [details]
MozReview Request: Bug 1264454 - Disable drag popups on GTK versions with a buggy gtk_drag_set_icon_widget. r?karlt

https://reviewboard.mozilla.org/r/48891/#review45737
Attachment #8745174 - Flags: review?(karlt) → review+
https://hg.mozilla.org/mozilla-central/rev/c4b070e15c3c
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla48
Target Milestone: mozilla48 → mozilla49
Is there a bugzilla.gnome.org #BZ or shall I create one?
Flags: needinfo?(andrew)
Blocks: 1265254
See Also: 1263791
(In reply to Martin Stránský from comment #37)
> Is there a bugzilla.gnome.org #BZ or shall I create one?

Just added gnome bug #765641.
Flags: needinfo?(andrew)
I assume libgtk-3.so.0.2000.3@0x393263 (https://crash-stats.mozilla.com/report/list?signature=libgtk-3.so.0.2000.3%400x393263) is the same crash.
Crash Signature: [@ libgobject-2.0.so.0.4800.0@0x34920] [@ libgobject-2.0.so.0.4800.0@0x33e16] [@ libgobject-2.0.so.0.4800.0@0x348f0] [@ libgobject-2.0.so.0.4800.0@0x346b0] → [@ libgobject-2.0.so.0.4800.0@0x34920] [@ libgobject-2.0.so.0.4800.0@0x33e16] [@ libgobject-2.0.so.0.4800.0@0x348f0] [@ libgobject-2.0.so.0.4800.0@0x346b0] [@ libgtk-3.so.0.2000.3@0x393263]
Crash Signature: [@ libgobject-2.0.so.0.4800.0@0x34920] [@ libgobject-2.0.so.0.4800.0@0x33e16] [@ libgobject-2.0.so.0.4800.0@0x348f0] [@ libgobject-2.0.so.0.4800.0@0x346b0] [@ libgtk-3.so.0.2000.3@0x393263] → [@ libgobject-2.0.so.0.4800.0@0x34920] [@ libgobject-2.0.so.0.4800.0@0x33e16] [@ libgobject-2.0.so.0.4800.0@0x348f0] [@ libgobject-2.0.so.0.4800.0@0x346b0] [@ libgtk-3.so.0.2000.3@0x393263] [@ libgtk-3.so.0.2000.3@0x3932b3]
(In reply to Marco Castelluccio [:marco] from comment #40)
> I assume libgtk-3.so.0.2000.3@0x393263
> (https://crash-stats.mozilla.com/report/list?signature=libgtk-3.so.0.2000.
> 3%400x393263) is the same crash.

I don't know. We have a whole raft of libgtk-3.so crashes with different versions and addresses. I emailed karlt just today to ask if they are related.
Hi Karl, Andrew: Should we consider uplifting this fix to Beta47 and Aurora48? This remains a top crasher on Fx47.
Flags: needinfo?(karlt)
Flags: needinfo?(andrew)
Comment on attachment 8745174 [details]
MozReview Request: Bug 1264454 - Disable drag popups on GTK versions with a buggy gtk_drag_set_icon_widget. r?karlt

Yup, this is a good candidate for uplift.

Approval Request Comment
[Feature/regressing bug #]: N/A
[User impact if declined]: Dragging tabs on GTK 3.20 with e10s enabled will crash.
[Describe test coverage new/current, TreeHerder]: N/A (dnd not tested)
[Risks and why]: Very little risk, we're simply falling back to GTK's default drag icon. The user won't have tab drag images with e10s enabled on GTK 3.20, but it's better than crashing. We'll have to wait for GTK 3.22 to get those back with the current drag infrastructure.
[String/UUID change made/needed]: N/A
Flags: needinfo?(andrew)
Attachment #8745174 - Flags: approval-mozilla-beta?
Attachment #8745174 - Flags: approval-mozilla-aurora?
Should we file a bug to re-enable it when the bug is fixed upstream?
(In reply to Marco Castelluccio [:marco] from comment #40)
> I assume libgtk-3.so.0.2000.3@0x393263
> (https://crash-stats.mozilla.com/report/list?signature=libgtk-3.so.0.2000.
> 3%400x393263) is the same crash.

Yes, thanks.  Anything with libgtk-3.so.0.2000 and
nsDragService::SetDragIcon(_GdkDragContext*) is the same crash.
Flags: needinfo?(karlt)
(In reply to Ritu Kothari (:ritu) from comment #42)
> Hi Karl, Andrew: Should we consider uplifting this fix to Beta47 and
> Aurora48? This remains a top crasher on Fx47.

Yes, please.
(In reply to Marco Castelluccio [:marco] from comment #44)
> Should we file a bug to re-enable it when the bug is fixed upstream?

Yes, please.  Re-enabling will also need something to deal with or block GTK now unrealizing Gecko's GtkWindow.
Crash Signature: [@ libgobject-2.0.so.0.4800.0@0x34920] [@ libgobject-2.0.so.0.4800.0@0x33e16] [@ libgobject-2.0.so.0.4800.0@0x348f0] [@ libgobject-2.0.so.0.4800.0@0x346b0] [@ libgtk-3.so.0.2000.3@0x393263] [@ libgtk-3.so.0.2000.3@0x3932b3] → [@ libgobject-2.0.so.0.4800.0@0x34920] [@ libgobject-2.0.so.0.4800.0@0x33e16] [@ libgobject-2.0.so.0.4800.0@0x348f0] [@ libgobject-2.0.so.0.4800.0@0x346b0] [@ libgtk-3.so.0.2000.3@0x393263] [@ libgtk-3.so.0.2000.3@0x3932b3] [@ libgtk-3.so.0.2000.3 (…
Comment on attachment 8745174 [details]
MozReview Request: Bug 1264454 - Disable drag popups on GTK versions with a buggy gtk_drag_set_icon_widget. r?karlt

We need it for aurora.
Attachment #8745174 - Flags: approval-mozilla-beta?
Attachment #8745174 - Flags: approval-mozilla-beta+
Attachment #8745174 - Flags: approval-mozilla-aurora?
Attachment #8745174 - Flags: approval-mozilla-aurora+
Hi Ryan, Wes, we are also need this uplifted to Beta47, this was a top-crasher on 47.0a2
Flags: needinfo?(wkocher)
Flags: needinfo?(ryanvm)
Yeah, I figured one of Wes/Tomcat would get it with their regular uplifts. I just did Aurora so we could get new Linux nightlies spun for it.
Flags: needinfo?(ryanvm)
Andrew, with this bug fixed, can I know remove the restriction to block gtk 3.20 users from e10s? (bug 1266213).

Did the fix get rid of all of the crash signatures tracked in this bug?
Flags: needinfo?(andrew)
Yes, I believe that the restriction can be lifted.  I don't see any crashes in the signatures attached to this bug using releases after the patch.
Flags: needinfo?(andrew)
Crash Signature: (deleted)@0x393263] → (deleted)@0x393263] [@ libgobject-2.0.so.0.4600.2@0x34e39] [@ libgobject-2.0.so.0.4800.0@0x34d99]
(In reply to Marco Castelluccio [:marco] from comment #55)
> Looks like this wasn't restricted to e10s. For example,
> https://crash-stats.mozilla.com/report/index/999cd673-9f82-456e-befd-
> 579262160521.

How do you tell from a crash report whether it's e10s or not?  I still haven't figured that out :)
Flags: needinfo?(mcastelluccio)
I don't know if this is reliable, I went to the "Metadata" tab and saw `"e10sEnabled":false` in the "TelemetryEnvironment" section.
Flags: needinfo?(mcastelluccio)
Ah.  You have higher privileges than I do then.  I don't have 'TelemtryEnvironment' in Metadata or any other tab.
(In reply to Marco Castelluccio [:marco] from comment #55)
> Looks like this wasn't restricted to e10s. For example,
> https://crash-stats.mozilla.com/report/index/999cd673-9f82-456e-befd-
> 579262160521.

[@ libgobject-2.0.so.0.4600.2@0x34e39 ]
https://crash-stats.mozilla.com/report/index/18ccdf51-ef0b-4619-ab17-c31fc2160526

That's GTK+ 3.16.7 and so not this bug.
libgio-2.0.so.0.4600 on the stack and comments like
'Crash occurs when I download an XML file and choose "open with gedit"'
=> bug 1244305.

[@ libgobject-2.0.so.0.4800.0@0x34d99]
https://crash-stats.mozilla.com/report/index/ba9d56a9-e7cc-4d32-9f9f-13f002160602

Similarly, libgtk-3.so.0.1800.9 is GTK+ 3.18.9.
"Crash when attempting to choose application to open downloaded file in Firefox on Ubuntu 16.04 LTS" is bug 1244305.
Crash Signature: (deleted)@0x393263] [@ libgobject-2.0.so.0.4600.2@0x34e39] [@ libgobject-2.0.so.0.4800.0@0x34d99] → (deleted)@0x393263]
Sorry, for some reason I confused this bug with bug 1244305...
You need to log in before you can comment on or make changes to this bug.