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)
Tracking
()
People
(Reporter: ritu, Assigned: acomminos)
References
Details
(Keywords: crash)
Crash Data
Attachments
(1 file)
58 bytes,
text/x-review-board-request
|
karlt
:
review+
Sylvestre
:
approval-mozilla-aurora+
Sylvestre
:
approval-mozilla-beta+
|
Details |
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
Reporter | ||
Comment 1•8 years ago
|
||
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)
Comment 2•8 years ago
|
||
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
Updated•8 years ago
|
Component: General → Widget: Gtk
Product: Firefox → Core
Comment 4•8 years ago
|
||
(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.
Comment 5•8 years ago
|
||
https://bugzilla.mozilla.org/show_bug.cgi?id=1263791#c7 supports the 3.20-only theory.
Comment 6•8 years ago
|
||
[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.
tracking-firefox46:
--- → ?
Flags: needinfo?(lhenry)
Comment 7•8 years ago
|
||
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)
Comment 8•8 years ago
|
||
This would likely also affect 47 and 48. Tracking since this sounds like a high volume crash potentially.
status-firefox46:
--- → affected
status-firefox47:
--- → affected
status-firefox48:
--- → affected
tracking-firefox47:
--- → +
tracking-firefox48:
--- → +
Comment 9•8 years ago
|
||
From crash-stats and the signature you list I'm only seeing crashes on 47/48.
Comment 10•8 years ago
|
||
(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)
Comment 11•8 years ago
|
||
(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)
Comment 12•8 years ago
|
||
(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.
Comment 13•8 years ago
|
||
Crash only happens with e10s enabled so we don't need to fix this for 46.
tracking-e10s:
--- → ?
Comment 14•8 years ago
|
||
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
Comment 15•8 years ago
|
||
(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.
Reporter | ||
Comment 16•8 years ago
|
||
This crash signature is now the top-most crash on 47.0a2. I think we should block update on GTK 3.20.
Comment 17•8 years ago
|
||
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.
Reporter | ||
Comment 18•8 years ago
|
||
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)
Comment 19•8 years ago
|
||
(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)
Reporter | ||
Comment 20•8 years ago
|
||
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)
Comment 21•8 years ago
|
||
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)
Comment 22•8 years ago
|
||
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.
Comment 23•8 years ago
|
||
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.
Updated•8 years ago
|
Flags: needinfo?(felipc)
Reporter | ||
Comment 24•8 years ago
|
||
(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!
Comment 25•8 years ago
|
||
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?
Assignee | ||
Comment 26•8 years ago
|
||
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.
Comment 27•8 years ago
|
||
STR : 1) Drag a tab 2) release the dragged tab 3) crash
Updated•8 years ago
|
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]
Updated•8 years ago
|
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]
Comment 28•8 years ago
|
||
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)
Assignee | ||
Comment 30•8 years ago
|
||
(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)
Comment 31•8 years ago
|
||
(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.
Assignee | ||
Comment 32•8 years ago
|
||
Review commit: https://reviewboard.mozilla.org/r/48891/diff/#index_header See other reviews: https://reviewboard.mozilla.org/r/48891/
Attachment #8745174 -
Flags: review?(karlt)
Assignee | ||
Comment 33•8 years ago
|
||
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 34•8 years ago
|
||
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+
Comment 36•8 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/c4b070e15c3c
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
status-firefox49:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla48
Updated•8 years ago
|
Target Milestone: mozilla48 → mozilla49
Comment 37•8 years ago
|
||
Is there a bugzilla.gnome.org #BZ or shall I create one?
Flags: needinfo?(andrew)
Assignee | ||
Comment 39•8 years ago
|
||
(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)
Comment 40•8 years ago
|
||
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]
Updated•8 years ago
|
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]
Comment 41•8 years ago
|
||
(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.
Reporter | ||
Comment 42•8 years ago
|
||
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)
Assignee | ||
Comment 43•8 years ago
|
||
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?
Comment 44•8 years ago
|
||
Should we file a bug to re-enable it when the bug is fixed upstream?
Comment 45•8 years ago
|
||
(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)
Comment 46•8 years ago
|
||
(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.
Comment 47•8 years ago
|
||
(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.
Updated•8 years ago
|
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 48•8 years ago
|
||
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+
Reporter | ||
Comment 50•8 years ago
|
||
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)
Comment 51•8 years ago
|
||
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)
Comment 52•8 years ago
|
||
bugherder uplift |
https://hg.mozilla.org/releases/mozilla-beta/rev/5a86ed5f7b64
Flags: needinfo?(wkocher)
Comment 53•8 years ago
|
||
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)
Assignee | ||
Comment 54•8 years ago
|
||
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)
Updated•8 years ago
|
Crash Signature: (deleted)@0x393263] → (deleted)@0x393263]
[@ libgobject-2.0.so.0.4600.2@0x34e39]
[@ libgobject-2.0.so.0.4800.0@0x34d99]
Comment 55•8 years ago
|
||
Looks like this wasn't restricted to e10s. For example, https://crash-stats.mozilla.com/report/index/999cd673-9f82-456e-befd-579262160521.
(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)
Comment 57•8 years ago
|
||
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.
Comment 59•8 years ago
|
||
(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]
Comment 60•8 years ago
|
||
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.
Description
•