Candybar - Gnome shell crash on lock/disable

[ghost]

Candybar causes GNOME to crash when system goes into sleep mode.

[neuromorph]

Hello,

Please provide details of which Open Bar version you are using and the Gnome version. Any steps to reproduce? Were you in Overview or Fullscreen mode when system went to sleep? Can you reproduce it by simply locking the screen. Is your Bar on Top or Bottom position? Are using WindowMax Bar?

Previously we had faced a Gnome crash issue in fullscreen due to some upstream issue most likely in Mutter but it was fixed. It is important to know as much details as possible to properly investigate within Open Bar or upstream.

Thanks.

[ghost]

Version 29. My system is usually not on fullscreen mode when it goes to sleep. My bar is on the top posiiton, and windowmax is off. It can be reproduced by locking the screen.

[neuromorph]

OK, crash without fullscreen or overview is new, Also provide your Gnome version. I will try to recreate the scenario in VM later for the Gnome version you are using. While v29 has been tested earlier but will redo anyway.
BTW, it is unlikely to be related to Candy Bar since that only assigns the candy palette colors. But if you mean that it works OK when candybar is Off and only crashes when Candybar is On then please let me know.

Also, please try to disable all extensions and then enable only Open Bar to check if it is a conflict issue.

Thanks for reporting!

[ghost]

Yes, you are correct in that GNOME only crashes when candybar is off and I try to put my computer into sleep mode. I tried it with all other extensions disabled and the same thing happened. I'm using a laptop so you can imagine that this happens often, as laptops often go into sleep mode!

My Debian system is using GNOME 42.9.

Thank you for your help!

[neuromorph]

Yes, you are correct in that GNOME only crashes when candybar is off

Don't you mean when candybar is 'ON'?

I am also using Gnome 42.9 on my laptop with Ubuntu 22.04 LTS. But I am not able to reproduce this crash both with or without candybar. Basically, when laptop sleeps or when you lock screen, Gnome disables the extensions including Open Bar. Try to reproduce the issue just by disabling the Open Bar through an extension manager. If disabling works fine this way then the extension itself does not have an issue but there maybe some conflict occurring when locking (assume lock happens also on sleep).
One more thing you can do is try running in a nested shell to reproduce the issue and gather the messages/trace in the terminal. You will need to be on Wayland, then open a terminal and run following command. It will launch a new window with a new (nested) instance of the shell. It will throw a lot of messages in the terminal from all sorts of processes/extensions but that's normal. Then from the system menu in the nested shell click on Lock button to lock the screen of the nested shell. If the issue occurs, the nested shell window will crash but the terminal should show a log of what happened. Share that log here so we can check for clues. (You may want to send the log to a file). Command:

MUTTER_DEBUG_DUMMY_MODE_SPECS=1200x800 SHELL_DEBUG=all dbus-run-session -- gnome-shell --nested --wayland

Thanks.

[ghost]

