GNOME Bugzilla – Bug 414783
Save As crashes
Last modified: 2018-06-29 21:28:53 UTC
Steps to reproduce: 1. Open a document 2. File->Save As 3. Boom Stack trace: Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x00000034 0x006589e8 in draw_cell (grid=0x65ad1a0, block=0x3078c10, virt_loc={vcell_loc = {virt_row = 1, virt_col = 0}, phys_row_offset = 0, phys_col_offset = 0}, drawable=0x65e54b8, x=0, y=0, width=81, height=17) at gnucash-grid.c:436 436 if ((virt_loc.phys_row_offset == 0) && (gdb) bt
+ Trace 115910
Other information: This stack trace is from r15678 with no modifications. The statement that is crashing is if ((virt_loc.phys_row_offset == 0) && (table->model->dividing_row >= 0)) The immediate cause of the crash is that table->model is zero. In case this depends on the file being saved, I'll attach my test file to this, it's small.
Created attachment 83940 [details] The file I was trying to do a Save As on when it crashed.
Does it crash *every* time? Also, which version of libgnomeui and gtk is this? In case you already explained this in IRC, please add a link to the appropriate http://lists.gnucash.org/logs here.
Yes, it crashes every time. However it depends on what registers are open and whether they have focus. I also discovered this happens when saving a new file so the easiest way to reproduce it is to create a new file (taking all the defaults), open the Checking Account register, and do a save. I have things set to open the register in a new page in the same window, I don't know if that matters. It doesn't seem to matter whether the register is in Transaction Journal or Basic Ledger mode. You get the crash described above if the Checking Account register has focus at the time of the save. However, if it is open but not focused then the save seems to work, but GnuCash crashes if you immediately quit. This crash is different, I'll attach the backtrace for it too. If nothing but the account tree is open then the save works ok and GnuCash quits ok. The version of libgnomeui is 2.14.1 and gtk is 2.6.10. Both were installed from Fink.
Here is the second backtrace: 0 libgncmod-ledger-core.dylib 0x005fe9b0 gnc_split_register_get_info + 52 (split-register-util.c:68) 1 libgncmod-ledger-core.dylib 0x005ee178 gnc_split_register_changed + 32 (split-register.c:1932) 2 libgnc-gnome.0.dylib 0x004979c4 gnc_plugin_page_register_finish_pending + 140 (gnc-plugin-page-register.c:1069) 3 libgncmod-gnome-utils.dylib 0x01074874 gnc_plugin_page_finish_pending + 244 (gnc-plugin-page.c:936) 4 libgncmod-gnome-utils.dylib 0x01060704 gnc_main_window_finish_pending + 252 (gnc-main-window.c:895) 5 libgncmod-gnome-utils.dylib 0x010607c4 gnc_main_window_all_finish_pending + 76 (gnc-main-window.c:910) 6 libgncmod-gnome-utils.dylib 0x01067bb8 gnc_main_window_cmd_file_quit + 32 (gnc-main-window.c:3034) 7 libgobject-2.0.0.dylib 0x02ad337c g_closure_invoke + 400 8 libgobject-2.0.0.dylib 0x02ae408c signal_emit_unlocked_R + 2676 9 libgobject-2.0.0.dylib 0x02ae54b8 g_signal_emit_valist + 1924 10 libgobject-2.0.0.dylib 0x02ae571c g_signal_emit + 48 11 libgtk-x11-2.0.0.dylib 0x02223afc gtk_action_activate + 444 12 libgobject-2.0.0.dylib 0x02ad337c g_closure_invoke + 400 13 libgobject-2.0.0.dylib 0x02ae408c signal_emit_unlocked_R + 2676 14 libgobject-2.0.0.dylib 0x02ae54b8 g_signal_emit_valist + 1924 15 libgobject-2.0.0.dylib 0x02ae571c g_signal_emit + 48 16 libgtk-x11-2.0.0.dylib 0x0247dbd0 gtk_widget_activate + 240 17 libgtk-x11-2.0.0.dylib 0x02346618 gtk_menu_shell_activate_item + 568 18 libgtk-x11-2.0.0.dylib 0x02346958 gtk_menu_shell_button_release + 552 19 libgtk-x11-2.0.0.dylib 0x02331444 _gtk_marshal_BOOLEAN__BOXED + 244 20 libgobject-2.0.0.dylib 0x02ad337c g_closure_invoke + 400 21 libgobject-2.0.0.dylib 0x02ae42b0 signal_emit_unlocked_R + 3224 22 libgobject-2.0.0.dylib 0x02ae5518 g_signal_emit_valist + 2020 23 libgobject-2.0.0.dylib 0x02ae571c g_signal_emit + 48 24 libgtk-x11-2.0.0.dylib 0x02478200 gtk_widget_event_internal + 752 25 libgtk-x11-2.0.0.dylib 0x0232e6dc gtk_propagate_event + 508 26 libgtk-x11-2.0.0.dylib 0x0232f41c gtk_main_do_event + 1788 27 libgdk-x11-2.0.0.dylib 0x02643ef0 gdk_event_dispatch + 128 28 libglib-2.0.0.dylib 0x02b3c748 g_main_context_dispatch + 600 29 libglib-2.0.0.dylib 0x02b3e324 g_main_context_iterate + 1364 30 libglib-2.0.0.dylib 0x02b3e720 g_main_loop_run + 876 31 libgtk-x11-2.0.0.dylib 0x0232ea90 gtk_main + 224 32 libgncmod-gnome-utils.dylib 0x01056ef8 gnc_ui_start_event_loop + 96 (gnc-gnome-utils.c:388) 33 gnucash-bin 0x00006ef8 inner_main + 396 (gnucash-bin.c:467) 34 libguile.12.dylib 0x029660d8 scm_boot_guile + 120 (init.c:617) 35 gnucash-bin 0x00007384 main + 516 (gnucash-bin.c:592) 36 gnucash-bin 0x000033e0 _start + 760 37 gnucash-bin 0x000030e4 start + 48
I can't reproduce with Linux, I'm guessing it's Mac-specific. I'm also having a hard time seeing any relation between the original stack trace and the one in comment 4. They might be separate bugs.
I don't know why you can't reproduce the problem, but here's some more info that might help find it. The problems is that gnc_split_register_destroy is being called for the currently active register during save as. After this, it's only a matter of time before you crash. The stack trace where this is happening (while saving a new document) looks like this:
+ Trace 116206
When gnc_file_save_as calls gnc_clear_current_session to get rid of the old session, it eventually calls the SX code. This calls gnc_collection_set_template_root to delete the SX template collection. In turn this calls xaccAccountDestory on the template root. This ends up deleting the split register out from under the GUI. I don't really know where the bug is, perhaps something got broken when the account group concept got removed in r15647 or perhaps something is wrong in the SX code or perhaps it's something else. I think both crashes in this bug are due to this problem. If the register that got freed has focus you crash immediately. If not you crash later, when it gets focus if not before.
Ah, I got this bug mixed up with another and tried to reproduce with 2.0.5. It's easily reproducible with svn.
Here's another back trace that may be the same problem. I created a new file, did a save (which did not crash), then a save as to get a second copy. Thread 0 Crashed: 0 libgncmod-ledger-core.dylib 0x005dfb4c gnc_split_register_get_info + 28 (split-register-util.c:68) 1 libgncmod-ledger-core.dylib 0x005d2a18 gnc_split_register_changed + 24 (split-register.c:1945) 2 libgnc-gnome.0.dylib 0x0047b3f4 gnc_plugin_page_register_finish_pending + 84 (gnc-plugin-page-register.c:1074) 3 libgncmod-gnome-utils.dylib 0x01045e58 gnc_main_window_finish_pending + 168 (gnc-main-window.c:926) 4 libgncmod-gnome-utils.dylib 0x01045f78 gnc_main_window_all_finish_pending + 56 (gnc-main-window.c:941) 5 libgnc-gnome.0.dylib 0x00471924 gnc_main_window_cmd_file_save_as + 84 (gnc-plugin-basic-commands.c:344) 6 libgobject-2.0.0.dylib 0x03bf15e4 g_closure_invoke + 372 7 libgobject-2.0.0.dylib 0x03c06d50 signal_emit_unlocked_R + 2880 8 libgobject-2.0.0.dylib 0x03c082bc g_signal_emit_valist + 2012 9 libgobject-2.0.0.dylib 0x03c08760 g_signal_emit + 48 10 libgtk-x11-2.0.0.dylib 0x02bd2d34 _gtk_action_emit_activate + 108 11 libgtk-x11-2.0.0.dylib 0x02bd2e38 gtk_action_activate + 208 12 libgobject-2.0.0.dylib 0x03bf15e4 g_closure_invoke + 372 13 libgobject-2.0.0.dylib 0x03c06d50 signal_emit_unlocked_R + 2880 14 libgobject-2.0.0.dylib 0x03c082bc g_signal_emit_valist + 2012 15 libgobject-2.0.0.dylib 0x03c08760 g_signal_emit + 48 16 libgtk-x11-2.0.0.dylib 0x02ef08d4 gtk_widget_activate + 244 17 libgtk-x11-2.0.0.dylib 0x02d480b0 gtk_menu_shell_activate_item + 532 18 libgtk-x11-2.0.0.dylib 0x02d46a1c gtk_menu_shell_button_release + 532 19 libgtk-x11-2.0.0.dylib 0x02d387b0 gtk_menu_button_release + 316 20 libgtk-x11-2.0.0.dylib 0x02d2bc98 _gtk_marshal_BOOLEAN__BOXED + 308 21 libgobject-2.0.0.dylib 0x03bf15e4 g_closure_invoke + 372 22 libgobject-2.0.0.dylib 0x03c06f8c signal_emit_unlocked_R + 3452 23 libgobject-2.0.0.dylib 0x03c08320 g_signal_emit_valist + 2112 24 libgobject-2.0.0.dylib 0x03c08760 g_signal_emit + 48 25 libgtk-x11-2.0.0.dylib 0x02ef0760 gtk_widget_event_internal + 908 26 libgtk-x11-2.0.0.dylib 0x02ef00b8 gtk_widget_event + 340 27 libgtk-x11-2.0.0.dylib 0x02d29868 gtk_propagate_event + 816 28 libgtk-x11-2.0.0.dylib 0x02d27b6c gtk_main_do_event + 1296 29 libgdk-x11-2.0.0.dylib 0x03134388 gdk_event_dispatch + 196 30 libglib-2.0.0.dylib 0x03c70074 g_main_context_dispatch + 900 31 libglib-2.0.0.dylib 0x03c708dc g_main_context_iterate + 1404 32 libglib-2.0.0.dylib 0x03c70ce4 g_main_loop_run + 884 33 libgtk-x11-2.0.0.dylib 0x02d26cbc gtk_main + 332 34 libgncmod-gnome-utils.dylib 0x0103e6e4 gnc_ui_start_event_loop + 84 (gnc-gnome-utils.c:429) 35 gnucash-bin 0x00003ff8 inner_main + 584 (gnucash-bin.c:479) 36 libguile.12.dylib 0x03b2abec invoke_main_func + 88 37 libguile.12.dylib 0x03b2ab70 scm_boot_guile_1 + 124 38 libguile.12.dylib 0x03b2a868 scm_boot_guile + 84 39 gnucash-bin 0x00004858 main + 2104 (gnucash-bin.c:609) 40 gnucash-bin 0x000039bc _start + 760 41 gnucash-bin 0x000036c0 start + 48
Fixed in r15975. This timing window has always been present between 1) moving all the books from the current session to a new session, and 2) setting the new session as the current one. Any callback triggered during this window that tries to compare something to the "current book" will be comparing to the wrong value. The change from an top level SX account group to a SX root account appears to be what is triggering the problem, although I would expect the same result from the change from a top level account group to a top level account.
Merged into 2.0 as r16083. Should be in 2.0.6 if we have one.
*** Bug 456062 has been marked as a duplicate of this bug. ***
*** Bug 478231 has been marked as a duplicate of this bug. ***
*** Bug 496327 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=414783. Please update any external references or bookmarks.