Re: ‘staging’ and GNOME updates

[Timothy Sample <samplet@ngyro.com>]

Ricardo Wurmus <rekado@elephly.net> writes:

>> After running GNOME 3.28 for a while, I’ve 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’ve turned on
>> notifications there), and I can’t seem to fix it.
>>
>> Interestingly, there is a discussion about this on the Arch Linux forums
>> <https://bbs.archlinux.org/viewtopic.php?pid=1778640>.  I’m not sure if
>> there’s anything useful for us in there, though.
>
> This message seems relevant:
>
>     https://bbs.archlinux.org/viewtopic.php?pid=1778640#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’t 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 <https://issues.guix.info/issue/33693>.

>> 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 – it tells GTK+ to run this thread from the
>> “load_texture_async” function in “st-texture-cache.c”.
>>
>> I think the “bad” user files are not the root cause here.  There’s
>> 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 (“js/ui/notificationDaemon.js”).  I
>> glanced at it and its Git history, but couldn’t find anything.
>
> I don’t think it’s notifications per se, but rendering SVGs.  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 — that’s 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’m guessing that
> the problem is entirely due to using an outdated variant of librsvg.
>
> What do you think?

To be honest, I don’t know.  From my side, I haven’t seen anything that
suggests SVGs might be the problem.  I just checked an application that
no longer has an icon since the update, and it doesn’t provide an SVG.
On the other hand, Emacs, which does provide an SVG, is fine.  I can’t
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’m seeing is fallback code that gets called when SVGs aren’t
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’ll try and patch everything later 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’t need it).  Either way, I will try and test this.  If nothing
else, it might fix the bug linked above.


-- Tim