(gnome-shell:26539): GLib-GObject-CRITICAL **: 10:43:23.804: g_signal_handler_disconnect: assertion 'handler_id > 0' failed
== Stack trace for context 0x5637a2bab170 ==
#-0 7ffc5bbb15a0 b resource:///org/gnome/gjs/modules/core/overrides/GObject.js:704 (236c637896f0 @ 25)
#-1 7ffc5bbb1690 b /home/lauren/.local/share/gnome-shell/extensions/blur-my-shell@aunetx/conveniences/settings.js:135 (410c0193880 @ 37)
#-2 7ffc5bbb1740 b /home/lauren/.local/share/gnome-shell/extensions/blur-my-shell@aunetx/conveniences/settings.js:179 (410c0193ab0 @ 57)
#-3 7ffc5bbb17b0 I self-hosted:164 (236c6378c330 @ 272)
#-4 7ffc5bbb1ea0 b /home/lauren/.local/share/gnome-shell/extensions/blur-my-shell@aunetx/conveniences/settings.js:177 (410c0193a60 @ 121)
#-5 7ffc5bbb24b0 I self-hosted:164 (236c6378c330 @ 272)
#-6 5637a4d7a2a8 i /home/lauren/.local/share/gnome-shell/extensions/blur-my-shell@aunetx/conveniences/settings.js:170 (410c0193a10 @ 29)
#-7 5637a4d7a218 i /home/lauren/.local/share/gnome-shell/extensions/blur-my-shell@aunetx/extension.js:141 (410c0187b00 @ 279)
#-8 7ffc5bbb3000 b resource:///org/gnome/shell/ui/extensionSystem.js:125 (1adf5716330 @ 386)
#-9 7ffc5bbb30c0 b resource:///org/gnome/shell/ui/extensionSystem.js:536 (1adf5716bf0 @ 15)
#-10 7ffc5bbb3130 I self-hosted:164 (236c6378c330 @ 272)
#-11 5637a4d7a190 i resource:///org/gnome/shell/ui/extensionSystem.js:536 (1adf5716ab0 @ 116)
#-12 5637a4d7a108 i resource:///org/gnome/shell/ui/extensionSystem.js:658 (1adf571a0b0 @ 17)
#-13 7ffc5bbb3be0 b self-hosted:1121 (236c6377eec0 @ 432)
#-14 7ffc5bbb3ce0 b resource:///org/gnome/gjs/modules/core/_signals.js:114 (236c637a0740 @ 433)
#-15 7ffc5bbb4420 b resource:///org/gnome/shell/ui/sessionMode.js:204 (32e12fe6ff60 @ 283)
#-16 5637a4d79fb0 i resource:///org/gnome/shell/ui/sessionMode.js:163 (32e12fe6fe20 @ 66)
#-17 5637a4d79f00 i resource:///org/gnome/shell/ui/screenShield.js:620 (32e12fe667e0 @ 206)
#-18 5637a4d79e40 i resource:///org/gnome/shell/ui/screenShield.js:666 (32e12fe66830 @ 342)
#-19 5637a4d79da8 i resource:///org/gnome/shell/misc/systemActions.js:416 (1adf57b1790 @ 87)
#-20 5637a4d79d28 i resource:///org/gnome/shell/ui/status/system.js:244 (d127847a3d0 @ 17)

(gnome-shell:26539): libmutter-WARNING **: 10:43:23.833: (../src/backends/meta-barrier.c:275):init_barrier_impl: runtime check failed: (priv->impl)
== Stack trace for context 0x5637a2bab170 ==
#-0 5637a4d79db8 i resource:///org/gnome/shell/ui/layout.js:563 (236c637cb6a0 @ 281)
#-1 5637a4d79d28 i resource:///org/gnome/shell/ui/layout.js:542 (236c637cb600 @ 22)
#-2 7ffc5bbb48a0 b self-hosted:1121 (236c6377eec0 @ 463)

(gnome-shell:26539): libmutter-WARNING **: 10:43:23.833: (../src/backends/meta-barrier.c:275):init_barrier_impl: runtime check failed: (priv->impl)
== Stack trace for context 0x5637a2bab170 ==
#-0 5637a4d79e40 i resource:///org/gnome/shell/ui/layout.js:1165 (236c637cc380 @ 615)
#-1 5637a4d79db8 i resource:///org/gnome/shell/ui/layout.js:547 (236c637cb650 @ 33)
#-2 7ffc5bbb3de0 I self-hosted:164 (236c6378c330 @ 272)
#-3 5637a4d79d28 i resource:///org/gnome/shell/ui/layout.js:545 (236c637cb600 @ 67)
#-4 7ffc5bbb48a0 b self-hosted:1121 (236c6377eec0 @ 463)

(gnome-shell:26539): libmutter-WARNING **: 10:43:23.833: (../src/backends/meta-barrier.c:275):init_barrier_impl: runtime check failed: (priv->impl)
== Stack trace for context 0x5637a2bab170 ==
#-0 5637a4d79e40 i resource:///org/gnome/shell/ui/layout.js:1170 (236c637cc380 @ 743)
#-1 5637a4d79db8 i resource:///org/gnome/shell/ui/layout.js:547 (236c637cb650 @ 33)
#-2 7ffc5bbb3de0 I self-hosted:164 (236c6378c330 @ 272)
#-3 5637a4d79d28 i resource:///org/gnome/shell/ui/layout.js:545 (236c637cb600 @ 67)
#-4 7ffc5bbb48a0 b self-hosted:1121 (236c6377eec0 @ 463)
== Stack trace for context 0x5637a2bab170 ==
lauren@debian:~$ A connection to the bus can't be made
gnome-shell-calendar-server[26604]: Lost (or failed to acquire) the name org.gnome.Shell.CalendarServer - exiting

