abrt 1.1.1 detected a crash. architecture: x86_64 Attached file: backtrace cmdline: /usr/bin/gnucash bin component: gnucash crash_function: __strncmp_ssse3 executable: /usr/bin/gnucash-bin global_uuid: 732ae349cac211081cc5720d635a6174d12055ae kernel: 2.6.33.5-124.fc13.x86_64 package: gnucash-2.3.13-1.fc13 rating: 4 reason: Process /usr/bin/gnucash-bin was killed by signal 11 (SIGSEGV) release: Fedora release 13 (Goddard) How to reproduce ----- 1. Open gnucash file 2. Add a report 3. Click 'Options' in the main icon bar. Seems to work for all reports, even for ones opened automatically with the file
Created attachment 429572 [details] File: backtrace
I can't reproduce this here in brief testing... 'Expenses vs. Day of Week', 'Advanced Portfolio', 'Cash Flow', etc. all work, and I can select 'Options' without a crash.
Thanks for the comment, I've found one more datapoint because of it. I run my desktop with LANG=en_US.UTF-8, but gnucash with LANG=de_DE (my financial slang is not exactly up to date). gnucash with LANG=de_DE crashes, gnucash under the normal desktop locale does not (using the same account save file).
788 if (item != NULL) 789 { 790 normalized_string = g_utf8_normalize (item, -1, G_NORMALIZE_ALL); 791 case_normalized_string = g_utf8_casefold (normalized_string, -1); 792 793 if (!strncmp (key, case_normalized_string, strlen (key))) 794 ret = TRUE; 795 796 g_free (item); 797 g_free (normalized_string); (gdb) print item $3 = (gchar *) 0x36af550 "ANG (Niederl\344ndische Antillen-Gulden)" You're running with LANG=de_DE, which is a non-UTF-8 locale, despite the rest of your system being in UTF-8. So, it's returning a null string. Ideally, gtk shouldn't blow up here, but I think the simplest solution for you is to just run gnucash with LANG=de_DE.UTF-8. That works for me in brief testing.
Filed upstream as: https://bugzilla.gnome.org/show_bug.cgi?id=624270. Closing here as there's a workaround... let me know if the workaround doesn't work for you.
de_DE.UTF-8 seems to work. Is my backtrace mojo totally off, or does this blow up in strncmp itself and not in gtk?
It blows up in strncmp because it was passed a null string, which is a no-no.