Starting indicator-multiload (with peculiar config) crashes gnome-shell

[max ulidtko]

## Steps to reproduce ##

1. On bionic, apt install -y indicator-multiload dconf-editor
2. dconf load /de/mh21/indicator-multiload/ < crasher.dconf-dump
3. Run indicator-multiload

## Actual result ##

Whole desktop crashes.

gnome-shell dies with SIGABRT, logging this assertion failure: https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1787512

## Expected result ##

An applet appears, showing CPU/RAM load graphs.

If not that -- an error is reported.

If not that -- gnome-shell continues to work, rather than crashing and destroying everything unsaved I've been working on.

The desktop should not crash because of one shitty program. Especially so if that program has put itself into ~/.config/autostart -- effectively rendering the OS dead to a simpleton user.

lsb_release -d: Ubuntu 18.04.3 LTS
gnome-shell version: 3.28.4-0ubuntu18.04.1
indicator-multiload version: 0.4-0ubuntu5

[max ulidtko (ulidtko)]

The repro steps aren't as exact as I'd like, since I found this on a live machine with long history of rough usage (including wiping /var by accident, and restoring from there), so the steps are a bit difficult to isolate.

I'll try refining the steps as needed in a VM.

[max ulidtko (ulidtko)]

Also, I'd like to see feedback from @vanvugt (as he has triaged a lot of gnome-shell crash reports), and Michael Hofmann <email address hidden> as the original maintainer of indicator-multiload.

[max ulidtko (ulidtko)]

Repro steps have been verified in clean VM and now refined to include the crasher.

[max ulidtko (ulidtko)]

Please NOTE: the report is against gnome-shell, NOT indicator-multiload!

It's not so important to fix the indicator app. Rather, gnome-shell needs to become sturdier.

There's a change to be made to gnome-shell so that it perseveres assertion failures and keeps running.

Lurking around, I've seen plentiful variations of gnome-shell assertion-crashing posted, with varying backtraces. I've also personally witnessed, on multiple occasions, "Ubuntu dying" as they say, with very similar symptoms and the exact same workaround, mv ~/.config{,.bugz}.

Mind that, in each of that crash story, reported and not, we've caused suffering and disappointment in hundreds of people. The data is there at errors.ubuntu.com waiting for you to check out.

Now that I've spent a day unearthing a concrete working reproducer, can I expect a *PROPER FIX* for this disaster, not just a measly patch-over as dozens of bugs before?

[Daniel van Vugt (vanvugt)]

Isn't this a duplicate of bug 1787512?

If not then please follow these steps:
https://wiki.ubuntu.com/Bugs/Responses#Missing_a_crash_report_or_having_a_.crash_attachment

[max ulidtko (ulidtko)]

Daniel, yes, this is the same crash as in bug 1787512.

It's not a duplicate IMO, since I'd researched the exact repro steps. Any developer can trigger the crash now, by following the repro steps.

That's why I didn't use ubuntu-bug either; just follow the repro steps and trigger the crash yourself, rather than blankly staring at my recording of it.