From mboxrd@z Thu Jan 1 00:00:00 1970 From: Timothy Sample Subject: Re: =?utf-8?B?4oCYc3RhZ2luZ+KAmQ==?= and GNOME updates Date: Wed, 24 Apr 2019 15:19:56 -0400 Message-ID: <871s1rnrc3.fsf@ngyro.com> References: <871s3a4xd4.fsf@gnu.org> <87wokjyuw4.fsf@fastmail.com> <87muld8xuo.fsf@gnu.org> <87y34xzez8.fsf@elephly.net> <87zhpaydem.fsf_-_@gnu.org> <87imvler9u.fsf@elephly.net> <87bm1d8sxv.fsf@gnu.org> <87ef68ibfy.fsf@elephly.net> <87r2a3o39s.fsf@gnu.org> <87sgujgchr.fsf@gnu.org> <878swa3nm9.fsf@elephly.net> <87h8ayfstx.fsf@ngyro.com> <87zhopd7x4.fsf@gnu.org> <87d0le1h38.fsf@gnu.org> <87zhoh5gwu.fsf@elephly.net> <8736m9j9rx.fsf@gnu.org> <87r29s60wp.fsf@elephly.net> <87a7ggoxf2.fsf@ngyro.com> <87o94v6ghe.fsf@elephly.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([209.51.188.92]:53076) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hJNZU-0006F7-UK for guix-devel@gnu.org; Wed, 24 Apr 2019 15:28:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hJNR2-0006cE-UK for guix-devel@gnu.org; Wed, 24 Apr 2019 15:20:02 -0400 List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Ricardo Wurmus Cc: Guix-devel Ricardo Wurmus writes: >> After running GNOME 3.28 for a while, I=E2=80=99ve had several crashes. = It used >> to crash whenever I opened a URL from Emacs, but fiddling with dconf has >> fixed that. It currently crashes every time I run ERC (I=E2=80=99ve tur= ned on >> notifications there), and I can=E2=80=99t seem to fix it. >> >> Interestingly, there is a discussion about this on the Arch Linux forums >> . I=E2=80=99m no= t sure if >> there=E2=80=99s anything useful for us in there, though. > > This message seems relevant: > > https://bbs.archlinux.org/viewtopic.php?pid=3D1778640#p1778640 > > My issue was caused by using ubuntu-cairo. It was incompatible with > librsvg 2.42.3, which caused a crash when gnome attempted to load an > SVG when trying to display the notification. It also caused the > close window button to not appear in the overview. I did see this, but I couldn=E2=80=99t really connect it to the problem at = hand. It is interesting that the close window buttons in the overview are a problem for us, too . >> It looks like GNOME Shell passes some bad icon data into GTK+, which >> results in a null filename that gets dereferenced. (GNOME Shell is not >> in the backtrace =E2=80=93 it tells GTK+ to run this thread from the >> =E2=80=9Cload_texture_async=E2=80=9D function in =E2=80=9Cst-texture-cac= he.c=E2=80=9D. >> >> I think the =E2=80=9Cbad=E2=80=9D user files are not the root cause here= . There=E2=80=99s >> definitely something wrong with notifications. (I just plugged in a USB >> drive and, sure enough, GNOME Shell crashed.) The notification daemon >> code is written in JavaScript (=E2=80=9Cjs/ui/notificationDaemon.js=E2= =80=9D). I >> glanced at it and its Git history, but couldn=E2=80=99t find anything. > > I don=E2=80=99t think it=E2=80=99s notifications per se, but rendering SV= Gs. When > application_state exists, GNOME shell tries to restore application > windows and their icons are likely SVG files that should be rendered. > > Chris reported elsewhere that GNOME sometimes crashes when the Activity > tab is accessed =E2=80=94 that=E2=80=99s where the application starter is= , which > displays icons. > > I believe we should be using librsvg-next in the closure of gnome-shell. > We may also want to use gdk-pixbuf+svg instead of just gdk-pixbuf, but > again replacing librsvg with librsvg-next throughout. I=E2=80=99m guessi= ng that > the problem is entirely due to using an outdated variant of librsvg. > > What do you think? To be honest, I don=E2=80=99t know. From my side, I haven=E2=80=99t seen a= nything that suggests SVGs might be the problem. I just checked an application that no longer has an icon since the update, and it doesn=E2=80=99t provide an S= VG. On the other hand, Emacs, which does provide an SVG, is fine. I can=E2=80= =99t find anything in the backtrace that suggests SVG problems either. That said, software is complicated and this is best lead we have. Maybe the crash I=E2=80=99m seeing is fallback code that gets called when SVGs ar= en=E2=80=99t quite working. I did try patching GTK+ the other day (for testing something else), but gave up when I realized that it means recompiling WebKitGTK, which takes forever. I=E2=80=99ll try and patch everything late= r and leave my computer to compile overnight. Or, maybe I could pull Epiphany out of our GNOME package, and avoid WebKitGTK (now that GNOME Shell doesn=E2=80=99t need it). Either way, I will try and test this. If nothing else, it might fix the bug linked above. -- Tim