(evolution-addressbook-factory:26673): libedbus-private-WARNING **: 10:43:23.872: Error setting property 'ConnectionStatus' on interface org.gnome.evolution.dataserver.Source: The connection is closed (g-io-error-quark, 18)
lauren@debian:~$

---

I just added the relevant parts that led to the crash. Hope that's okay!

And yes, I meant that whenever candybar is on, gnome crashes when it is locked. Sorry I misspoke! I don't mean to make things harder for you.

[neuromorph]

Hello,

Thank you for the log. I saw it but will need to try a few things.
Unfortunately, I had some disk issue and now I am on a fresh Ubuntu install on a new disk. Thus, my system is not setup yet and I am working on getting it back on track. I will look into this issue once my system is up.
If I somehow manage to reproduce the issue, it would be much easier to debug, if not, I may have to ask you to try a few more things. We will get it fixed as long as it's not an upstream (e.g. mutter) issue 🤞 . Maybe something is amiss in the disable.

Also, I saw you bought me coffees ☕ . Thanks a lot for your support! It is much appreciated 🙏
Wishing you best!

[neuromorph]

OK, in the beginning there is a Critical log about g_signal_handler. While it does not give trace pointing to OpenBar, I have made some update based on it. There is not much after that to indicate an issue.
To be sure, I tried in a new VM for Ubuntu 22.04 since that has Gnome 42 and installed Open Bar v29 afresh. However, I could not reproduce the crash/error. So it may be related to any customizations that you may have in your setup (e.g. additional widgets added to Bar or Menu). So I would suggest to first turn off other extensions when you try this update.

You will need to use the updated extension.js to try the update. You can get that by running the command given below in terminal. I would request to also collect journalctl log when you are testing with it and paste here to see the additional logging that I have added in OpenBar disable. For the log, you can run following command if using in host directly, OR you can use the earlier shared command if using the nested shell for testing.
SHELL_DEBUG=all journalctl /usr/bin/{gjs,gnome-shell} -fo cat

Command to get the update:
cd ~/.local/share/gnome-shell/extensions/openbar@neuromorph/; curl -LJO https://raw.githubusercontent.com/neuromorph/openbar/g42-44/patches/issue35_extension.js > extension.js; rm issue35_extension.js; cd

Let me know how it goes.

[ghost]

I think I found the problem.

I tried changing the palette colors, and discovered that when two colors are the same hex, that's when gnome crashes. However, when I make all the colors different, it's fine.

I don't remember what the default colors were, but if they were all different, then I must have made two colors the same somewhere along the line and forgot about it.

[neuromorph]

I don't remember what the default colors were, but if they were all different, then I must have made two colors the same somewhere along the line and forgot about it.

Yes, the default colors were all different for some candy effect. Though, it repeats when you have more than 8 buttons in the bar.

I tried changing the palette colors, and discovered that when two colors are the same hex, that's when gnome crashes.

That should not happen. No valid reason for it and also when candybar is off, all buttons have same hex color. However, Gnome/mutter may trip on anything like redrawing of shadow or change in size of bar as styles are removed on lock screen.

I forgot to mention in the last comment - you need to logout and log back in for any change in the extension code. So if you tried to update with that command, it will only take effect in new Gnome session (logout/login).

I would request you to provide feedback on following points:

1. Did you try the update (with logout/login)? You can test it with same or different candy colors (or both). Please collect the journalctl log and let me know here.
2. Keep all other extensions turned off, at least initially. If that works then you can try with other extensions On.
3. Instead of locking/sleep, please try to disable the extension from Extension Manager, does it cause same issue or not?
4. A pic of your bar/menus would help to quickly get idea on how many buttons, what colors, or oddities if any.

However, when I make all the colors different, it's fine.

Is this reproducible both ways? e.g. crash when same and not when different colors?

Thank you, hope to iron it out soon.

[StanSvec]

