gnome-shell 3.38.2-1ubuntu1~20.10.1 is crashing with assertion failures in st_bin_get_preferred_width

https://errors.ubuntu.com/problem/4f12318421d8c95c357e2db953aa75b2cdcacdfa

https://errors.ubuntu.com/problem/0b6c9d77c0cae16f6672a684255ddd3dde92aabc

https://errors.ubuntu.com/problem/0447ee3910962f0195cdad658227957b305b14e2

Incomplete because we don't have any line number info, any log messages telling us what the assertion is, or any test case.

We're left to guess, and my guess is either:

* An inlined function with an explicit assertion; or

* One of these macros:

  StBinPrivate *priv = st_bin_get_instance_private (ST_BIN (self));
  StThemeNode *theme_node = st_widget_get_theme_node (ST_WIDGET (self));

The assertion failure might not even be in st_bin_get_preferred_width at all. That might be a red herring caused by lack of debug symbols.

I suspect this might be an old bug that has always existed. Only we didn't hit it until now because bug 1898005 would crash first. Now bug 1898005 is fixed in 3.38.2, this other issue is able to crash instead :P

https://gitlab.gnome.org/GNOME/gnome-shell/-/commit/176133e6ac

Is there anyone here who is experiencing this bug, or can reproduce it?

I wonder if it could be a bug related to the crash reporting software instead. What looks strange (but maybe I'm not reading it correctly) is that the publishing history indicates it was brought back to 0% even before it was put at 10% : https://launchpad.net/ubuntu/groovy/amd64/gnome-shell

It seems to me it should at least collect some data before phasing out, so maybe the bug is somewhere else or it has been blocked manually...

The qemu package looks affected too, maybe it's not a coincidence that it has been published only a few days before : https://launchpad.net/ubuntu/groovy/amd64/qemu

Maybe old bug reports are incorrectly attached to newer packages.

Focal, Bionic and others also have "zombie updates" : update-notifier on Focal, gnome-calculator and nautilus on Bionic. Those last two have been zombified more than one year ago (moreover at the same time it seems). Have a look here : https://people.canonical.com/~ubuntu-archive/phased-updates.html

Considering all those first go through proposed, the phasing system is an ultimate security system in case something slipped through, which should happen rarely.

> Maybe old bug reports are incorrectly attached to newer packages.

That would certainly explain the weird stack traces and lack of working debug symbols.

Re comment #6:

"I wonder if it could be a bug related to the crash reporting software instead. What looks strange (but maybe I'm not reading it correctly) is that the publishing history indicates it was brought back to 0% even before it was put at 10% : https://launchpad.net/ubuntu/groovy/amd64/gnome-shell

It seems to me it should at least collect some data before phasing out, so maybe the bug is somewhere else or it has been blocked manually..."

The phased-updater, which sets the phased-update percentage, currently runs every 6 hours and does not consider how the long the package has been in -updates. I've submitted an MP fixing this now so that there will be an opportunity for more data to be collected. Thanks for discovering this!

Thanks for the info, that's good to know. And btw, is there a place to report or discuss about the phased-updater, like there is for Ubuntu packages ?

On Tue, Feb 09, 2021 at 09:19:15PM -0000, Olivier Robert wrote:
> Thanks for the info, that's good to know. And btw, is there a place to
> report or discuss about the phased-updater, like there is for Ubuntu
> packages ?

The phased-updater is a script which is part of ubuntu-archive-tools so
I guess the most appropriate thing would be to report a bug about that
project.

https://bugs.launchpad.net/ubuntu-archive-tools

--
Brian Murray

Zero reports of this crash in hirsute (which is version 3.38.4) so consider it fixed.