[Bug] Privacy and Online Account crash

[littlelevi]

Description

"Privacy" and "Online Accounts" panels in "Budgie Control Center"
get crashed when the language is different than English.

Budgie version

10.8.2

Operating System

FreeBSD 14.0-RELEASE-p3

Steps to reproduce the issue

1. Open "Budgie Control Center"
2. Go to "Region & Langauge" panel and select "Polish" language.
3. Logout - as panel suggest
4. Login again
5. Open "Budgie Control Center" again
6. Check "Privacy" and "Online Accounts" panels

Actual result

Panel crashes, sometimes it's impossible to launch "Budgie Control Center" it keeps crashing right after it open. Sometimes opens and opens in white theme (previously was set to dark). Changing the theme doesn't work.

Expected result

Possibility to open "Privacy" and "Online Accounts" panels (in any language) in "Budgie Control Center" without crashing

Additional information

No response

[fossfreedom]

'fraid I can't reproduce this issue on Ubuntu Budgie

Polish version of BCC starts just fine here - privacy and online tabs are ok - they show on a restart

LANGUAGE=pl_PL LANG=pl_PL.UTF-8 budgie-control-center

[littlelevi]

Ok, here something even simpler. Because previous issues may have been direct results from a corrupted configuration file.

I don't know where Budgie stores its config files. I'm testing this on a test user account, so for the sake of simplicity I'm just deleting everything in the home directory. So every time we have a fresh start.

After Budgie is launched, I go straight to "Budgie Control Center"
I'm clicking on "Sharing", "Budgie Control Center" crashes. After it crashes, I'm no longer able to run "Budgie Control Center" again. I delete everything in the home directory again, now "Budgie Control Center" runs again. When deleting all directories, I don't log out of Budgie. It is still one and the same session.

budgie-control-cent.core file inspection

(lldb) thread backtrace all
* thread #1, name = 'budgie-control-cent', stop reason = signal SIGSEGV
  * frame #0: 0x000000000043a531
    frame #1: 0x00002a289a666eb0

  thread #2, name = 'pool-spawner', stop reason = signal SIGSEGV
    frame #0: 0x000000083b34cd2c
    frame #1: 0x000000083b35cd72
  thread #3, name = 'gmain', stop reason = signal SIGSEGV
    frame #0: 0x000000083b9e3c2a
    frame #1: 0x000000083b35b691
  thread #4, name = 'gdbus', stop reason = signal SIGSEGV
    frame #0: 0x000000083b9e3c2a
    frame #1: 0x000000083b35b691
  thread #5, name = 'pool', stop reason = signal SIGSEGV
    frame #0: 0x000000083b34cd2c
    frame #1: 0x000000083b35cd72
  thread #6, name = 'dconf worker', stop reason = signal SIGSEGV
    frame #0: 0x000000083b9e3c2a
    frame #1: 0x000000083b35b691

[littlelevi]

It sounds too simple and too obvious to be a common bug. Maybe it was built using the wrong libraries versions ? Here is the port, at the bottom of the page there are all run and build dependencies for budgie-control-center. Possibly there is something suspicious about them.

https://www.freshports.org/sysutils/budgie-control-center/

[fossfreedom]

I can't really comment about bsd libraries and versioning. I can though point you to what build dependencies Debian uses

https://github.com/UbuntuBudgie/budgie-control-center/blob/debian/debian/control

Your core trace is interesting. It appears to be seg faulting on dconf ... which is the gsettings stuff from gnome.

So removing all folders would be deleting the userspace dconf file.

The reason why BCC will not open again on a crash for a particular panel is because BCC will open on the last panel that was open. That is stored in gsettings/dconf

Since you are running BSD I don't think you have access to journalctl logs. Maybe looking in /var/log/messages would be useful around the time of a crash.

Also if you can install your debug symbols for BCC would give more information where in BCC it is crashing.

[littlelevi]

I can't really comment about bsd libraries and versioning. I can though point you to what build dependencies Debian uses

Most of the time it is the same set of libraries. The main reasons why things may differ are Linuxisms. A heavy reliance on Linux infrastructure such as hard-coded systemd, udev, the Linux sound system, etc. And these are mainly low-level libraries that need to provide a glue interface.

If application/library is well written honoring other system and POSIX standards, then is portable and most of the time is the same build setup as on Linux. I don't think this is the case of Budgie.

Your core trace is interesting. It appears to be seg faulting on dconf ... which is the gsettings stuff from gnome.

That was my first guess, too, before I even did a core trace. The entry to the dconf configuration file is broken and the file itself is also broken. This is my point from where I start my search. Starting with the library that does it.

Since you are running BSD I don't think you have access to journalctl logs. Maybe looking in /var/log/messages would be useful around the time of a crash.

I don't think there's anything interesting about it.

cat /var/log/messages
pid 1777 (budgie-control-cent), jid 0, uid 1001: exited on signal 11 (core dumped)

Just good old SIGSEGV

Also if you can install your debug symbols for BCC would give more information where in BCC it is crashing.

It may still be helpful too. I run BCC from terminal.

budgie-control-center

(process:1794): Gtk-CRITICAL **: 13:20:18.130: gtk_style_context_add_provider_for_screen: assertion 'GDK_IS_SCREEN (screen)' failed

(budgie-control-center:1794): Gtk-CRITICAL **: 13:20:35.576: Error building template class 'CcSharingPanel' for an instance of type 'CcSharingPanel': .:3:2369 Invalid object type 'CcListRow'

(budgie-control-center:1794): GLib-GObject-CRITICAL **: 13:20:35.576: invalid (NULL) pointer instance

(budgie-control-center:1794): GLib-GObject-CRITICAL **: 13:20:35.576: g_signal_connect_object: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed

(budgie-control-center:1794): GLib-GObject-CRITICAL **: 13:20:35.576: invalid (NULL) pointer instance

(budgie-control-center:1794): GLib-GObject-CRITICAL **: 13:20:35.576: g_signal_connect_data: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed

(budgie-control-center:1794): GLib-GObject-CRITICAL **: 13:20:35.576: invalid (NULL) pointer instance

(budgie-control-center:1794): GLib-GObject-CRITICAL **: 13:20:35.576: g_signal_connect_data: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed

(budgie-control-center:1794): GLib-GObject-CRITICAL **: 13:20:35.576: invalid (NULL) pointer instance

(budgie-control-center:1794): GLib-GObject-CRITICAL **: 13:20:35.576: g_signal_connect_data: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed

(budgie-control-center:1794): GLib-GObject-CRITICAL **: 13:20:35.576: invalid (NULL) pointer instance

(budgie-control-center:1794): GLib-GObject-CRITICAL **: 13:20:35.576: g_signal_connect_data: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed

(budgie-control-center:1794): Gtk-CRITICAL **: 13:20:35.576: gtk_list_box_set_activate_on_single_click: assertion 'GTK_IS_LIST_BOX (box)' failed

(budgie-control-center:1794): Gtk-CRITICAL **: 13:20:35.576: gtk_list_box_set_header_func: assertion 'GTK_IS_LIST_BOX (box)' failed

(budgie-control-center:1794): Gtk-CRITICAL **: 13:20:35.576: gtk_widget_set_sensitive: assertion 'GTK_IS_WIDGET (widget)' failed

(budgie-control-center:1794): Gtk-CRITICAL **: 13:20:35.577: gtk_widget_grab_focus: assertion 'GTK_IS_WIDGET (widget)' failed

(budgie-control-center:1794): Gtk-CRITICAL **: 13:20:35.586: gtk_widget_hide: assertion 'GTK_IS_WIDGET (widget)' failed

(budgie-control-center:1794): Gtk-CRITICAL **: 13:20:35.586: gtk_widget_hide: assertion 'GTK_IS_WIDGET (widget)' failed

(budgie-control-center:1794): GLib-GObject-CRITICAL **: 13:20:35.586: g_object_bind_property_full: assertion 'G_IS_OBJECT (source)' failed

(budgie-control-center:1794): GLib-GObject-CRITICAL **: 13:20:35.586: invalid (NULL) pointer instance

(budgie-control-center:1794): GLib-GObject-CRITICAL **: 13:20:35.586: g_signal_connect_data: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed

(budgie-control-center:1794): GLib-GObject-CRITICAL **: 13:20:35.586: invalid (NULL) pointer instance

(budgie-control-center:1794): GLib-GObject-CRITICAL **: 13:20:35.586: g_signal_connect_data: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed

(budgie-control-center:1794): GLib-GObject-CRITICAL **: 13:20:35.586: invalid (NULL) pointer instance

(budgie-control-center:1794): GLib-GObject-CRITICAL **: 13:20:35.586: g_signal_connect_object: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed

(budgie-control-center:1794): Gtk-CRITICAL **: 13:20:35.586: gtk_widget_set_sensitive: assertion 'GTK_IS_WIDGET (widget)' failed

(budgie-control-center:1794): Gtk-CRITICAL **: 13:20:35.586: gtk_widget_set_sensitive: assertion 'GTK_IS_WIDGET (widget)' failed

(budgie-control-center:1794): Gtk-CRITICAL **: 13:20:35.586: gtk_widget_hide: assertion 'GTK_IS_WIDGET (widget)' failed
zsh: segmentation fault (core dumped)  budgie-control-center

The Funny thing is, when cycling through different panels, I was able to finally access "Sharing" panel. And this most likely means one thing, a rouge pointer situation. I hope this sheds some more light. This also explains why earlier crashes occurred on Privacy and Account panels. Maybe this is related to stack panel ?

The reason why BCC will not open again on a crash for a particular panel is because BCC will open on the last panel that was open.

This may play a key role. If this does not guide us to find the bug. That leaves me no other choice but to play with dbg symbols.

One more important thing. FreeBSD by default uses clang compiler, not gnu GCC. I know from experience that code generated with clang and GCC treats (UB's) undefined behaviors differently. Please try out clang compiler, it might help to catch more potential bugs.

[fossfreedom]

Please try out clang compiler, it might help to catch more potential bugs.

I tried to compile with clang-17 - compilation fails. So what version of clang is your distro using? If you are using 17 - are you using any patches that haven't been upstreamed here?

[littlelevi]

Oh, that was unexpected...
I expected instability rather than compilation errors...
Here is my clang version:

clang -v
FreeBSD clang version 16.0.6 (https://github.com/llvm/llvm-project.git llvmorg-16.0.6-0-g7cbf1a259152)
Target: x86_64-unknown-freebsd14.0
Thread model: posix
InstalledDir: /usr/bin

are you using any patches that haven't been upstreamed here?

Basically, I'm using the Meta Port:
https://www.freshports.org/x11/budgie/
I understand that the compilation error applies only to BCC and not to the whole Budgie or other Budgie modules.
Then: https://www.freshports.org/sysutils/budgie-control-center/

Seems like there are some minor tweaks to the BCC:
https://cgit.freebsd.org/ports/commit/sysutils/budgie-control-center?id=53f3134b74bb18b06b6f2d25dbf2fadfbda004df

And the Makefile with all the flags is here:
https://cgit.freebsd.org/ports/tree/sysutils/budgie-control-center/Makefile?id=53f3134b74bb18b06b6f2d25dbf2fadfbda004df