Hey @neuromorph, I experience the same issue on my laptop. The gnome session restarts after I open the lid (resume from sleep) . This happens only when the candybar is enabled. I'll answer the 4 questions soon. Just what do you mean by 1. Did you try the update ? Update what exactly? Thanks

Gnome version 46 (wayland)
Open bar version 30

[neuromorph]

Hello @StanSvec ,

experience the same issue on my laptop. The gnome session restarts after I open the lid (resume from sleep) . This happens only when the candybar is enabled.

That is weird and unfortunate. I would certainly like to fix this issue. I am not able to reproduce this issue even when I tried again today with Gnome 45/46. Some specific setup is probably causing it and I would need help to figure it out. If I can get the cause or be able to reproduce it then it will be possible to progress towards fixing it.

'll answer the 4 questions soon. Just what do you mean by 1. Did you try the update ? Update what exactly?

Thank you for deciding to help fixing it. I had prepared a small patch for extension.js for them to try, that is the update. It was for Gnome 42 though. It had some checks and logging in Disable to help find/fix the issue. BTW, when you lock or suspend the computer, Gnome disables all extensions and enables them back when you resume. My current assumption is that the issue occurs during the disable and thus I had also asked alq3f above to try disabling through Extension Manager to see if same issue happens.

I am currently almost ready with the new version of OpenBar with major updates. So I would request you to test with that to check if issue persists. I have added similar patch to that version as well. You will need to get it from GitHub branch 'openbar2.0' and install manually. Note: you would need to log out and log in again for the new changes to take effect.
It has more options for shell/apps etc but initially you can just try to set the bar as you have now and try to reproduce the issue. I would need to see the log of what happens when you lock/disable so for that you can do this - Quoting from a message above in this thread:

One more thing you can do is try running in a nested shell to reproduce the issue and gather the messages/trace in the terminal. You will need to be on Wayland, then open a terminal and run following command. It will launch a new window with a new (nested) instance of the shell. It will throw a lot of messages in the terminal from all sorts of processes/extensions but that's normal. Then from the system menu in the nested shell click on Lock button to lock the screen of the nested shell. If the issue occurs, the nested shell window will crash but the terminal should show a log of what happened. Share that log here so we can check for clues. (You may want to send the log to a file). Command:

MUTTER_DEBUG_DUMMY_MODE_SPECS=1200x800 SHELL_DEBUG=all dbus-run-session -- gnome-shell --nested --wayland

Thank you for writing!

[StanSvec]

Thanks for the suggestions @neuromorph. What is the procedure for trying the new version?

1. Uninstall the current one
2. Logout / in
3. Copy the 2.0 branch to a corresponding dir
4. Logout / in
5. See the logs somewhere

Something like this? Sorry, I'm not familiar with Gnome internals. Also, is it possible to somehow keep the current configuration?

Many thanks

[neuromorph]

Hello,

Also, is it possible to somehow keep the current configuration?

Your current configuration should stay except any changes from the new features that do not exist in the older version (see install procedure below). However, you can export the current settings to a file as backup. After installing new version, you can import this settings file, if needed.

What is the procedure for trying the new version?

No need to uninstall. Just git clone or download the zip for the 'openbar2.0' branch. Then extract, if zipped, and copy the the extensions directory to overwrite the existing one. The directory should be named as openbar@neuromorph. The path to the install location is: ~/.local/share/gnome-shell/extensions/.
Yes, you need to logout and login after manual install for the new version to take effect.

If you face the crash issue in new version as well then you can use the nested shell method and command described in previous post to capture the log.

Let me know how it goes.
Thank you!

[StanSvec]

Hi,

Thanks for the instructions. I've installed the version from the openbar2.0 branch, but the problem persists.
When this command is executed in terminal:
MUTTER_DEBUG_DUMMY_MODE_SPECS=1200x800 SHELL_DEBUG=all dbus-run-session -- gnome-shell --nested --wayland
it terminates with this error:

