abrt version: 2.0.0 executable: /usr/bin/gsettings cmdline: gsettings list-recursively org.gnome.desktop.default-applications component: glib2 crash_function: g_settings_schema_new kernel: 2.6.38.2-9.fc15.x86_64 reason: Process /usr/bin/gsettings was killed by signal 6 (SIGABRT) package: glib2-2.28.5-2.fc15 architecture: x86_64 username: xake uid: 500 rating: 4 time: 1302074719 os_release: Fedora release 15 (Lovelock) Text file: event_log, 2782 bytes Text file: maps, 7105 bytes Text file: smaps, 35133 bytes Binary file: coredump, 8978432 bytes Text file: dsos, 4811 bytes Text file: backtrace, 8335 bytes
Created attachment 490164 [details] File: event_log
Created attachment 490165 [details] File: maps
Created attachment 490166 [details] File: smaps
Created attachment 490167 [details] File: dsos
Created attachment 490168 [details] File: backtrace
Upstream bug about issues of this kind: https://bugzilla.gnome.org/show_bug.cgi?id=646039
Package: glib2-2.28.5-2.fc15 Architecture: x86_64 OS Release: Fedora release 16 (Rawhide) How to reproduce ----- 1. ran a local shell script that displays all gnome schemas and their keys and values 2. 3. Comment ----- run the shell script. $ cat /data/schema-keys.sh #!/bin/bash shopt -s -o nounset # Global Declarations declare -rx SCRIPT=${0##*/} # SCRIPT is the name of this script declare -rx DATA_FILE="temp.txt" # this is raw data for tune2s declare -rx KEY_FILE="keys.txt" declare DEVS # this variable is used in tune2fs declare KEYS gsettings list-schemas > $DATA_FILE if test ! -r "$DATA_FILE" ; then printf "$SCRIPT: the report file is missing—aborting\n" >&2 exit 192 fi { while read DEVS ; do printf "%s\n" "$DEVS" gsettings list-recursively $DEVS > $KEY_FILE { while read KEYS ; do printf "%s\n" " $KEYS" done } < $KEY_FILE done } < $DATA_FILE exit 0
Package: glib2-2.28.5-2.fc15 Architecture: x86_64 OS Release: Fedora release 15 (Lovelock) Comment ----- Use "gsettings list-recursively" to find key names.
This is not going to get fixed in glib 2.28.x, since it has some compatibility concerns. Strictly speaking, it is not gsettings' fault. The installed schemas are inconsistent, since some of them refer to nonexisting child schemas. Better handling of this situation will have to wait until 2.30 in F16. See the upstream bug for more information.