gnome-shell crashes after update

[raphaelrochet]

gnome-shell crashes after update

[3v1n0]

I did that patch, so I know it... However it might be caused more from gjs or new mozjs causing the elements to be destroyed differently, however what you should not do here is to touch an element that has been destroyed, and thus just avoid to interact with it when that has happened.

[3v1n0]

@ronjouch having an updated JS crash dump would help too, please follow these instructions

[3v1n0]

Anyway look at the last part of the wiki...

sudo gdb -p $(pgrep -U $USER -x gnome-shell) -batch \
  -ex "set logging on" -ex continue \
  -ex "bt full" -ex "call gjs_dumpstack()" \
  -ex quit

[RaphaelRochet]

Why do you think this extension is responsible for the crash ?

[securitym0nkey]

Once i uninstalled the extension the next update has not triggered a crash. Reinstalled it and it was crashing again. I know that's not much input for debugging.

[hedgepigdaniel]

In case its useful, this line of code in Freon triggers the same crash: https://github.com/UshakovVasilii/gnome-shell-extension-freon/blob/f9756b2430b3766c3d21d71e9928963032617bf7/freon%40UshakovVasilii_Github.yahoo.com/extension.js#L360

[RaphaelRochet]

This is weird. The journactl log mention st_label_set_text too, but how changing the label could lead to a crash, and (more important) how to fix this ...

[phw]

This seems to be the corresponding upstream bug: https://bugzilla.gnome.org/show_bug.cgi?id=788931

[RaphaelRochet]

Thanks for pointing this. I'm still clueless about how to fix this !

[3v1n0]

In order to debug this properly, please follow this instructions in order to get a proper JS stacktrace that could help to debug this issue.

Thanks.

[3v1n0]

Ok, the issue is caused by this:

nov 16 19:04:44 Arch-Lenovo org.gnome.Shell.desktop[16162]: == Stack trace for context 0x55759502d000 ==
nov 16 19:04:44 Arch-Lenovo org.gnome.Shell.desktop[16162]: #0 0x5575953b3ac0 i   /home/stalker/.local/share/gnome-shell/extensions/arch-update@RaphaelRochet/extension.js:303 (0x7fe8fd256098 @ 581)
nov 16 19:04:44 Arch-Lenovo org.gnome.Shell.desktop[16162]: #1 0x7ffe47181cb0 I   resource:///org/gnome/gjs/modules/_legacy.js:82 (0x7fe9386c2c48 @ 71)
nov 16 19:04:44 Arch-Lenovo org.gnome.Shell.desktop[16162]: #2 0x5575953b3a38 i   /home/stalker/.local/share/gnome-shell/extensions/arch-update@RaphaelRochet/extension.js:402 (0x7fe8fd2564d8 @ 126)
nov 16 19:04:44 Arch-Lenovo org.gnome.Shell.desktop[16162]: #3 0x7ffe471828b0 I   resource:///org/gnome/gjs/modules/_legacy.js:82 (0x7fe9386c2c48 @ 71)
nov 16 19:04:44 Arch-Lenovo org.gnome.Shell.desktop[16162]: #4 0x5575953b3990 i   /home/stalker/.local/share/gnome-shell/extensions/arch-update@RaphaelRochet/extension.js:390 (0x7fe8fd2563c8 @ 285)
nov 16 19:04:44 Arch-Lenovo org.gnome.Shell.desktop[16162]: #5 0x7ffe471834b0 I   resource:///org/gnome/gjs/modules/_legacy.js:82 (0x7fe9386c2c48 @ 71)
nov 16 19:04:44 Arch-Lenovo org.gnome.Shell.desktop[16162]: #6 0x5575953b3910 i   /home/stalker/.local/share/gnome-shell/extensions/arch-update@RaphaelRochet/extension.js:357 (0x7fe8fd2562b8 @ 17)
nov 16 19:04:44 Arch-Lenovo org.gnome.Shell.desktop[16162]: #7 0x7ffe471840b0 I   self-hosted:917 (0x7fe9386ee4d8 @ 394)

As you can see the problem is setting the text here https://github.com/RaphaelRochet/arch-update/blob/v24/extension.js#L303, I guess because the _updateProcess_sourceId is not removed when the label actor is destroyed.

[chrisnew]

