GNOME Bugzilla – Bug 107953
Crash while generating report
Last modified: 2018-06-29 20:29:52 UTC
Change the options for a report. Press apply Press OK while it is still working. Get a crash: Backtrace was generated from '/usr/bin/guile' (no debugging symbols found)...[New Thread 8192 (LWP 2370)] 0x420ae169 in wait4 () from /lib/i686/libc.so.6
+ Trace 34692
Thread 1 (Thread 8192 (LWP 2370))
What version of gnucash? What report?
Every report I tried exhibited this behavior. Try: Income/Expense Advanced Portfolio Expense Piechart Net worth barchart ... I am using 1.8.1
First, can you upgrade to 1.8.2 and try again. Second, can you provide any scheme backtrace that might be displayed on the terminal where you started gnucash? If you start gnucash from a menu option, can you NOT do that -- run "gnucash &" from your terminal, and then try to reproduce this? I suspect you have a lot of transactions, right? About how many? I don't have a test account with lots of transactions, so I cannot click "Apply, OK" quick enough to reproduce what I suspect is a race condition. Alternatively, can you supply your data file so I have a working dataset to test with?
Created attachment 14949 [details] Back trace generated during Income Expense report
Installed 1.8.2, and ran from a terminal. See attached scheme backtraces.
Created attachment 14950 [details] Backtrace generated during Advanced Portfolio report
Uh, you missed the actual backtraces in your attachments...
Sorry, I mistook all the debug output for a scheme backtrace ( I havent't seen a scheme backtrace before... ) There was no backtrace generated. That is where the output stops. Do any of the other regular developers have large files for testing? I am reluctant to send you all my financial transactions going back five quarters, if I can avoid it! :) My gnucash data file is ~2.5 megs.
Hi, I just started looking at this again. I still cannot reproduce it here with my data set. The tail end of your income/expense report seems to have a backtrace: guppi-text-state.c:guppi_text_state_get_block:338: text changed size 122.494 14.614 guppi-text-state.c:guppi_text_state_get_block:338: text changed size 139.186 12.274 guppi-layout-engine.c:schedule_layout:508: layout scheduled Backtrace: See, the backtrace would have been here. Unfortunately I don't have a scheme backtrace handy to show you, but it would have listed a bunch of procedures and ended with a "wrong argument type" message.. But as I said, I cannot reproduce this. Perhaps you can email me a sample data file out-of-band instead of posting it here?
AHA! I was just able to reproduce this today (using a P&L report).
Ok, the problem is that in the middle of the Apply function it tries to refresh the screen, which opens up the GTK event window, which allows you to hit "OK", which then runs the apply (again), and closes the window (thus destroying state). So, when control finally pops back up the stack to the original "apply", the existing state is no longer there. Oops. I've got a simple patch which fixes the problem by disallowing you from hitting "ok" until the apply actually finishes. This should prevent this crash, but there is an underlying issue going on (the crash might occur in other ways). Hopefully the gnome2 port can fix this -- I think it's somewhat related to an MDI issue. In particular, the gnc_mdi_show_progress() calls gtk_main_iteration() which accepts the button press. Anyways, fixes are applied to CVS and 1.8. Thanks for reporting this.
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=107953. Please update any external references or bookmarks.