MUTTER_DEBUG_DUMMY_MODE_SPECS=1200x800 SHELL_DEBUG=all dbus-run-session -- gnome-shell --nested --wayland
dbus-daemon[21703]: [session uid=1000 pid=21703] Activating service name='org.gtk.vfs.Daemon' requested by ':1.0' (uid=1000 pid=21705 comm="gnome-shell --nested --wayland")
dbus-daemon[21703]: [session uid=1000 pid=21703] Successfully activated service 'org.gtk.vfs.Daemon'
fusermount3: failed to access mountpoint /run/user/1000/gvfs: Permission denied
libmutter-Message: 00:14:04.714: Running GNOME Shell (using mutter 46.2) as a Wayland display server
Invalid MIT-MAGIC-COOKIE-1 key
Failed to setup: Unable to open display ':1'
A connection to the bus can't be made

Any idea what can be wrong?

[neuromorph]

Hello,

I've installed the version from the openbar2.0 branch, but the problem persists.

Well, we need to find the root cause then. What exactly is causing the crash. I can't think of anything special for Candybar.
We'll need to get the logs.

Any idea what can be wrong?

That is an unrelated issue. You are unable to start the display for the nested shell.
It says Unable to open display ':1'. You can check with echo $DISPLAY for the index 0 or 1. Try exporting DISPLAY 0 or 1. Check here for some guidance - https://unix.stackexchange.com/questions/199891/invalid-mit-magic-cookie-1-key-when-trying-to-run-program-remotely
Below link goes into details of MIT Magic Cookie , if you are interested:
https://linux-blog.anracom.com/tag/invalid-mit-magic-cookie-1/

Other way of going about it would be to dig into logs after the crash. Which OS are you on? Usually, there will be logs at /var/crash and /var/log . There is also a GUI app called logs (at least in Ubuntu) that can be used to check for logs.
You will need to get the log for when the crash happened (note the timestamp).

journalctl also helps to get the logs, I will check for more specific command as well.

Hope this helps.

[neuromorph]

Hello @StanSvec and @alq3f ,

I have good news and better news.
I have been using Candybar for the past couple days and finally faced the Crash issue today, so good news, I guess? :)
I looked through the stack trace and found what looked like an upstream issue I had come across earlier too. After searching I found it. From the trace it is most likely due to an issue in Gnome shell - relevant bugs here and here.
It seems that, the memory is freed after stylesheet is unloaded but the st_theme_node keeps pointing to it causing a SEGFAULT. The good news is that there is already a merge request here which seems to fix the issue and is ready to merge. When this is merged and available in Gnome update, most likely this issue should get resolved.

Meanwhile, I also tried to do a workaround to avoid the issue from Open Bar and it seems to be holding up. I am not getting the crash now, but it may not be full-proof. While at it, I also fixed some highlight inconsistencies for Candybar and added support to auto-style when some indicators become visible/invisible (e.g. Accessibility).

Please get the latest commit from 'openbar2.0' branch and try it out and let me know.
Also do update your system when upstream Gnome fix is available.

[neuromorph]

One more thing, even with the workaround, the issue seems to happen more with the 'Accessibility' indicator in the panel and not really when the indicator is not there. Not sure why that should happen but you may want to try it out.

[StanSvec]

Hello @neuromorph , I updated the code from the branch (last commit yesterday 16th), but the issue is not fixed by that even after I removed the Accessibility icon. I'll wait for the Gnome fixes to see if they have any effect then.

[neuromorph]

I updated the code from the branch (last commit yesterday 16th), but the issue is not fixed by that even after I removed the Accessibility icon. I'll wait for the Gnome fixes to see if they have any effect then.

Thank you for reporting!
The root cause is certainly the upstream bug in Gnome and about how they unload and load stylesheets for the extensions. So the real fix will come from there.

