GNOME Bugzilla – Bug 790692
Crashing on startup when calling SettingsBackend.get_default ()
Last modified: 2017-12-15 04:30:43 UTC
When I try to run the app it crashes silently before showing the window. Commenting out test_backend(); makes it open. Debugging, I've noticed that it segfaults when executing line: SettingsBackend? backend1 = SettingsBackend.get_default (); I'm running from current master flatpak, built with GNOME Builder (Nightly). Debug log: GNU gdb (GDB) 8.0.1 [...] Reading symbols from /home/dsboger/.var/app/org.gnome.Builder/cache/gnome-builder/install/dconf-editor/host/bin/dconf-editor...done. [Thread debugging using libthread_db enabled] Using host libthread_db library "/usr/lib/libthread_db.so.1". Temporary breakpoint 1, main (argc=1, argv=0x7fffffffe528) at dconf-editor.c:167 [New Thread 0x7fffee18c700 (LWP 22990)] [New Thread 0x7fffed98b700 (LWP 22991)] Thread 1 "dconf-editor" hit Breakpoint 2, configuration_editor_real_startup (base=<optimized out>) at /home/dsboger/Pessoal/dconf-editor/editor/dconf-editor.vala:84 84 test_backend (); [Switching to thread 3 (Thread 0x7fffed98b700 (LWP 22991))](running) [Switching to thread 3 (Thread 0x7fffed98b700 (LWP 22991))](running) [Switching to thread 3 (Thread 0x7fffed98b700 (LWP 22991))](running) [Switching to thread 3 (Thread 0x7fffed98b700 (LWP 22991))](running) Thread 1 "dconf-editor" received signal SIGSEGV, Segmentation fault. 0x00007ffff76029d6 in g_type_check_instance_cast () from /usr/lib/libgobject-2.0.so.0 Single stepping until exit from function g_type_check_instance_cast, which has no line number information. [Switching to thread 2 (Thread 0x7fffee18c700 (LWP 22990))] [Thread 0x7fffed98b700 (LWP 22991) exited] [Thread 0x7fffee18c700 (LWP 22990) exited] Program terminated with signal SIGSEGV, Segmentation fault. The program no longer exists.
It was working too easily to be possible. :) I’m using the GNOME nightly-apps flatpak repository, and my two computers run perfectly fine `flatpak run ca.desrt.dconf-editor`. It crashes silently on `GSETTINGS_BACKEND=null flatpak run ca.desrt.dconf-editor`, but the “memory” backend is working. Can you test this repository? flatpak remote-add --if-not-exists gnome-nightly https://sdk.gnome.org/gnome-nightly.flatpakrepo flatpak remote-add --if-not-exists gnome-apps-nightly https://sdk.gnome.org/gnome-apps-nightly.flatpakrepo flatpak install gnome-apps-nightly ca.desrt.dconf-editor flatpak run ca.desrt.dconf-editor What `flatpak` version are you running? Here it’s 0.10.0 (Fedora 27). I didn’t try building directly with Builder, do you know from where it is taking it’s build informations?
(In reply to Arnaud B. from comment #1) > It was working too easily to be possible. :) > > I’m using the GNOME nightly-apps flatpak repository, and my two computers > run perfectly fine `flatpak run ca.desrt.dconf-editor`. It crashes silently > on `GSETTINGS_BACKEND=null flatpak run ca.desrt.dconf-editor`, but the > “memory” backend is working. Can you test this repository? > > flatpak remote-add --if-not-exists gnome-nightly > https://sdk.gnome.org/gnome-nightly.flatpakrepo > flatpak remote-add --if-not-exists gnome-apps-nightly > https://sdk.gnome.org/gnome-apps-nightly.flatpakrepo > flatpak install gnome-apps-nightly ca.desrt.dconf-editor > flatpak run ca.desrt.dconf-editor It works from there. > What `flatpak` version are you running? Here it’s 0.10.0 (Fedora 27). I'm running 0.10.0 from Arch. > I didn’t try building directly with Builder, do you know from where it is > taking it’s build informations? I just noticed that on Builder the runtime was configured to host system. I changed it to org.gnome.Platform master and it works. Not sure what all that means. I didn't test building and running outside of Builder (and no flatpak at all). Maybe my system is missing something.
Is your broken build crashing all the time, or half the time? When the G_SETTINGS_ENABLE_BACKEND compilation variable is not set, I discovered that the app was crashing at startup randomly. I suspect that when you’re building to the host, Builder tries to rewrite/select the compilation variables, and maybe is failing to pick this one; then, it would be a Builder bug.
(In reply to Arnaud B. from comment #3) > Is your broken build crashing all the time, or half the time? When the > G_SETTINGS_ENABLE_BACKEND compilation variable is not set, I discovered that > the app was crashing at startup randomly. I suspect that when you’re > building to the host, Builder tries to rewrite/select the compilation > variables, and maybe is failing to pick this one; then, it would be a > Builder bug. It segfaults consistently. I tried building outside of Builder with: mkdir build meson build cd build ninja sudo ninja install That installs everything under /usr/local and also segfaults consistently. I think it is not related to Builder.
Can you send me please [arnaud d0t bonatti @t gm@il dôt com] a Flatpak built against your host? It should be able to run here, and if so, I’ll just close saying it’s your system the problem. :P (I keep in mind the problem anyway, the “backends” patch *should* be working, so I’ll keep it in master, but I’ll notify releaser so that they don’t loose too much time if that’s failing in their distribution.)
I am having the segfault problem as well. A work around is to use valgrind to execute dconf-editor.
I disabled the SettingsBackend stuff, so it’s fixed. We’ll come back to that later. *** This bug has been marked as a duplicate of bug 791597 ***