After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 649635 - dconf-editor sigsegv at gvdb-reader.c
dconf-editor sigsegv at gvdb-reader.c
Status: RESOLVED FIXED
Product: dconf-editor
Classification: Other
Component: general
0.7.x
Other All
: Normal critical
: ---
Assigned To: dconf-editor maintainer(s)
dconf-editor maintainer(s)
: 649729 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2011-05-07 08:43 UTC by Antoine Jacoutot
Modified: 2015-02-22 12:23 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
backtrace of dconf-editor sigsegv (11.47 KB, text/plain)
2011-05-07 08:43 UTC, Antoine Jacoutot 		Details
info threads (7.27 KB, text/plain)
2011-05-08 10:33 UTC, Antoine Jacoutot 		Details

Description Antoine Jacoutot 2011-05-07 08:43:54 UTC 
Created attachment 187411 [details]
backtrace of dconf-editor sigsegv

Hi.

Running dconf-editor 0.7.4 (under OpenBSD/i386), I get a crash when clicking on an entry (here, trying to go into apps/empathy).

Backtrace attached.
Comment 1 Allison Karlitskaya (desrt) 2011-05-07 09:07:48 UTC 
hi

This might be the same as bug #648949.  The fix for that was released yesterday as part of dconf 0.7.4.  Can you give that a try?
Comment 2 Antoine Jacoutot 2011-05-07 09:13:54 UTC 
Hi Ryan.

As I mentioned in the original post, I'm already running dconf 0.7.4.
Comment 3 Allison Karlitskaya (desrt) 2011-05-08 09:48:28 UTC 
I'm sorry that I didn't catch that.

Indeed, it seems that other users are reporting the same problem.  I obviously didn't do a good job with the new locking scheme.

I'll look into this further.
Comment 4 Allison Karlitskaya (desrt) 2011-05-08 10:08:07 UTC 
Antoine: would it be possible to get a backtrace showing all threads?  If this is indeed a locking issue, it would help quite a lot to see what is happening in the other threads.
Comment 5 Antoine Jacoutot 2011-05-08 10:33:24 UTC 
Created attachment 187445 [details]
info threads
Comment 6 Antoine Jacoutot 2011-05-08 10:33:51 UTC 
Seems only one thread is involved, please see attachment.
Comment 7 Allison Karlitskaya (desrt) 2011-05-08 11:14:28 UTC 
So I think that this is not related to the threading fix I made, but another unreleated feature addition in 0.7.4 for lockdown support.  That makes it easier.  Thanks.
Comment 8 Allison Karlitskaya (desrt) 2011-05-08 11:15:42 UTC 
Got it.  It happens when the user's dconf database doesn't already exist (which is why none of us have seen it).  Expect a fix today.
Comment 9 Allison Karlitskaya (desrt) 2011-05-08 12:12:12 UTC 
should be fixed now

i plan to do a release in the next day or two.  sorry for the mess.


commit c80896f5644ec0a07822047dd7e899da63b42e89
Author: Ryan Lortie <desrt@desrt.ca>
Date:   Sun May 8 14:08:38 2011 +0200

    Fix crash when user database is not present
    
    If we fail to open the database in the user's home directory then the
    variable will be NULL.  The refactor of the read function for lockdown
    support missed this check, resulting in a rather dramatic crash on fresh
    accounts.
Comment 10 Antoine Jacoutot 2011-05-08 12:21:54 UTC 
(In reply to comment #9)
> should be fixed now
> 
> i plan to do a release in the next day or two.  sorry for the mess.

Hi Ryan.

I can confirm it fixed the issue. No need to be sorry, fixing a bug report that fast deserves a thank you instead ;-)
Cheers!
Comment 11 Ionut Biru 2011-05-08 14:59:17 UTC 
I can confirm too that this patch fixes the problem in arch.
Comment 12 Allison Karlitskaya (desrt) 2011-05-08 15:46:09 UTC 
*** Bug 649729 has been marked as a duplicate of this bug. ***
Comment 13 André Klapper 2015-02-22 12:23:18 UTC 
[moving dconf>editor tickets to dconf-editor product. See bug 744791]