GNOME Bugzilla – Bug 564928
Segfault when closing a invoice tab
Last modified: 2018-06-29 22:14:04 UTC
When I open and edit a invoice in gnucash and then click on the "Close" button to close the currently opened invoice, gnucash crash with segfault. Steps to reproduce : 1. Open gnucash with a file that already contains customers and invoices. 2. Click on Business / Customer / Find invoice, find and double-click on a invoice to open it in gnucash. 3. Click on the "Close" button to close the current invoice. Result : Segfault. I attach a gdb backtrace. I will also do a git bisect today to find which revision introduced that regression. I think that 2.2.7 didn't have that problem.
Created attachment 124896 [details] GDB Backtrace
Thanks for the backtrace. Questions: Can you narrow down the sort of windows that exhibit this crash on closing? I.e. does that happen when closing any other report window as well? Do you think you could add a very small example file that reproduces this bug every time? Thanks.
Created attachment 124933 [details] Sample file to reproduce the bug
At the mean time, I can't reproduce this bug in any other section of gnucash, it can only be reproduced when closing a invoice. As you asked, I attached a sample file that can be used to reproduce the bug using the steps to reproduce that I previously mentioned. This sample file only contains one single invoice with ID 000001 .
Created attachment 124941 [details] [review] Diff of the commit that caused the regression I found the commit that introduced the regression! It is : commit ebf55e8f6432853a5fc925e41504c77b367f5c14 Author: cstim <cstim@57a11ea4-9604-0410-9ed3-97b8803252fd> Date: Sat Dec 6 21:33:14 2008 +0000 Bug #563273: Fix crash on startup Here's the problem... GnuCash uses a hash table with int keys to store dimensions, and the key value is the number of rows in the dimension being stored. The problem is that this key value is stored in a static int inside the style_get_key function, which means that the key always has the same address, and the hash functions in glib2 store the *address*, not the *value* of the key. Unfortunately, the hash algorithm changed some time between glib2-2.18.2 and glib2-2.19.2, such that there's a hash conflict between the key value 1 and the key value 2, but since the value of the already hashed key was swiped out from under it when style_get_key "created" a new key, the hash table entry that's already there matches even when it shouldn't have. The attached patch cleans this up by allocating memory to hold the key when inserting it into the hash table. It also changes the way the hash table is created to ensure that the memory is freed when a hash table entry or hash table is destroyed. And while I was at it, I made the same fix for the cursors hash table, which was also leaking memory when entries were removed or the table was destroyed. Patch by Jonathan Kamens. BP git-svn-id: http://svn.gnucash.org/repo/gnucash/trunk@17747 57a11ea4-9604-0410-9ed3-97b8803252fd I didn't test if this bug is reproducible with glib2 2.19.* . I reproduce this bug on ubuntu 8.10 which has glib2 2.18.* .
Created attachment 124943 [details] Valgrind
Ok, now we're getting closer. Let me repeat: - The segfault has been observed only when closing an invoice. - The segfault goes away when commit r17747 (bug 563273) is reverted. - The segfault appears with glib2 2.18.*, but potentially not with glib2 2.19.*. @Jonathan Kamens (in CC): Could you double-check your patch from bug 563273 so that it doesn't introduce double-frees with glib 2.18.*? That would be great!
And just for completeness: With the sample file of comment #3 I can reproduce this with both trunk (today, r17779) and 2.2 on a system with glib2-2.12.4. Oops.
Yes, I believe I introduced a double-free. Sorry! Undo this portion of my patch: --- src/register/register-gnome/gnucash-sheet.c~ 2008-01-07 20:05:28.000000000 -0500 +++ src/register/register-gnome/gnucash-sheet.c 2008-12-04 16:01:47.000000000 -0500 @@ -2367,7 +2367,8 @@ sheet->width = 0; sheet->height = 0; - sheet->cursor_styles = g_hash_table_new (g_str_hash, g_str_equal); + sheet->cursor_styles = g_hash_table_new_full (g_str_hash, g_str_equal, + g_free, NULL); sheet->blocks = g_table_new (sizeof (SheetBlock), gnucash_sheet_block_construct, It's not necessary because the hash table keys are freed up in gnucash_sheet_cleer_styles.
I confirm that reverting this specific change fixes the bug
Committed to trunk, r17781, awaiting back-port. I can confirm this fixes the bug with glib2-2.12.4 as well.
2.2 branch, r17783. Thanks a lot!
*** Bug 565604 has been marked as a duplicate of this bug. ***
*** Bug 565740 has been marked as a duplicate of this bug. ***
FTR, you can find r17783 here: http://svn.gnucash.org/trac/changeset/17783?format=diff&new=17783
*** Bug 566385 has been marked as a duplicate of this bug. ***
*** Bug 566505 has been marked as a duplicate of this bug. ***
*** Bug 566671 has been marked as a duplicate of this bug. ***
*** Bug 566682 has been marked as a duplicate of this bug. ***
*** Bug 567162 has been marked as a duplicate of this bug. ***
*** Bug 567161 has been marked as a duplicate of this bug. ***
*** Bug 567951 has been marked as a duplicate of this bug. ***
*** Bug 569420 has been marked as a duplicate of this bug. ***
*** Bug 569853 has been marked as a duplicate of this bug. ***
*** Bug 571028 has been marked as a duplicate of this bug. ***
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=564928. Please update any external references or bookmarks.