Thanks for digging so deep. I’ve got the same gnome-shell crash issues now for weeks and today I had two crashes while running updates. I disabled arch-update extension after the last two crashes and seeing your comments in this issue. Let‘s see… 🤞

[RaphaelRochet]

You mean the label actor is destroyed sometimes ? How should I deal with that :-/

[chrisnew]

Right now I got no idea, but in my opinion it’s clearly a upstream bug… 😢

Something has changed in gnome-shell which breaks existing extensions like yours and itself in a bad way. It also seems to be breaking some parts of gnome as well: https://bugzilla.gnome.org/show_bug.cgi?id=788931#c37 🤕

[RaphaelRochet]

I made a little fix. Could you try the lastest commit ? (e9c08b6)

[3v1n0]

@RaphaelRochet

You mean the label actor is destroyed sometimes ? How should I deal with that :-/

Yeah... I saw your commit above but I don't think it would change much the things...
What I'd do instead is making sure that archupdateindicator.destroy() (or cancelling this._updateProcess_sourceId, as you wish) is also called when this.actor is destroyed... So just connect to its destroy signals to it.

[RaphaelRochet]

Sorry, I don't get why the hell I should destroy my whole object (and/or lose info about running operation) when that stupid label actor is destroyed for whatever reason !
If that's the label that misbehave, maybe the fix can work.

[3v1n0]

I'm pretty sure it's the whole parent actor that gets destroyed in some cases when g-s things the extension needs to, for whatever reason... So you need to protect from this, and any async operation should not acting on invalid data.

FYI, here's how I fixed a similar issue: https://github.com/jderose9/dash-to-panel/pull/263/files

[ronjouch]

"I made a little fix. Could you try the lastest commit ? (e9c08b6)"

@RaphaelRochet e9c08b6 doesn't help on my machine, I still occasionally get the same crash:

#0  0x00007f735a44ea0d g_type_check_instance_cast (libgobject-2.0.so.0)
#1  0x00007f735816e960 st_label_set_text (libst-1.0.so)
#2  0x00007f73548841c8 ffi_call_unix64 (libffi.so.6)
#3  0x00007f7354883c2a ffi_call (libffi.so.6)
#4  0x00007f73590f5cbb n/a (libgjs.so.0)
#5  0x00007f73590f7617 n/a (libgjs.so.0)
#6  0x00007f7351864b8d n/a (libmozjs-52.so.0)
...

[ronjouch]