Meanwhile I will try if there is a way to dodge the issue. Also, I think it is not about the Accessibility icon (that wouldn't have made much sense) but I might have faced it since adding the icon increased the number of buttons beyond 8. There are 8 candybar color options currently supported after which it repeats. Event the repeat shouldn't cause any problem at all but some quirkiness of CSS is triggering the main issue in Gnome and I am wondering if that trigger could be avoided.

Can you also please try with 8 or less buttons in the panel (disable some extensions/apps) and then see if the crash happens or not.
Let me know how that goes. I will try to increase the limit if that works.

Thank you.

[neuromorph]

Quick Update:

• I have merged OpenBar 2.0 into 'main' branch so all new updates will be there.
• The main issue for Candy crash saga will only be fixed from upstream Gnome. However I have increased the color limit from 8 to 16 (in 'main' branch), so feel free to test with that if it helps.
• I had uploaded the extension to Gnome a few days ago and it just got published, in case you see an update. However, since it is from a few days ago, it does not have latest commits, so I suggest to get that from 'main' branch in GitHub.

Thanks!

[StanSvec]

Thanks for the new info @neuromorph. I can see the 16 colours palette in the update, but it doesn't fix the crashing after resume. There are 9 different colours in my panel.

[neuromorph]

@StanSvec Thank you for the update. In my test it wouldn't crash on <=8 buttons in panel so I decided to increase the palette but I didn't know how's it would affect. If nothing else it gives additional color options instead of repeating.

While there is the upstream bug, I still can't figure out why it affects candybar but not otherwise. There is another update coming soon where the loading and unloading of stylesheet is altered to accommodate NixOS like immutable distros. That might help here too but would need testing.

About the upstream merge request, I had added a comment there. We need to compile Gnome shell from source in order to test that fix which I haven't got chance to try yet. On the other hand, they said it will likely be included in Ubuntu 24.04 next month which makes it easier to test and hopefully will become part of Gnome update.

[StanSvec]

Hi @neuromorph , I appreciate your effort to have this issue fixed! Fingers crossed the fix will land soon.

[neuromorph]

There is another update coming soon where the loading and unloading of stylesheet is altered to accommodate NixOS like immutable distros. That might help here too but would need testing.

This has been merged into main branch. I would suggest you can pull / download latest code from main and try with it. I enabled random extensions to get 10 different colored buttons in the panel. It did not crash in my test but then again my setup hasn't been consistent on reproducing it, sometimes it does some times not. With latest update it hasn't yet.

And yes, hoping for the upstream fix soon 👍

[coyotle]

I have the same issue. Is this fix already released or do I need to use the main branch to fix the problem?

[neuromorph]

Hello @coyotle ,
With latest update (v37), the released version is up to date with main branch.
As discussed in the thread, the core issue seems to be upstream in Gnome where a node may point to freed memory upon stylesheet unload and the merge request for the fix seems still open. However, there should be some scenarios that trigger it since it doesn't happen on every reload of stylesheet. To that end I was trying out some fixes but not really sure how reliable that might be but already included in v37.

• Are you on Gnome 46, Open Bar v37?
• Can you please share a screenshot of your bar to get idea on your config and the items in the panel
• If possible, can you please share the stack trace of the crash so we can verify it is the same as the upstream issue

Thank you for reporting!

[coyotle]

@neuromorph sorry for late reply.
openbar Version 38
gnome 46

openbar-settings.txt

I'm not sure how to get stack trace. Here is a journalctl -xe /usr/bin/gnome-shell log
gnome-shell.zip

[neuromorph]

Thanks!
However, can you please turn off Dash-to-dock. Reboot and reproduce the Open Bar crash. Then collect the journalctl log for the previous/crashed session.

This is since there is a bug in the latest Dash-to-dock due to which your log is mostly flooded with only errors from it and is way too big as well. I also switched to Ubuntu dock today when I noticed the issue with Dash-to-dock, hope they'll fix it soon.

While you are at it, can you please get the latest Open Bar from the main branch, now it has more updates compared to v38.

Thank you for getting back!

[coyotle]

ok, I installed OpenBar from the main branch and disabled Dash-to-Dock, but the result is the same, gnome shell is crashing.

gnome-shell.log

[BigBoyBarney]

Same here, just updated to Fedora 41 / Gnome 47, installed OpenBar for the first time from https://extensions.gnome.org/extension/6580/open-bar/, and gnome shell crashes when I lock the screen. Unlike the previous issue, I do not have CandyBar turned on.

Here are the gnome-shell logs from a "login → attempt to lock screen → crash → login" cycle.

Thanks for looking into it!

shell.log

openbar_settings.txt

EDIT:

Adding the following to metadata.json fixes the crashing. I suppose it couldn't close cleanly when switching from user to the lock screen.

"session-modes": ["user", "unlock-dialog"],