Bug 611571

Summary:

[abrt] crash in gnucash-2.3.13-1.fc13: __strncmp_ssse3: Process /usr/bin/gnucash-bin was killed by signal 11 (SIGSEGV)

Product:

[Fedora] Fedora

Reporter:

Ralf Ertzinger <redhat-bugzilla>

Component:

gnucash

Assignee:

Bill Nottingham <notting>

Status:

CLOSED UPSTREAM

QA Contact:

Fedora Extras Quality Assurance <extras-qa>

Severity:

medium

Docs Contact:

Priority:

low

Version:

CC:

notting, rvokal

Target Milestone:

---

Target Release:

---

Hardware:

x86_64

OS:

Linux

Whiteboard:

abrt_hash:732ae349cac211081cc5720d635a6174d12055ae

Fixed In Version:

Doc Type:

Bug Fix

Doc Text:

Story Points:

---

Clone Of:

Environment:

Last Closed:

2010-07-13 17:57:51 UTC

Type:

---

Regression:

---

Mount Type:

---

Documentation:

---

CRM:

Verified Versions:

Category:

---

oVirt Team:

---

RHEL 7.3 requirements from Atomic Host:

Cloudforms Team:

---

Target Upstream Version:

Embargoed:

Attachments:

Description	Flags
File: backtrace	none

Description Ralf Ertzinger 2010-07-05 18:00:00 UTC

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

Comment 1 Ralf Ertzinger 2010-07-05 18:00:03 UTC

Created attachment 429572 [details]
File: backtrace

Comment 2 Bill Nottingham 2010-07-12 21:19:18 UTC

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.

Comment 3 Ralf Ertzinger 2010-07-12 22:53:51 UTC

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).

Comment 4 Bill Nottingham 2010-07-13 17:50:07 UTC

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.

Comment 5 Bill Nottingham 2010-07-13 17:57:51 UTC

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.

Comment 6 Ralf Ertzinger 2010-07-13 19:32:27 UTC

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?

Comment 7 Bill Nottingham 2010-07-13 20:27:48 UTC

It blows up in strncmp because it was passed a null string, which is a no-no.