The message looks like this (gnucash:24946): GLib-CRITICAL **: g_key_file_set_value: assertion `g_key_file_is_key_name (key)' failed It puts out 14 of followed by gnucash: [W] "failure loading ""/home/m/.gnucash/books/%2Fhome%2Fm%2Fgnucash%2Fgcash" The latter files exists and is easy to read. It is generated when I click on an entry called gcash in the file menu. There are two entries there gcash and s1. The latter was created when I used "save as" to save my data in /tmp/s1. I meant for this to be temporary, but have no way to get s1 out of this menu now, and so I may be causing the problem by deleting the file s1. (The problem remains if I save back to s1 however.) Given the shape this is in, It's difficult to say whether this is some kind of bug, but it should be easy to check by trying this on a system that does not have this extra choice. =============== emerge --info ================== Portage 2.1.2_rc3-r7 (default-linux/amd64/2006.0, gcc-4.1.1, glibc-2.5-r0, 2.6.19-gentoo-r2 x86_64) ================================================================= System uname: 2.6.19-gentoo-r2 x86_64 AMD Opteron(tm) Processor 242 Gentoo Base System version 1.12.8 Last Sync: Tue, 19 Dec 2006 21:30:01 +0000 ccache version 2.4 [enabled] dev-java/java-config: 1.3.7, 2.0.31 dev-lang/python: 2.4.4 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: 2.4-r6 sys-apps/sandbox: 1.2.18.1 sys-devel/autoconf: 2.13, 2.61 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.17 sys-devel/gcc-config: 1.3.14 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.17-r2 ACCEPT_KEYWORDS="amd64 ~amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -march=opteron -pipe -fomit-frame-pointer" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/java-config/vms/ /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c" CXXFLAGS="-O2 -march=opteron -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig ccache distlocks fixpackages metadata-transfer parallel-fetch sandbox sfperms strict" GENTOO_MIRRORS="http://gentoo.osuosl.org http://cudlug.cudenver.edu/gentoo http://gentoo.binarycompass.org" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="amd64 X aac aiglx alsa apache2 auctex audiofile bash-completion bcmath berkdb bitmap-fonts blas bonobo bzip2 calendar clamav cli cracklib crypt ctype cups dbus debugger dga divx-linux dlloader dri dvd dvdr dvdread elibc_glibc emacs emboss emul-linux86 encode esd fam fastcgi fbcon firefox flac foomaticdb fortran ftp gif glut gnome gphoto2 gpm gstreamer gtk gtk2 iconv imlib input_devices_keyboard input_devices_mouse ipv6 isdnlog java jpeg kde kerberos kernel_linux lapack latin1 leim lesstif libclamav lzw lzw-tiff mbox mcal mime mng mouse mozcalendar mozilla mp3 mpeg mpi mysql mysqli ncurses nls nocd nosendmail nptl nptlonly nsplugin nvidia offensive openal opengl osc oscar oss pam pcre pdf perl png pop pop3d portaudio ppds pppd preview-latex python qt3 quicktime readline reflection samba sasl sdl session sharedmem sockets source sox speex spell spl ssl svg symlink tcltk tcpd tetex threads tiff truetype truetype-fonts type1-fonts usb userland_GNU vhosts video_cards_fbdev video_cards_nvidia video_cards_vesa vorbis xine xmail xorg xpm xv xvid zlib" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY
*** This bug has been marked as a duplicate of 158646 ***
Reopening as this isn't strictly a glib bug. gnucash possibly deviates from the standard in different ways than gnome-vfs, and GKeyFile doesn't have an exception for that. I'm talking of the desktop entry specification, more specifically the key names format given by it - http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s02.html "Key names must contain only the characters A-Za-z0-9-." Due to gnome-vfs it has exception for the following characters in 2.12.6 (2.12.4 and earlier had very forgiving validation or no validation of all for key names format): '_', '/', '+', '.' http://cvs.gnome.org/viewcvs/glib/glib/gkeyfile.c?r1=1.46.2.4&r2=1.46.2.5 So if gnucash uses GKeyfile, it shouldn't use characters other than alphanumeric, a hyphen or if necessary an underscore, slash, plus sign or dot in the key name strings. http://bugzilla.gnome.org/show_bug.cgi?id=343191 for upstream bug about adding the validation of key names.
glib-2.12.7 changes the assertion error to a critical warning in these cases. HEAD and therefore future stable 2.14 series still has it as an assert, so gnucash should still fix it upstream. The conversion to critical warnings was done precisely mostly due to gnucash, see the upstream bug: http://bugzilla.gnome.org/show_bug.cgi?id=390532
(In reply to comment #3) > glib-2.12.7 changes the assertion error to a critical warning in these cases. > HEAD and therefore future stable 2.14 series still has it as an assert, so > gnucash should still fix it upstream. > The conversion to critical warnings was done precisely mostly due to gnucash, > see the upstream bug: http://bugzilla.gnome.org/show_bug.cgi?id=390532 FWIW, it looks like trunk/ is back to being liberal - <http://svn.gnome.org/viewcvs/glib?rev=5254&view=rev>
Yes, both trunk and 2-10 branch, including the 2.12.9 release that is now in portage, error when a key name is used that GKeyFile itself won't be able to read back again.
Josh, I leave this to you to handle upstream
(In reply to comment #6) > Josh, I leave this to you to handle upstream Already resolved, but for completeness: http://svn.gnucash.org/trac/changeset/15458 has the trunk commit which resolves the issue. This will be in 2.1 (beta)/2.2 (stable).