Still crashes here on an up-to-date Arch. Marco Trevisan (GNOME dev who commented on GNOME bug 788931 comment 69 hints at two PR for other extensions fixing problem: home-sweet-gnome/dash-to-panel#263 , gnome-pomodoro/gnome-pomodoro#321 , which both involve calling disconnect().

@RaphaelRochet for arch-update, looking at e9c08b6 I don't see any attempt to do something similar, is there a reason for it? Could attempting something along the same lines work for us?

[ronjouch]

"having an updated JS crash dump would help too, please follow these instructions"

@3v1n0 doing so. One nit:

 ~ ps aux | grep gnome-shell | grep -v grep
gdm      27089  0.3  0.1 1745412 28404  tty1   Sl+  10:05   0:00 /usr/bin/gnome-shell
ronj     27104 41.1  1.3 3647524 216260 tty2   Sl+  10:05   0:05 /usr/bin/gnome-shell

Which one should I attach to? Looks like the active one is the second (see third column, CPU), but attaching to it with gdb $(which gnome-shell) 27104 results in an instant freeze (mouse still reactive, but clicks/keyboard don't do anything and I have to restart Shell from another tty). Will attaching to the first gdm-owned one work, or is it pointless?

---

EDIT Okay, saw the new fix attempt, trying it. Thanks @3v1n0 @RaphaelRochet 🙂.

[ronjouch]

Sorry, after pulling 9d9aa8b / #90 and restarting Shell, the problem persists: Shell freezes and restarts after an upgrade.

@3v1n0 "look at the last part of the wiki..." yeah indeed, I wasn't looking at the right section, thanks for the pointer. Running it right now, will chime back here at the next crash.

@RaphaelRochet can you re-open the issue?

[3v1n0]

@ronjouch Ok, good to know... Do you have a JS stacktrace again?

To be fair, these crashes won't happen anymore with this gjs change (and this for stable version), but they'll still show errors.

[ronjouch]

@3v1n0 @RaphaelRochet just got a stack trace. Here it is below, plus I manually matched arch-update lines with an // ... annotation below to the actual code; hope that helps.

Dec 22 22:13:01 t org.gnome.Shell.desktop[14403]: == Stack trace for context 0x5614cb32c170 ==
Dec 22 22:13:01 t org.gnome.Shell.desktop[14403]: #0 0x5614cb89ae90 i   /home/ronj/.local/share/gnome-shell/extensions/arch-update@RaphaelRochet/extension.js:322 (0x7f98fa4304d8 @ 551)
// _updateStatus :: this.updatesListMenuLabel.set_text("");
Dec 22 22:13:01 t org.gnome.Shell.desktop[14403]: #1 0x7ffdd9596200 I   resource:///org/gnome/gjs/modules/_legacy.js:82 (0x7f99186c2bc0 @ 71)
Dec 22 22:13:01 t org.gnome.Shell.desktop[14403]: #2 0x5614cb89ae08 i   /home/ronj/.local/share/gnome-shell/extensions/arch-update@RaphaelRochet/extension.js:422 (0x7f98fa430918 @ 126)
// _checkUpdatesEnd :: this._updateStatus(this._updateList.length);
Dec 22 22:13:01 t org.gnome.Shell.desktop[14403]: #3 0x7ffdd9596e40 I   resource:///org/gnome/gjs/modules/_legacy.js:82 (0x7f99186c2bc0 @ 71)
Dec 22 22:13:01 t org.gnome.Shell.desktop[14403]: #4 0x5614cb89ad60 i   /home/ronj/.local/share/gnome-shell/extensions/arch-update@RaphaelRochet/extension.js:410 (0x7f98fa430808 @ 285)
// _checkUpdatesRead :: this._checkUpdatesEnd();
Dec 22 22:13:01 t org.gnome.Shell.desktop[14403]: #5 0x7ffdd9597a80 I   resource:///org/gnome/gjs/modules/_legacy.js:82 (0x7f99186c2bc0 @ 71)
Dec 22 22:13:01 t org.gnome.Shell.desktop[14403]: #6 0x5614cb89ace0 i   /home/ronj/.local/share/gnome-shell/extensions/arch-update@RaphaelRochet/extension.js:377 (0x7f98fa4306f8 @ 17)
// _checkUpdates :: this._updateProcess_sourceId = GLib.child_watch_add(0, pid, Lang.bind(this, function() {this._checkUpdatesRead()}));
Dec 22 22:13:01 t org.gnome.Shell.desktop[14403]: #7 0x7ffdd9598810 b   self-hosted:917 (0x7f99186ee5e8 @ 394)

To be fair, these crashes won't happen anymore with this gjs change (and this for stable version), but they'll still show errors.

👍👍👍, awesome.

[3v1n0]

Mh, try to add also this.menu.connect('destroy', Lang.bind(this, this._onDestroy));

Or it might happen that the label is destroyed when the menu is closed otherwise...

[ronjouch]

Mh, try to add also this.menu.connect('destroy', Lang.bind(this, this._onDestroy));

Or it might happen that the label is destroyed when the menu is closed otherwise...

@3v1n0 tried it (inside extension.js _init, right?) and restarted Shell, didn't help: same crashes.

[shihjay2]

Updated gjs to 1.51.4 (which has the updates @3v1n0 mentioned) hoping that using arch-update would not cause the crash but it still reports the same g_type_check_instance_cast and st_label_set_text errors as the OP reports. It's not just a logging error, gnome-shell closes and restarts again when the crash occurs.

[RaphaelRochet]

I may have found the deep cause of that bug. I were indeed trying to update a no-more-existing instance of the indicator from the directory monitor, as I wasn't canceling that monitor on destroy (yep, as simple as that ...).
I hope it's fixed since 07ce51d.

[ronjouch]

I may have found the deep cause of that bug. I were indeed trying to update a no-more-existing instance of the indicator from the directory monitor, as I wasn't canceling that monitor on destroy (yep, as simple as that ...). I hope it's fixed since 07ce51d.

@RaphaelRochet 👍. Updated to that, testing it, will barf here if the problem persists. Thanks!!! 🙂 (And hopfully Shell 3.26.3 will land someday and make the root problem a mere warning rather than a restart.)

EDIT: no crash in a whole day, looks solved!