Problem first appears in Windows maint build gnucash-3.5-2019-06-13-git-3.5-277-gca759fb49+.setup.exe. (I cannot reproduce in maint build gnucash-3.5-2019-06-07-git-3.5-268-g520f350a9+.setup.exe.) The hang is always triggered by clicking on a report tab, but I can sometimes restart the app and then display that report successfully on a second attempt. I've been unable to construct a minimal repro, and am unable to determine a reliable reproduction in my personal datafile. Happy to help with more testing to narrow down the source, but I am not set up to build GnuCash myself.
FWIW, same problem is present in most recent builds in master.
Do I understand correctly that: * The hang occurs for an already-generated report when you switch to another tab and switch back. * The hang occurs on different reports covering different periods. * You're not able to find a way to reliably get it to hang, but it happens frequently after some amount of activity. * This doesn't happen for a simple example file with few entries.
I've only ever experienced the hang on the first attempt to activate a particular report tab in a session. Once a report has been successfully generated, I seem to be able to switch to and from it indefinitely. It seems to happen only (mainly?) on certain report types. Asset pie charts seem to work reliably, whereas income/expense over time reports seem to trigger the hang readily. The behaviour doesn't seem to be entirely deterministic - I believe I've repeated the same series of tab activations with different results in different sessions (i.e. the hang happens on a different tab). It happens very reliably - I've been repeatedly relaunching GnuCash and immediately clicking through my eight report tabs, and I've never managed to generate all the report tabs in a session. I've been unable to produce a simple example file which reproduces the hang.
A bit different from what I thought. What happens if you start GnuCash and *don't* immediately go looking at reports but instead work in registers or just let it sit for a few minutes, then go to the report tabs? Let's arbitrarily say "a few" means "10".
So I can work in registers apparently indefinitely without triggering this. But it seems no matter how long I do that, I still get the hang on the report tabs.
OK, the experiment was to see if there was something GnuCash was still loading. Thanks.
I was able to get GnuCash to hang by opening 4 reports (Balance Sheet, Profit & Loss, Cash Flow Barchart, Average Balance) in a largeish file. The stack trace for the hang is: #0 print_swig_aux (swig_smob=0x16e23470, port=0x1951ce50, pstate=0x125915f0, attribute=0x67f9cb15 <boost::detail::static_log2_impl::initial_n+557> "") at C:/gcdev64/gnucash/maint/build/gnucash-git/libgnucash/core-utils/swig-core-utils-guile.c:1056 #1 0x67f8b08e in print_swig (swig_smob=0x16e23470, port=0x1951ce50, pstate=0x125915f0) at C:/gcdev64/gnucash/maint/build/gnucash-git/libgnucash/core-utils/swig-core-utils-guile.c:1070 #2 0x6e7dc4fa in iprin1 (exp=0x16e23470, port=0x1951ce50, pstate=0x125915f0) at C:/gcdev64/gnucash/maint/src/guile-2.2.4.68-65d98/libguile/print.c:762 #3 0x6e7dc035 in scm_iprlist ( hdr=hdr@entry=0x6e86645e <s_scm_i_port_property+522> "(", exp=exp@entry=0x1972baf0, tlr=tlr@entry=41, port=port@entry=0x1951ce50, pstate=pstate@entry=0x125915f0) at C:/gcdev64/gnucash/maint/src/guile-2.2.4.68-65d98/libguile/print.c:984 #4 0x6e7dc902 in iprin1 (exp=0x1972baf0, port=0x1951ce50, pstate=0x125915f0) at C:/gcdev64/gnucash/maint/src/guile-2.2.4.68-65d98/libguile/print.c:635 #5 0x6e7dc0cd in scm_iprlist ( hdr=hdr@entry=0x6e86645e <s_scm_i_port_property+522> "(", exp=0x19777330, exp@entry=0x1977b098, tlr=tlr@entry=41, port=port@entry=0x1951ce50, pstate=pstate@entry=0x125915f0) at C:/gcdev64/gnucash/maint/src/guile-2.2.4.68-65d98/libguile/print.c:995 #6 0x6e7dc902 in iprin1 (exp=0x1977b098, port=0x1951ce50, pstate=0x125915f0) at C:/gcdev64/gnucash/maint/src/guile-2.2.4.68-65d98/libguile/print.c:635 #7 0x6e7dbebb in scm_prin1 (exp=0x1977b098, port=0x1951ce50, writingp=0) at C:/gcdev64/gnucash/maint/src/guile-2.2.4.68-65d98/libguile/print.c:816 #8 0x6e7dbc74 in scm_display (obj=0x1977b098, port=<optimized out>) at C:/gcdev64/gnucash/maint/src/guile-2.2.4.68-65d98/libguile/print.c:1090 #9 0x6e815dcb in vm_regular_engine (thread=0xe9d1f00, vp=0xf1edf78, registers=0x68f4d0, resume=0) at C:/gcdev64/gnucash/maint/src/guile-2.2.4.68-65d98/libguile/vm-engine.c:786 #10 0x6e81be96 in scm_call_n (proc=proc@entry=0xf4b02b8, argv=argv@entry=0x68f544, nargs=nargs@entry=3) at C:/gcdev64/gnucash/maint/src/guile-2.2.4.68-65d98/libguile/vm.c:1260 #11 0x6e7965b7 in scm_call_3 (proc=0xf4b02b8, arg1=arg1@entry=0x16e115b0, arg2=arg2@entry=0xfbc0580, arg3=arg3@entry=0xf1f76e0) at C:/gcdev64/gnucash/maint/src/guile-2.2.4.68-65d98/libguile/eval.c:499 #12 0x6e803e7f in scm_eval_string_in_module (string=0x16e115b0, module=0xf1f76e0) at C:/gcdev64/gnucash/maint/src/guile-2.2.4.68-65d98/libguile/strports.c:369 #13 0x6e815dcb in vm_regular_engine (thread=0xe9d1f00, vp=0xf1edf78, registers=0x68f660, resume=0) at C:/gcdev64/gnucash/maint/src/guile-2.2.4.68-65d98/libguile/vm-engine.c:786 #14 0x6e81be96 in scm_call_n (proc=proc@entry=0xfa90048, argv=argv@entry=0x68f6e4, nargs=nargs@entry=1) at C:/gcdev64/gnucash/maint/src/guile-2.2.4.68-65d98/libguile/vm.c:1260 #15 0x6e79652f in scm_call_1 (proc=0xfa90048, arg1=<optimized out>) at C:/gcdev64/gnucash/maint/src/guile-2.2.4.68-65d98/libguile/eval.c:485 #16 0x6a047f78 in gfec_eval_string (str=0x13814700 "(gnc:report-run 3)", error_handler=0x31e17d8 <error_handler>) at C:/gcdev64/gnucash/maint/src/gnucash-git/libgnucash/app-utils/gfec.c:74 #17 0x031e1865 in gnc_run_report (report_id=3, data=0x68f7ec) at C:/gcdev64/gnucash/maint/src/gnucash-git/gnucash/report/report-system/gnc-report.c:163 #18 0x031e196e in gnc_run_report_id_string (id_string=0x1b964018 "id=3", data=0x68f7ec) at C:/gcdev64/gnucash/maint/src/gnucash-git/gnucash/report/report-system/gnc-report.c:189 #19 0x0313f842 in gnc_html_report_stream_cb (location=0x1b964018 "id=3", data=0x68f7ec, len=0x68f7e8) at C:/gcdev64/gnucash/maint/src/gnucash-git/gnucash/report/report-gnome/window-report.c:273 #20 0x624448bc in load_to_stream (self=0xc740fc0, type=0x1b963d98 "report", location=0x1b964018 "id=3", label=0x0) at C:/gcdev64/gnucash/maint/src/gnucash-git/gnucash/html/gnc-html-webkit1.c:488 #21 0x624455f9 in impl_webkit_show_url (self=0xc740fc0, type=0x1b963d98 "report", location=0x1b964018 "id=3", label=0x0, new_window_hint=0) at C:/gcdev64/gnucash/maint/src/gnucash-git/gnucash/html/gnc-html-webkit1.c:924 #22 0x624421bf in gnc_html_show_url (self=0xc740fc0, type=0xcb0def8 "report", location=0x1b964018 "id=3", label=0x0, new_window_hint=0) at C:/gcdev64/gnucash/maint/src/gnucash-git/gnucash/html/gnc-html.c:368 #23 0x03139f32 in gnc_plugin_page_report_load_uri (page=0xca6c120) at C:/gcdev64/gnucash/maint/src/gnucash-git/gnucash/report/report-gnome/gnc-plugin-page-report.c:392 #24 0x64bf3ad0 in ?? () from C:\Program Files (x86)\gnucash\bin\libglib-2.0-0.dll #25 0x64bf3e2f in ?? () from C:\Program Files (x86)\gnucash\bin\libglib-2.0-0.dll #26 0x64bf426d in ?? () from C:\Program Files (x86)\gnucash\bin\libglib-2.0-0.dll #27 0x0153e101 in gtk_main () at gtkmain.c:1323 #28 0x6c90a8a9 in gnc_ui_start_event_loop () at C:/gcdev64/gnucash/maint/src/gnucash-git/gnucash/gnome-utils/gnc-gnome-utils.c:671 #29 0x0040367e in inner_main (closure=0x0, argc=1, argv=0x94a9998) at C:/gcdev64/gnucash/maint/src/gnucash-git/gnucash/gnucash-bin.c:680 #30 0x6e7afdc0 in invoke_main_func (body_data=0x68fe80) at C:/gcdev64/gnucash/maint/src/guile-2.2.4.68-65d98/libguile/init.c:341 #31 0x6e790e30 in c_body (d=0x68fdc4) at C:/gcdev64/gnucash/maint/src/guile-2.2.4.68-65d98/libguile/continuations.c:422 #32 0x6e815dcb in vm_regular_engine (thread=0xe9d1f00, vp=0xf1edf78, registers=0x68fc30, resume=0) at C:/gcdev64/gnucash/maint/src/guile-2.2.4.68-65d98/libguile/vm-engine.c:786 #33 0x6e81be96 in scm_call_n (proc=proc@entry=0xf38c160, argv=argv@entry=0x0, nargs=nargs@entry=0) at C:/gcdev64/gnucash/maint/src/guile-2.2.4.68-65d98/libguile/vm.c:1260 #34 0x6e7964ff in scm_call_0 (proc=proc@entry=0xf38c160) at C:/gcdev64/gnucash/maint/src/guile-2.2.4.68-65d98/libguile/eval.c:479 #35 0x6e8098fb in catch (tag=0x404, thunk=0xf38c160, handler=0xf38c150, pre_unwind_handler=0xf38c140) at C:/gcdev64/gnucash/maint/src/guile-2.2.4.68-65d98/libguile/throw.c:137 #36 0x6e809bf8 in scm_catch_with_pre_unwind_handler ( pre_unwind_handler=<optimized out>, handler=<optimized out>, thunk=<optimized out>, key=<optimized out>) at C:/gcdev64/gnucash/maint/src/guile-2.2.4.68-65d98/libguile/throw.c:254 #37 scm_c_catch (tag=<optimized out>, tag@entry=0x404, body=<optimized out>, body@entry=0x6e790e20 <c_body>, body_data=<optimized out>, body_data@entry=0x68fdc4, handler=<optimized out>, handler@entry=0x6e791020 <c_handler>, handler_data=handler_data@entry=0x68fdc4, pre_unwind_handler=pre_unwind_handler@entry=0x6e790e40 <pre_unwind_handler>, pre_unwind_handler_data=pre_unwind_handler_data@entry=0xf1ea510) at C:/gcdev64/gnucash/maint/src/guile-2.2.4.68-65d98/libguile/throw.c:377 #38 0x6e791385 in scm_i_with_continuation_barrier ( body=body@entry=0x6e790e20 <c_body>, body_data=body_data@entry=0x68fdc4, handler=handler@entry=0x6e791020 <c_handler>, handler_data=handler_data@entry=0x68fdc4, pre_unwind_handler=pre_unwind_handler@entry=0x6e790e40 <pre_unwind_handler>, pre_unwind_handler_data=0xf1ea510) at C:/gcdev64/gnucash/maint/src/guile-2.2.4.68-65d98/libguile/continuations.c:360 #39 0x6e791424 in scm_c_with_continuation_barrier ( func=0x6e7afd90 <invoke_main_func>, data=0x68fe80) at C:/gcdev64/gnucash/maint/src/guile-2.2.4.68-65d98/libguile/continuations.c:456 #40 0x6e808365 in with_guile (base=0x68fe2c, data=0x68fe54) at C:/gcdev64/gnucash/maint/src/guile-2.2.4.68-65d98/libguile/threads.c:661 #41 0x70bcdaec in GC_call_with_stack_base ( fn=fn@entry=0x6e808320 <with_guile>, arg=arg@entry=0x68fe54) at C:/gcdev64/gnucash/maint/src/bdwgc/misc.c:1935 #42 0x6e808d00 in scm_i_with_guile (dynamic_state=<optimized out>, data=0x68fe80, func=0x6e7afd90 <invoke_main_func>) at C:/gcdev64/gnucash/maint/src/guile-2.2.4.68-65d98/libguile/threads.c:704 #43 scm_with_guile (func=func@entry=0x6e7afd90 <invoke_main_func>, data=data@entry=0x68fe80) at C:/gcdev64/gnucash/maint/src/guile-2.2.4.68-65d98/libguile/threads.c:710 #44 0x6e7aff97 in scm_boot_guile (argc=1, argv=0x94a9998, main_func=0x403476 <inner_main>, closure=0x0) at C:/gcdev64/gnucash/maint/src/guile-2.2.4.68-65d98/libguile/init.c:324 #45 0x00403d1b in main (argc=1, argv=0x94a9998) at C:/gcdev64/gnucash/maint/src/gnucash-git/gnucash/gnucash-bin.c:938
After more testing I don't think I did reproduce the problem, I think that the hang I encountered is limited to the Average Balance report: * I wasn't able to run that report by itself on build 268 that the OP said worked OK. * I was able to run 8 different reports on later builds, including the latest nightly. * I sampled GnuCash in the debugger more than once while trying to get an Average Balance report and got different stack traces on each sample, so it would seem that it's not hung per se, it's just taking a really long time to run that report.
@adrian could share the datafile after processing with https://wiki.gnucash.org/wiki/ObfuscateScript ?
I started the Average Balance report and left for a grocery run. It had completed by the time I came back about 1 1/2 hours later. I quit GnuCash with the Accounts page, one register, and 9 report tabs including an Average Balance report and restarted it. Most of the reports rendered in 5 minutes, leaving only the Average Balance report grinding away. Adrian, what are the 8 reports that you have open? When GnuCash isn't responding does the CPU usage go to zero in Task Manager's details page? If not, what happens if you leave it running overnight?
Created attachment 373308 [details] Obfuscated gnucash datafile Attaching my obfuscated datafile. I'm able to reproduce the hang by opening a series of reports for this file, but I'm unable to be more specific than that - I tried to find a minimal, specific sequence, but the hang seems to come at different points each time I load. (Once it hangs CPU usage drops to 0% - I'll try leaving it in that state overnight tonight and see if it ever comes back.)
I've just experimented with your (large) datafile The majority of time is spent creating the balancelist and converting to target-currency using 'weighted-average' price calculator -- it takes 20s to generate balancelist. So there may be optimisation opportunities here (at the cost of increased code complexity) I can use your datafile to experiment.
above using average-balance report. Are you stating that the 13/6 build is freezing whereas 7/6 isn't? This would be odd.
Yes - all builds since 13/6 are exhibiting this behaviour (including the 3.6 release just made). I've been unable to reproduce it in the 7/6 build and randomly sampled earlier builds. It feels like a deadlock - CPU activity indicates GnuCash isn't doing anything once it hangs. From what I can see in GitHub logs, there doesn't seem to have been anything committed in maint between those builds that could possibly cause it. Is it possible that dependencies were upgraded between those builds?
Ok I can confirm there's occasional genuine hang (using 3.6 Windows 10 en_AU). Can't reliably reproduce though. Adrian -- the clicking of tabs on a fresh restart actually triggers to generation of report.
Noticed from the build logs at https://code.gnucash.org/builds/win32/build-logs/ that between the maint builds on 7/6 and 13/6 GCC was upgraded from 7.4.0 to 9.1.0 and glib from 2.60.1 to 2.60.3.
Unfortunately neither of which is likely to be the cause of a hang. Guile is the prime suspect for that.
Just a tidbit. This datafile obfuscation has munged all amounts so that no transactions are balanced. Check&Repair gets quite busy. Interestingly the balances are updated while UI is still running. What toolchains are recommended to debug Windows hangs nowadays?
Here's a small patch to make average-balance more responsive for large books. I think this is a nice one to apply, irrespective of the cause for this bug. modified gnucash/report/standard-reports/average-balance.scm @@ -242,21 +242,35 @@ (let* ((splits (qof-query-run query)) (daily-dates (gnc:make-date-list begindate enddate DayDelta)) (interval-dates (gnc:make-date-list begindate enddate stepsize)) + + ;; for accounts-balances generation + (work-to-do (length accounts)) (accounts-balances (map - (lambda (acc) + (lambda (work-done acc) + (gnc:report-percent-done + (* 100 (/ work-done work-to-do))) (gnc:account-get-balances-at-dates acc daily-dates)) + (iota work-to-do) accounts)) + + ;; for daily-balances generation + (work-to-do (length daily-dates)) (balances (map - (lambda (date accounts-balance) + (lambda (work-done date accounts-balance) + (gnc:report-percent-done (* 100 (/ work-done work-to-do))) (gnc:gnc-monetary-amount (gnc:sum-collector-commodity (apply gnc:monetaries-add accounts-balance) report-currency (lambda (monetary target-curr) (exchange-fn monetary target-curr date))))) + (iota work-to-do) daily-dates - (apply zip accounts-balances)))) + (apply zip accounts-balances))) + + ;; for upcoming interval-calculators + (work-to-do (length splits))) (qof-query-destroy query) ;; this is a complicated tight loop. start with: @@ -268,10 +282,14 @@ (interval-bals '()) (interval-amts '()) (splits splits) + (work-done 0) (daily-balances (cdr balances)) (daily-dates (cdr daily-dates)) (interval-start (car interval-dates)) (interval-dates (cdr interval-dates))) + + (gnc:report-percent-done (* 100 (/ work-done work-to-do))) + (cond ;; daily-dates finished. job done. add details for @@ -309,6 +327,7 @@ '() ;reset interval-bals '() ;and interval-amts splits + work-done daily-balances daily-dates (car interval-dates) @@ -324,6 +343,7 @@ (cons (car daily-balances) interval-bals) interval-amts splits + work-done (cdr daily-balances) (cdr daily-dates) interval-start @@ -344,6 +364,7 @@ interval-bals interval-amts ;interval-amts unchanged (cddr splits) ;skip two splits. + (+ work-done 2) daily-balances daily-dates interval-start @@ -364,6 +385,7 @@ (car interval-dates))) interval-amts) ;add split amt to list (cdr splits) ;and loop to next split + (1+ work-done) daily-balances daily-dates interval-start
Google "profiling gcc gprof" for a bunch of tutorials on how to do profiling with gcc's tool. AFAIK there's no other option for MinGW. If there's an actual hang--CPU usage goes to 0 in Task Manager--you can attach the debugger and get a back trace to try and understand what it's waiting for. Note that MinGW packages don't provide debugging symbols so if it looks like the hang is in one of those you'll have to build that package from source, quite a chore.
@adrian sorry for digressing, confirming hang continues to exist especially when running random reports in gnucash-portable 3.6; expect more bug reports coming through.
I believe that this exactly describes the issue I have begun experiencing after updating to 3.6 (Windows 10). The reports all become a russian roulette with ~90% chance of immediately hanging the program with no recovery. Worst part is that it still somehow manages to save the fact I swapped to that tab last, so the next time I reopen the app, it's launching on a tab which is highly likely to immediately freeze the program again - so I have to go editing config to remove the offending tabs manually. CPU does drop to 0 when the program stops responding, and a dump seems to indicate that it's somewhere in the webkit/JS stuff. Unfortunately I have neither the symbols nor enough knowledge of Visual Studio to do much more than take and directly open the dump file. libwinpthread-1.dll!64b42e41() Unknown No symbols loaded. [Frames below may be incorrect and/or missing, no symbols loaded for libwinpthread-1.dll] Annotated Frame libwinpthread-1.dll!64b42030() Unknown No symbols loaded. libwinpthread-1.dll!64b4236d() Unknown No symbols loaded. libwinpthread-1.dll!64b4288c() Unknown No symbols loaded. libstdc++-6.dll!6feeed15() Unknown No symbols loaded. libjavascriptcoregtk-3.0-0.dll!070f5599() Unknown No symbols loaded. libwinpthread-1.dll!64b431c0() Unknown No symbols loaded. libstdc++-6.dll!6feeeceb() Unknown No symbols loaded. libcairo-2.dll!68fd8bdc() Unknown No symbols loaded. libcairo-2.dll!690382c8() Unknown No symbols loaded. libwebkitgtk-3.0-0.dll!03c15da2() Unknown No symbols loaded. libjavascriptcoregtk-3.0-0.dll!07160940() Unknown No symbols loaded. libjavascriptcoregtk-3.0-0.dll!07160940() Unknown No symbols loaded. libjavascriptcoregtk-3.0-0.dll!07160940() Unknown No symbols loaded. libjavascriptcoregtk-3.0-0.dll!07127d27() Unknown No symbols loaded. libjavascriptcoregtk-3.0-0.dll!071b62ae() Unknown No symbols loaded. libwebkitgtk-3.0-0.dll!03ab31d2() Unknown No symbols loaded. libwebkitgtk-3.0-0.dll!03bec40a() Unknown No symbols loaded. libwebkitgtk-3.0-0.dll!03bec7f3() Unknown No symbols loaded. libwebkitgtk-3.0-0.dll!03be69cc() Unknown No symbols loaded. libwebkitgtk-3.0-0.dll!03be791b() Unknown No symbols loaded. libwebkitgtk-3.0-0.dll!03be891c() Unknown No symbols loaded. libwebkitgtk-3.0-0.dll!03bf94f9() Unknown No symbols loaded. libwebkitgtk-3.0-0.dll!03bc5ecf() Unknown No symbols loaded. libwebkitgtk-3.0-0.dll!03e74a38() Unknown No symbols loaded. libwebkitgtk-3.0-0.dll!03e74872() Unknown No symbols loaded. libwebkitgtk-3.0-0.dll!03ec28fa() Unknown No symbols loaded. libwebkitgtk-3.0-0.dll!03eb9781() Unknown No symbols loaded. libwebkitgtk-3.0-0.dll!045d37af() Unknown No symbols loaded. libgio-2.0-0.dll!615f4275() Unknown No symbols loaded. libgio-2.0-0.dll!6162140e() Unknown No symbols loaded. libgio-2.0-0.dll!6162145f() Unknown No symbols loaded. libglib-2.0-0.dll!64bf3ad0() Unknown No symbols loaded. libglib-2.0-0.dll!64bf3e2f() Unknown No symbols loaded. libglib-2.0-0.dll!64bf426d() Unknown No symbols loaded. libgtk-3-0.dll!012ae101() Unknown No symbols loaded. libgncmod-gnome-utils.dll!6c90a841() Unknown No symbols loaded. gnucash.exe!00403649() Unknown No symbols loaded. libguile-2.2-1.dll!6e7ae640() Unknown No symbols loaded. libguile-2.2-1.dll!6e790540() Unknown No symbols loaded. libguile-2.2-1.dll!6e8171ee() Unknown No symbols loaded. libguile-2.2-1.dll!6e795a3f() Unknown No symbols loaded. libguile-2.2-1.dll!6e805051() Unknown No symbols loaded. libguile-2.2-1.dll!6e7ae837() Unknown No symbols loaded. gnucash.exe!00403ce6() Unknown No symbols loaded. gnucash.exe!0040138b() Unknown No symbols loaded.
Visual Studio isn't useful here, we use MinGW-w64 and its gcc-based toolchain. That emits DWARF debugging symbols that Visual Studio can't read. Unfortunately the MinGW project also strips their binaries so there aren't any symbols anyway for their packages, and libwebkit-gtk, libjavascript-gtk and libcairo are all from their distribution. I said in comment 7 that neither gcc or glib was likely to be responsible for a hang, but I notice that frames 4 and 7 are in libstdc++.dll. That could well be a problem, as C++ is known to be persnickety about everything being compiled with the same compiler.
TriageQ: should Version be git-maint or 3.6 ? I'm getting this too on Win8.1 since 3.6 but not always. I've no feeling at the moment for why it happens sometimes but not others. I don't think it is report dependant as I've had it happen with multi-col, graph and simple reports. I think it is the report (sub-)system. In case it helps I usually save (and therefore open) with a number of reports, these seem to work fine, i.e. I don't get / haven't had a hang when opening a book. Problems have been observed after a) Reports / Saved reports / choose report / tab gets created but report never shows and hang occurs b) data changes (e.g. I fetch prices or enter a tx) and I go to a report tab and refresh or expect a refresh, hang occurs.
People, if an accounting prog can't reliably produce a balance sheet and an income statement without hanging (and could before) then I say it is borked. If this is Windows only, that provides a clue.
I am experiencing the same issue since upgrading to 3.6 on windows as well. I have 6-8 reports that open when I open the file and it can be random which one might freeze when clicking on it. To clear up the one question that I saw might still be outstanding, I let mine go for about 2 days (I was away from the computer a bit) and it never came back, so it seems to be a true hang (The CPU also drops to 0). In the latest report I ran, I can confirm with --debug, nothing is added in the trace file that gives anything away. The last section of the trace file is the javascript dump from the report I was trying to switch to. I can also confirm it's after the report has generated as the temp copy of the report is on my system and I can open in a regular web browser. I'll see if I can work on a debugging environment next, though I know it's probably going to be difficult.
Matt Forbis, Unfortunately that means that it's hanging in webkit. Does it hang on text reports (no javascript) or only graphical ones? What version of Windows?
I have not gotten it to hang yet on a text only report. It seems the Line and Bar Charts are the ones that cause the most hangs, the Pie Charts do not seem to do it (or at least I have not seen it). I'm on Windows 10 for my OS.
I've just had it hang repeatedly on open and then fix itself. I was trying to change the start date on a line chart, it hung. Started again / open anyway / hang, repeat 4 or 5 times. Time for some text editing, I thought. Things I had running at the time were Thunderbird and GoogleChrome. I closed Thunderbird to prep for a backup but didn't bother closing GoogleChrome. Tried again one last time before actually starting the backup and ... it worked. The book didn't change between the the repeated hangs and then things working again. I have since opened and closed a few times with the tab for the line chart in place and it is opening and closing just fine. Straws, clasping at: if it is webkit or something else could that be affected by something outside of gnc's direct control? I am struggling with the not working a number of times and then working again without anything obvious changing.
Re: is it only graphs that cause this? I use multi-col reports a lot (e.g. a bal sheet next to P+L). Thought: if the multi-col bit of the report sub-system was using webkit (or whatever) then is it possible words and numbers reports might hang too? The multi-col bit might be using webkit in spite of the fact that the reports it actually gets to display don't include pretty lines or circles. Just a thought as it would explain my letters and numbers reports hanging.
All reports generate html and display it with an embedded WebKitGtkWebView. What's different about graphs is that they're generated with javascript, and WebKit's javascript interpreter operates as a separate thread. One possible explanation of this hang--at least for charts--might be that the connection between the webview thread and the javascript thread is getting borked somehow so that the webview thread never gets the response back from the javascript one. The multicolumn report viewer doesn't itself use any javascript and doesn't do anything special with threading, so the javascript thread hypothesis wouldn't hold.
OK. Thing is javascript doesn't change as much as you suggest, JohnR. Surely this is about how javascript is being used by gnc? i.e. this is a component issue. the original report gives us a near exact work / oops event in time terms. why are dev people relying on occasional reports when they have an event?
Actually it's not about javascript at all, it's about inter-thread communication inside of WebKitGtk. By event you mean that it worked for the OP with the 7 June build and hangs with the 13 June build? Here's the list of changes to reports in that week: 2c04ae310 [trep-engine] allow #:custom-source-accounts kwarg f6bfdabd3 [trep-engine] allow #f for friendly-fn 241f1f927 [test-transaction] add csv test 497e18c36 [trep-engine] allow csv export of grand-totals ca759fb49 [taxtxf] fix copy-n-paste error 59f9b7786 Don't test gnc:html-string-sanitize on emoji if guile doesn't understand them. Nothing to do with charts. trep-engine is the backend for the Transaction Report and taxtxf is the Turbotax export report. There aren't any changes at all in html for that week. That leaves the rather speculative suggestion that the gcc/libc++ upgrade affected webkit somehow. I don't know of a good way to test that, particularly since I can't replicate the problem at all on my Win10 VM.
I think we undid "everyone is a liar except me" a while back, JohnR. Just because you don't have it doesn't mean every other human on earth is a liar. There are a number of solid reports. Be real. Personally I used a bar chart I haven't used for a while earlier today. Got stuck, closed, started, got stuck, started again, it worked. This sequence makes no sense to me as I am not changing anything between the working and not working. Help! Something must have changed for people to be noticing this.
Wm, I'm not calling anyone a liar. It's simply that if I can't reproduce a problem I can't use the debugger to find what's causing it. Sometimes I can work it out and find the bug by reviewing the code, but that's not the case here because I don' know what code to look at. As I said in comment 33, none of the GnuCash changes appear to be relevant. That implies that the change is outside of GnuCash itself, either in a MinGW64 package or in Windows itself, but there's no way to prove it without being able to reproduce the hang and closely examine the state of the system to learn what it's waiting on.
Let's help each other think, please (I am aware I rub people up the wrong way) Have a think about what I say below and add your thoughts. This appears to be Windows specific but not Windows version specific. Reasoning: I've been on Win 8.1 for yonks and the problem shows on other versions of Win. Puzzle: it doesn't happen on JohnR's Win 10 VM and (I've just had a look at the user list) this isn't something the user's are yelling about as far as I can see. The OP noticed a change between minor versions that J thinks unlikely to have caused this, so what else might have caused this? Things to consider: MattF said in #26 === I can also confirm it's after the report has generated as the temp copy of the report is on my system and I can open in a regular web browser === Matt, where were your generated files? [1] The reason I ask is because I couldn't find mine. The places I looked were similar too C:\Users\MyName\AppData\Roaming\GnuCash Guess where they were? C:\Users\MyName\AppData\Local\Temp How fucking stupid are you gnc devs? I warned you about this before! Additional clue: when I try to display a report in C:\Users\MyName\AppData\Local\Temp I sometimes get a warning. Damn, I said OK because I knew it was OK and now I can't get the warning back. [1] I am known to think that gnc has fucked up the placement of stuff in recent times, let's leave that for another day and try to work out what is going on. Why have the gnc devs made such gross errors? Who has guided them? I really don't understand. Seriously, folks, this looks like a gnc own goal :(
Hypothesis: gnc is placing report output in a place it doesn't have permissions for gnc mods HAVE FUCKED UP THE PLACEMENT OF STUFF, this could have been discussed except I get blocked when I try to discuss it, let the shits at the list face know that! Anyway, what I think is happening is that some reports are being written to a place in the Win file system that gnc doesn't have access to after the event. The average user doesn't know where their report's temp file is placed so may not experience any difficulty. JohnR, I suggest, doesn't see the problem because his Win VM allows him access to all areas (I do the same with my VMs). Is it possible this is all down to gnc not having permission to read what it has written?
Wm, I'm not sure I'm following. My reports go in C:\Users\MyName\AppData\Local\Temp and have as long as I can remember. Everything under MyName should be owned by your own user as well. In general you are more likely to have read permissions to an area than write permissions, so without digging into detail on your system to see the permissions on that directory, it seems if you can dump a temporary report to a directory, you can most likely read it as well. (Yes I am aware it's possible to have write only permission, but not too common) While I'm not a core GNuCash developer, I am not sitting back and complaining even though this is impacting me as well. While waiting for John to try to replicate in his setup, I am also in the process of setting up a VM to try to do my own replication and see if I can get a useful stack trace to post as well.
Wm, you must accept that you've lost the argument about where GnuCash puts its configuration and temporary files on Windows in 3.x. They're the locations specified by Microsoft in their design guidelines. Get over it. %USERPROFILE%\AppData\Local\Temp is the Windows specified location for temporary files in Vista and later; before that it was %USERPROFILE%\Local Data\Temp. It would be strange indeed for GnuCash to have write permission to the temporary directory and not read permission on the file that it just wrote. Reports are generated in two steps: They're written in html to a temporary file and then that file is loaded into a GtkWebKitWebView for display. That second step is a weak point, especially on Windows, because WebKit itself is a bit of a monster, the port to Gtk has its own issues besides, the WebKitGtk team stopped supporting Windows at all several years ago with version 2.4.9 (they just released 2.24.3), and last winter MinGW-W64 removed WebKitGtk from their package updates. Maybe the right solution until we can find a substitute for WebKitGtk is to send the html file to the default browser instead.
I can confirm that so far, I have also only seen crashes on non-text reports. Great to see that this issue has already been hashed out in quite some detail.
GnuCash version: Version: 3.6 Build ID: 3.6+(2019-06-29) Finance::Quote: - OS: Windows 10 Enterprise, version 1803 Hi, I'm experiencing the same issue and would like to supplement some of the previous comments with my observations. - GnuCash hangs when a report tab containing graphs is displayed (the tab is visible). I didn't experience hangs if no reports including graphs were in sight. In most cases, the reports are generated successfully at first, but GnuCash hangs at a later stage while they are open. - I can quite reliably reproduce the hang by opening a report that contain graphs and then repeatedly pressing Alt-Tab to switch between GnuCash and another window. Doing this 2-5 times makes it hang. - The log file (generated with the option --debug) ends with the Javascript code that draws the graph. I compared the log at the moment the report is generated (i.e. before the hang) and after the hang, and nothing gets added. Thanks to all who are looking into this issue!
@jralls if this is currently unsolvable, it may be an idea to launch external browser according to global preference? .scm can also check this global preference and avoid creating html anchors if preference is enabled.
@ChristopherL if you point me at the right config file I'd be interested in testing just about anything that returns some stability. If stuff opened in a new, external browser window as was as slow as Trump realising gun controls were needed at least I'd know my db was still stable.
I know JohnR doesn't like me raising this but there are stability issues here. I realised late last night that my C:\Users\abc\AppData\Roaming\GnuCash\books wasn't being updated. gnc was crashing, I was starting it again, it was (I think) grabbing stuff from the registry rather than the .gcm file and this can continue for many hours on a system with good uptime to the extent that tabs recorded in the .gcm file no longer have any relation to those actually being used. Imagine how pissed off I was to discover that the .gcm is written to unreliably. ==== I have long advocated a move to external reporting being improved, perhaps this will be the kick that makes it happen? <-- somewhat rhetorical
Not writing the book's gcm on a crash isn't surprising, that's done as part of a normal session ending, either from shutting down or opening a different file/database. Preferences live in the Registry on Windows, so that's also expected behavior. Now about those crashes: Are they actually crashes or are you killing GnuCash from Task Manager because it's hung up displaying a report?
> Now about those crashes: Are they actually crashes or are you killing GnuCash from Task Manager because it's hung up displaying a report? . The program never crashes in my experience; it's always a permanent hang that requires killing the process, when it gets stuck at the JavaScript that generates the graphic.
CDB-Man, that question was directed at Wm's report of crashing in comment 44.
My response is the same as CBD's stop being a lazy thinker, JohnR
Wm, then why did you say that "gnc was crashing" in comment 44?
because it stops being usable, I have to undo bits that only certain people know about to make it work again seriously, I go into the innards, fix some stuff and then it works again, none of that is official
JohnR I declare you a liar, you know gnc is failing, you can't be arsed to address the actual issues. I call you lazy.
if Christopher's approach is worth testing I say go for it, some relief is needed
(In reply to Paolo from comment #41) > GnuCash version: > Version: 3.6 > Build ID: 3.6+(2019-06-29) > Finance::Quote: - > > OS: Windows 10 Enterprise, version 1803 > > Hi, I'm experiencing the same issue and would like to supplement some of the > previous comments with my observations. > > - GnuCash hangs when a report tab containing graphs is displayed (the tab is > visible). I didn't experience hangs if no reports including graphs were in > sight. In most cases, the reports are generated successfully at first, but > GnuCash hangs at a later stage while they are open. > - I can quite reliably reproduce the hang by opening a report that contain > graphs and then repeatedly pressing Alt-Tab to switch between GnuCash and > another window. Doing this 2-5 times makes it hang. > - The log file (generated with the option --debug) ends with the Javascript > code that draws the graph. I compared the log at the moment the report is > generated (i.e. before the hang) and after the hang, and nothing gets added. > > Thanks to all who are looking into this issue! Build ID: 3.6+(2019-06-29) Finance::Quote: 1.49 OS: Windows 10 Home 1903 Hi, for me the issue is exactly the same. The chance to get a hang / infinite loop seems higher when there is a complex report (a lot of series / data points) or when creating multiple reports after each other.
(In reply to Philipp Krebs from comment #53) > Hi, for me the issue is exactly the same. The chance to get a hang / > infinite loop seems higher when there is a complex report (a lot of series / > data points) or when creating multiple reports after each other. That suggests something running out of something. Data point which I don't think has been mentioned before: I tried using Edit / Pref / Reports / New window ON for 3 or 4 days and it made no diff.
Hi, just to add that I'm also getting this issue (since the latest release) and its definitely with the reports that have some form of graphics. On a test just now, it crashed immediately when I even just tried to open a new Expense Chart report via the menubar. Also checked and 0% CPU usage during the hang. Windows 10 Pro 1903 Build ID: 3.6+(2019-06-29)
Windows build isn't significant, it may be worth reporting in a sad sigh sort of way. It is hard to think of anything other than a badly chosen component being responsible for this. ChristopherL offered a way out but has provided no details. I am more than ready for a test, C. or anyone else that can provide some relief.
I was able to get a stack trace through GDB that looks similiar to Simon's above. Does this mean the next step would be try to compile webkit on windows instead of using mingw's prebuild package to see if I can get debugging symbols? This doesn't seem to offer much more insight than the other one: (gdb) bt full #0 0x77486c04 in ntdll!KiFastSystemCallRet () from C:\Windows\SYSTEM32\ntdll.dll No symbol table info available. #1 0x7748658c in ntdll!ZwWaitForMultipleObjects () from C:\Windows\SYSTEM32\ntdll.dll No symbol table info available. #2 0x75486a8e in KERNELBASE!InterlockedCompareExchange () from C:\Windows\system32\KernelBase.dll No symbol table info available. #3 0x00000002 in ?? () No symbol table info available. #4 0x0022e8c8 in ?? () No symbol table info available. #5 0x7574bf46 in WaitForMultipleObjectsEx () from C:\Windows\system32\kernel32.dll No symbol table info available. #6 0x7574bfb4 in WaitForMultipleObjects () from C:\Windows\system32\kernel32.dll No symbol table info available. #7 0x64b42cc1 in ?? () from C:\gcdev64\msys2\mingw32\bin\libwinpthread-1.dll No symbol table info available. #8 0x64b41f9b in ?? () from C:\gcdev64\msys2\mingw32\bin\libwinpthread-1.dll No symbol table info available. #9 0x64b4226d in ?? () from C:\gcdev64\msys2\mingw32\bin\libwinpthread-1.dll No symbol table info available. #10 0x64b42738 in ?? () from C:\gcdev64\msys2\mingw32\bin\libwinpthread-1.dll No symbol table info available. #11 0x697d60a5 in ?? () from C:\gcdev64\gnucash\maint\inst\bin\libstdc++-6.dll No symbol table info available. #12 0x053d5599 in ?? () from C:\gcdev64\msys2\mingw32\bin\libjavascriptcoregtk-3 .0-0.dll No symbol table info available. #13 0x053d7780 in ?? () from C:\gcdev64\msys2\mingw32\bin\libjavascriptcoregtk-3 .0-0.dll No symbol table info available. #14 0x053d974d in ?? () from C:\gcdev64\msys2\mingw32\bin\libjavascriptcoregtk-3 .0-0.dll No symbol table info available. #15 0x053da14b in ?? () from C:\gcdev64\msys2\mingw32\bin\libjavascriptcoregtk-3 .0-0.dll No symbol table info available. #16 0x053da1de in ?? () from C:\gcdev64\msys2\mingw32\bin\libjavascriptcoregtk-3 .0-0.dll No symbol table info available. #17 0x03c9c277 in ?? () from C:\gcdev64\msys2\mingw32\bin\libwebkitgtk-3.0-0.dll No symbol table info available. #18 0x03c9c4c5 in ?? () from C:\gcdev64\msys2\mingw32\bin\libwebkitgtk-3.0-0.dll No symbol table info available. #19 0x03c63a58 in ?? () from C:\gcdev64\msys2\mingw32\bin\libwebkitgtk-3.0-0.dll No symbol table info available. #20 0x0416e227 in ?? () from C:\gcdev64\msys2\mingw32\bin\libwebkitgtk-3.0-0.dll No symbol table info available. #21 0x13f038ef in ?? () No symbol table info available. #22 0x283304fa in ?? () No symbol table info available. #23 0x28329aa3 in ?? () No symbol table info available. #24 0x283291d1 in ?? () No symbol table info available. #25 0x26c1b096 in ?? () No symbol table info available. #26 0x26c1300f in ?? () No symbol table info available. #27 0x26c1a9ee in ?? () No symbol table info available. #28 0x26c19fbe in ?? () No symbol table info available. #29 0x26c0d3ba in ?? () No symbol table info available. #30 0x0545312b in ?? () from C:\gcdev64\msys2\mingw32\bin\libjavascriptcoregtk-3 .0-0.dll No symbol table info available. #31 0x05421599 in ?? () from C:\gcdev64\msys2\mingw32\bin\libjavascriptcoregtk-3 .0-0.dll No symbol table info available. Backtrace stopped: previous frame inner to this frame (corrupt stack?)
It's worth a try. The least painful way is to clone https://github.com/msys2/MINGW-packages, checkout b1f7ddb5 (the one before they dropped webkitgtk) and use pkgbuild, see https://github.com/msys2/msys2/wiki/Creating-packages. Edit mingw-w64-webkitgtk/PKGBUILD, changing "!debug" to "debug" on line 12 and change the configure options --enable-debug and --enable-debug-symbols to "yes". It may turn out that simply rebuilding with the current compiler will fix the problem. Good luck and be patient. WebKit isn't easy to build and takes a really long time. I'm not at all surprised that Alex decided to stop building it.
A user just reported bug 797385. He found repeatable webkit error: 23:42:05 ERROR <gnc.html> [webkit_resource_load_error()] WebKit load of resource file:///C:/Users/Windows10User/AppData/Local/Temp/gnc-report-WNEB7Z.html, type (NULL), failed due to Frame load was interrupted Apparently in his case the result is just a blank tab rather than a hang, but I wonder if any of you might have similar errors in tracefiles.
I do not get any entries like that in my trace file when the reports hang. On another note, an update on rebuilding webkit. I think I'm going to have to redo my VM to have a 64 bit version of windows as make has trouble with the last ld to assemble the final library because of running out of memory, so it doesn't look like webkit can build a version with debugging symbols on a 32 bit version of windows. It might be a few more weeks before I can get a full new VM setup and running.
I'm experiencing a very similar crash on Win10 1903 (natively, no VM) running Gnucash 3.6 (3.6+, 2019-06-29 build). For me, it's slightly different in that reports will render fine, but if I try to edit the data within a report, as soon as I hit reply there's a hang. I doubt it's related to large files or long rendering, as if I do an Expense Chart, it renders super quick, and then if I change it to only use a subset of that data, it immediately hangs. Oddly enough, if I run with the --debug --extra flags, the report won't render in the first place, and it hangs immediately upon attempting to render. It's super-reproducible for me, but it may or may not be the exact bug that's open here. I'm happy to toss my log files somewhere if it would help.
Sorry, hang, not crash. I said crash in the first line, but I meant hang.
What do you mean "edit the data within a report" and where are you "hitting reply"? The reports are html displayed in an embedded browser window, they're not editable.
Wow, my typing and explaining skills are failing, apologies. When I say "edit the data within the report" I actually mean editing the parameters of the report, like selecting new accounts to pull transactions from into the Expense Chart report. So the Report Options window (after you hit the Options button). And "reply" was a typo for "apply" in that Window. Also, I had tried a fresh install of 3.6 which didn't resolve the issue, but a fresh install of 3.5 does resolve the issue, so I can also confirm it doesn't exist in past builds. But since it's quite reproducible for me I'm happy to install 3.6 to grab trace files or troubleshoot, but in looking through the trace files generated myself I didn't see anything that looked much like useful error information.
Got it. You could try for a stack trace of the hang using gdb, but it's not likely to tell us much. You might look in the Details tab of Task Manager to see if there are any webkit or javascript processes marked "running" with 0% CPU usage. The other thing you could do is try installing https://code.gnucash.org/builds/win32/maint/gnucash-3.5-2019-06-13-git-3.5-277-gca759fb49+.setup.exe and https://code.gnucash.org/builds/win32/maint/gnucash-3.5-2019-06-07-git-3.5-268-g520f350a9+.setup.exe. If it's the same problem as originally reported it should hang with the first and work OK with the second.
I just did some more testing, here are the results: As expected, the issue exists in 2019-06-13 and not in 2019-06-07. I grabbed a trace file in 2019-06-13, and it's up on PasteBin here (minus redacting some of my own data): https://pastebin.com/Y9XdvYJN I tried getting a track trace using gdb, but I got stuck when the process hung but didn't crash. I manually killed it using Task Manager, but then gdb just said that the process exited, and the bt command gave "No stack". Happy to go down that route further if someone can point me to instructions on how to handle a freeze as opposed to a crash. Also, I can't see any webkit or javascript processes in my task manager Details tab during the hang.
GDB in windows doesn't know how to handle control-c, so you have to run GnuCash from the Start menu and get it to hang, then start gdb and use the attach command with the PID from the Task Manager Details page. e.g if gnucash's PID is 4242 you'd enter attach 4242 at the gdb prompt. After it does that and returns the prompt you can say "bt" to get the backtrace on the current thread and "threads" to get a list of open threads.
Thanks for the explanation! Here's the info: When I attach, it lists out the threads, not sure if that's helpful or not, but in case it is, here they are: (gdb) attach 14948 Attaching to process 14948 [New Thread 14948.0xcfc] [New Thread 14948.0x8ec] [New Thread 14948.0x1d30] [New Thread 14948.0x1118] [New Thread 14948.0x228] [New Thread 14948.0x2a58] [New Thread 14948.0x2208] [New Thread 14948.0x1b2c] [New Thread 14948.0x3a90] [New Thread 14948.0x3808] [New Thread 14948.0x1cb0] [New Thread 14948.0xd10] [New Thread 14948.0x1fac] [New Thread 14948.0x2268] [New Thread 14948.0x3858] [New Thread 14948.0x3a74] [New Thread 14948.0x3448] [New Thread 14948.0x18e0] [New Thread 14948.0x25c8] [New Thread 14948.0x1950] [New Thread 14948.0x35b0] [New Thread 14948.0x3b5c] [New Thread 14948.0x1e44] [New Thread 14948.0x1424] [New Thread 14948.0x2f2c] [New Thread 14948.0xbf4] [New Thread 14948.0x2608] [New Thread 14948.0x2140] [New Thread 14948.0x2bf0] [New Thread 14948.0x273c] Reading symbols from C:\Program Files (x86)\gnucash\bin\gnucash.exe...done. Then doing the bt gives me: (gdb) bt #0 0x77384061 in ntdll!DbgBreakPoint () from C:\WINDOWS\SYSTEM32\ntdll.dll #1 0x773bac19 in ntdll!DbgUiRemoteBreakin () from C:\WINDOWS\SYSTEM32\ntdll.dll #2 0x363d2fd0 in ?? () #3 0x773babe0 in ntdll!DbgUiIssueRemoteBreakin () from C:\WINDOWS\SYSTEM32\ntdll.dll #4 0x76a96359 in KERNEL32!BaseThreadInitThunk () from C:\WINDOWS\System32\kernel32.dll #5 0x77377b74 in ntdll!RtlGetAppContainerNamedObjectPath () from C:\WINDOWS\SYSTEM32\ntdll.dll #6 0x77377b44 in ntdll!RtlGetAppContainerNamedObjectPath () from C:\WINDOWS\SYSTEM32\ntdll.dll #7 0x00000000 in ?? () I looked into the GnuCash documentation on providing better stack dumps, but the site that hosts the pd and mmp files isn't there any more, and a google didn't reveal a common source. Just typing "threads" gives me an undefined command, but "info threads" gives the following: (gdb) info threads Id Target Id Frame * 30 Thread 14948.0x273c 0x77384061 in ntdll!DbgBreakPoint () from C:\WINDOWS\SYSTEM32\ntdll.dll 29 Thread 14948.0x2bf0 0x7738232c in ntdll!ZwWaitForMultipleObjects () from C:\WINDOWS\SYSTEM32\ntdll.dll 28 Thread 14948.0x2140 0x7738232c in ntdll!ZwWaitForMultipleObjects () from C:\WINDOWS\SYSTEM32\ntdll.dll 27 Thread 14948.0x2608 0x7738232c in ntdll!ZwWaitForMultipleObjects () from C:\WINDOWS\SYSTEM32\ntdll.dll 26 Thread 14948.0xbf4 0x7738232c in ntdll!ZwWaitForMultipleObjects () from C:\WINDOWS\SYSTEM32\ntdll.dll 25 Thread 14948.0x2f2c 0x7738232c in ntdll!ZwWaitForMultipleObjects () from C:\WINDOWS\SYSTEM32\ntdll.dll 24 Thread 14948.0x1424 0x7738232c in ntdll!ZwWaitForMultipleObjects () from C:\WINDOWS\SYSTEM32\ntdll.dll 23 Thread 14948.0x1e44 0x7738232c in ntdll!ZwWaitForMultipleObjects () from C:\WINDOWS\SYSTEM32\ntdll.dll 22 Thread 14948.0x3b5c 0x7738232c in ntdll!ZwWaitForMultipleObjects () from C:\WINDOWS\SYSTEM32\ntdll.dll 21 Thread 14948.0x35b0 0x77381d9c in ntdll!ZwWaitForSingleObject () from C:\WINDOWS\SYSTEM32\ntdll.dll 20 Thread 14948.0x1950 0x77381dbc in ntdll!ZwReadFile () from C:\WINDOWS\SYSTEM32\ntdll.dll 19 Thread 14948.0x25c8 0x77381d9c in ntdll!ZwWaitForSingleObject () from C:\WINDOWS\SYSTEM32\ntdll.dll 18 Thread 14948.0x18e0 0x77381d9c in ntdll!ZwWaitForSingleObject () from C:\WINDOWS\SYSTEM32\ntdll.dll 17 Thread 14948.0x3448 0x77381d9c in ntdll!ZwWaitForSingleObject () from C:\WINDOWS\SYSTEM32\ntdll.dll 16 Thread 14948.0x3a74 0x77381d9c in ntdll!ZwWaitForSingleObject () from C:\WINDOWS\SYSTEM32\ntdll.dll 15 Thread 14948.0x3858 0x77381d9c in ntdll!ZwWaitForSingleObject () from C:\WINDOWS\SYSTEM32\ntdll.dll 14 Thread 14948.0x2268 0x77381d9c in ntdll!ZwWaitForSingleObject () from C:\WINDOWS\SYSTEM32\ntdll.dll 13 Thread 14948.0x1fac 0x77381d9c in ntdll!ZwWaitForSingleObject () from C:\WINDOWS\SYSTEM32\ntdll.dll 12 Thread 14948.0xd10 0x77381d9c in ntdll!ZwWaitForSingleObject () from C:\WINDOWS\SYSTEM32\ntdll.dll 11 Thread 14948.0x1cb0 0x77381d9c in ntdll!ZwWaitForSingleObject () from C:\WINDOWS\SYSTEM32\ntdll.dll 10 Thread 14948.0x3808 0x77381d9c in ntdll!ZwWaitForSingleObject () from C:\WINDOWS\SYSTEM32\ntdll.dll 9 Thread 14948.0x3a90 0x77381d9c in ntdll!ZwWaitForSingleObject () from C:\WINDOWS\SYSTEM32\ntdll.dll 8 Thread 14948.0x1b2c 0x7738232c in ntdll!ZwWaitForMultipleObjects () from C:\WINDOWS\SYSTEM32\ntdll.dll 7 Thread 14948.0x2208 0x76a6708c in win32u!NtUserMsgWaitForMultipleObjectsEx () from C:\WINDOWS\System32\win32u.dll 6 Thread 14948.0x2a58 0x77383a4c in ntdll!ZwWaitForWorkViaWorkerFactory () from C:\WINDOWS\SYSTEM32\ntdll.dll 5 Thread 14948.0x228 0x77383a4c in ntdll!ZwWaitForWorkViaWorkerFactory () from C:\WINDOWS\SYSTEM32\ntdll.dll 4 Thread 14948.0x1118 0x77383a4c in ntdll!ZwWaitForWorkViaWorkerFactory () from C:\WINDOWS\SYSTEM32\ntdll.dll 3 Thread 14948.0x1d30 0x77383a4c in ntdll!ZwWaitForWorkViaWorkerFactory () from C:\WINDOWS\SYSTEM32\ntdll.dll 2 Thread 14948.0x8ec 0x77383a4c in ntdll!ZwWaitForWorkViaWorkerFactory () from C:\WINDOWS\SYSTEM32\ntdll.dll 1 Thread 14948.0xcfc 0x7738232c in ntdll!ZwWaitForMultipleObjects () from C:\WINDOWS\SYSTEM32\ntdll.dll Let me know if you think anything else I can provide would be useful, and thanks for the help so far.
Wow, that's a lot of blocked threads. I wonder what file thread 20 is trying to read.
I took a look in Process Explorer and Resource Monitor, but it wasn't obvious what file is being accessed there. There are some interesting handles open: Type Name ALPC Port \BaseNamedObjects\[CoreUI]-PID(14200)-TID(12712) 9ce6fab5-4c50-433f-ab27-4e41fc0aab83 Section \BaseNamedObjects\__ComCatalogCache__ Section \BaseNamedObjects\__ComCatalogCache__ Section \BaseNamedObjects\windows_shell_global_counters Desktop \Default File \Device\CNG File \Device\DeviceApi File \Device\KsecDD File \Device\KsecDD File \Device\NamedPipe\ File \Device\Nsi Event \KernelObjects\MaximumCommitCondition Directory \KnownDlls Directory \KnownDlls32 Directory \KnownDlls32 Directory \Sessions\1\BaseNamedObjects Mutant \Sessions\1\BaseNamedObjects\SM0:14200:168:WilStaging_02 Semaphore \Sessions\1\BaseNamedObjects\SM0:14200:168:WilStaging_02_p0 Mutant \Sessions\1\BaseNamedObjects\SM0:14200:64:WilError_02 Semaphore \Sessions\1\BaseNamedObjects\SM0:14200:64:WilError_02_p0 Section \Sessions\1\BaseNamedObjects\windows_shell_global_counters Section \Sessions\1\Windows\Theme166202071 WindowStation \Sessions\1\Windows\WindowStations\WinSta0 WindowStation \Sessions\1\Windows\WindowStations\WinSta0 Section \Windows\Theme535876713 File C:\Users\mghwa\AppData\Local\Microsoft\Windows\INetCache\webkit\icondatabase\WebpageIcons.db File C:\Users\mghwa\AppData\Local\Temp\gnucash.trace.1RFP7Z.log File C:\Users\mghwa\AppData\Local\Temp\gnucash.trace.1RFP7Z.log File C:\Users\mghwa\OneDrive\Desktop File C:\Windows File C:\Windows\Fonts\segoeui.ttf File C:\Windows\Fonts\StaticCache.dat File C:\Windows\Fonts\trebuc.ttf File C:\Windows\Fonts\trebucbd.ttf File C:\Windows\System32\en-US\KernelBase.dll.mui File C:\Windows\WinSxS\x86_microsoft.windows.common-controls_6595b64144ccf1df_5.82.18362.329_none_71d1f3d35ae8ae19 File C:\Windows\WinSxS\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.18362.329_none_2e74e79e27889be4 File C:\Windows\WinSxS\x86_microsoft.windows.gdiplus_6595b64144ccf1df_1.1.18362.329_none_5f5fda83821b15b2 File F:\Google Drive\Finances\GnuCash\Money.gnucash.20190909173449.log Thread gnucash.exe(14200): 10880 Thread gnucash.exe(14200): 10888 Thread gnucash.exe(14200): 10908
I can confirm having a single thread in ZwReadFile. I managed to use gdbgui (because I'm a lazy dev) to get the following trace for that thread (also, please note, I have no files in 'C:/gcdev64/' - that's not my path): Thread 20544.0x3f1c, id 13, stopped func file addr args ntdll!ZwReadFile 0x77221cdc ReadFile 0x756510ec read 0x7659c34d ?? 0x58c ?? 0xfb2fb84 read 0x7659c07a ?? 0x7 ?? 0xfb2fb84 read_finalization_pipe_data C:/gcdev64/gnucash/releases/src/guile-2.2.4.68-65d98/libguile/finalizers.c:199 0x6e79e8b1 GC_do_blocking_inner C:/gcdev64/gnucash/releases/src/bdwgc/win32_threads.c:878 0x70bd312e GC_with_callee_saves_pushed C:/gcdev64/gnucash/releases/src/bdwgc/mach_dep.c:303 0x70bc86fa GC_do_blocking C:/gcdev64/gnucash/releases/src/bdwgc/misc.c:2041 0x70bcdb17 scm_without_guile C:/gcdev64/gnucash/releases/src/guile-2.2.4.68-65d98/libguile/threads.c:722 0x6e804546 finalization_thread_proc C:/gcdev64/gnucash/releases/src/guile-2.2.4.68-65d98/libguile/finalizers.c:212 0x6e79e968 c_body C:/gcdev64/gnucash/releases/src/guile-2.2.4.68-65d98/libguile/continuations.c:422 0x6e790540 vm_regular_engine C:/gcdev64/gnucash/releases/src/guile-2.2.4.68-65d98/libguile/vm-engine.c:786 0x6e8140f8 scm_call_n C:/gcdev64/gnucash/releases/src/guile-2.2.4.68-65d98/libguile/vm.c:1260 0x6e8171ee scm_call_0 C:/gcdev64/gnucash/releases/src/guile-2.2.4.68-65d98/libguile/eval.c:479 0x6e795a3f catch C:/gcdev64/gnucash/releases/src/guile-2.2.4.68-65d98/libguile/throw.c:137 0x6e805051 scm_catch_with_pre_unwind_handler C:/gcdev64/gnucash/releases/src/guile-2.2.4.68-65d98/libguile/throw.c:377 0x6e805380 scm_c_catch C:/gcdev64/gnucash/releases/src/guile-2.2.4.68-65d98/libguile/throw.c:377 0x6e805380 scm_i_with_continuation_barrier C:/gcdev64/gnucash/releases/src/guile-2.2.4.68-65d98/libguile/continuations.c:360 0x6e790a95 scm_c_with_continuation_barrier C:/gcdev64/gnucash/releases/src/guile-2.2.4.68-65d98/libguile/continuations.c:456 0x6e790b34 with_guile C:/gcdev64/gnucash/releases/src/guile-2.2.4.68-65d98/libguile/threads.c:661 0x6e803ba5 GC_call_with_stack_base C:/gcdev64/gnucash/releases/src/bdwgc/misc.c:1935 0x70bcdadc scm_i_with_guile C:/gcdev64/gnucash/releases/src/guile-2.2.4.68-65d98/libguile/threads.c:704 0x6e8044f0 scm_with_guile C:/gcdev64/gnucash/releases/src/guile-2.2.4.68-65d98/libguile/threads.c:710 0x6e8044f0 run_finalization_thread C:/gcdev64/gnucash/releases/src/guile-2.2.4.68-65d98/libguile/finalizers.c:236 0x6e79e887 ?? 0x64b44ea1 msvcrt!_beginthreadex 0x765b6d5f msvcrt!_endthreadex 0x765b6e21 KERNEL32!BaseThreadInitThunk 0x74b86359 ntdll!RtlGetAppContainerNamedObjectPath 0x77217a94 ntdll!RtlGetAppContainerNamedObjectPath 0x77217a64 ?? 0x0
> also, please note, I have no files in 'C:/gcdev64/' - that's not my path): Right. It's the default root of the windows build system. Interesting, a guile thread and it looks like it's hung up trying to shut down. If you're so inclined there might be other clues in the backtraces of the other threads. Is gdbgui less of a pain in the butt than running gdb in a terminal window in Windows? In particular does it let you interrupt and then interact with a running process (some equivalent of control-c that doesn't work in a terminal)?
I was being lazy with gdbgui because I can't always remember the magic incantations for real CLI GDB. However, since I know how to run "thread apply all bt", please find below the entire bt for all threads. == Thread 17 (Thread 8416.0x5968): #0 0x77223f81 in ntdll!DbgBreakPoint () from C:\WINDOWS\SYSTEM32\ntdll.dll #1 0x7725aba9 in ntdll!DbgUiRemoteBreakin () from C:\WINDOWS\SYSTEM32\ntdll.dll #2 0xcf556960 in ?? () #3 0x7725ab70 in ntdll!DbgUiIssueRemoteBreakin () from C:\WINDOWS\SYSTEM32\ntdll.dll #4 0x74b86359 in KERNEL32!BaseThreadInitThunk () from C:\WINDOWS\System32\kernel32.dll #5 0x77217a94 in ntdll!RtlGetAppContainerNamedObjectPath () from C:\WINDOWS\SYSTEM32\ntdll.dll #6 0x77217a64 in ntdll!RtlGetAppContainerNamedObjectPath () from C:\WINDOWS\SYSTEM32\ntdll.dll #7 0x00000000 in ?? () Thread 16 (Thread 8416.0x58f8): #0 0x7722396c in ntdll!ZwWaitForWorkViaWorkerFactory () from C:\WINDOWS\SYSTEM32\ntdll.dll #1 0x772066df in ntdll!TpCallbackIndependent () from C:\WINDOWS\SYSTEM32\ntdll.dll #2 0x74b86359 in KERNEL32!BaseThreadInitThunk () from C:\WINDOWS\System32\kernel32.dll #3 0x77217a94 in ntdll!RtlGetAppContainerNamedObjectPath () from C:\WINDOWS\SYSTEM32\ntdll.dll #4 0x77217a64 in ntdll!RtlGetAppContainerNamedObjectPath () from C:\WINDOWS\SYSTEM32\ntdll.dll #5 0x00000000 in ?? () Thread 15 (Thread 8416.0x1a94): #0 0x7722396c in ntdll!ZwWaitForWorkViaWorkerFactory () from C:\WINDOWS\SYSTEM32\ntdll.dll #1 0x772066df in ntdll!TpCallbackIndependent () from C:\WINDOWS\SYSTEM32\ntdll.dll #2 0x74b86359 in KERNEL32!BaseThreadInitThunk () from C:\WINDOWS\System32\kernel32.dll #3 0x77217a94 in ntdll!RtlGetAppContainerNamedObjectPath () from C:\WINDOWS\SYSTEM32\ntdll.dll #4 0x77217a64 in ntdll!RtlGetAppContainerNamedObjectPath () from C:\WINDOWS\SYSTEM32\ntdll.dll #5 0x00000000 in ?? () Thread 14 (Thread 8416.0x2e1c): #0 0x7722224c in ntdll!ZwWaitForMultipleObjects () from C:\WINDOWS\SYSTEM32\ntdll.dll #1 0x7566b923 in WaitForMultipleObjectsEx () from C:\WINDOWS\System32\KernelBase.dll #2 0x64c01787 in ?? () from C:\Program Files (x86)\gnucash\bin\libglib-2.0-0.dll #3 0x64c01923 in ?? () from C:\Program Files (x86)\gnucash\bin\libglib-2.0-0.dll #4 0x64c01e53 in ?? () from C:\Program Files (x86)\gnucash\bin\libglib-2.0-0.dll #5 0x64bf3d97 in ?? () from C:\Program Files (x86)\gnucash\bin\libglib-2.0-0.dll #6 0x64bf403a in ?? () from C:\Program Files (x86)\gnucash\bin\libglib-2.0-0.dll #7 0x64bf4078 in ?? () from C:\Program Files (x86)\gnucash\bin\libglib-2.0-0.dll #8 0x64c1b2d5 in ?? () from C:\Program Files (x86)\gnucash\bin\libglib-2.0-0.dll #9 0x64b44ea1 in ?? () from C:\Program Files (x86)\gnucash\bin\libwinpthread-1.dll #10 0x765b6d5f in msvcrt!_beginthreadex () from C:\WINDOWS\System32\msvcrt.dll #11 0x765b6e21 in msvcrt!_endthreadex () from C:\WINDOWS\System32\msvcrt.dll #12 0x74b86359 in KERNEL32!BaseThreadInitThunk () from C:\WINDOWS\System32\kernel32.dll #13 0x77217a94 in ntdll!RtlGetAppContainerNamedObjectPath () from C:\WINDOWS\SYSTEM32\ntdll.dll #14 0x77217a64 in ntdll!RtlGetAppContainerNamedObjectPath () from C:\WINDOWS\SYSTEM32\ntdll.dll #15 0x00000000 in ?? () Thread 13 (Thread 8416.0x54cc): #0 0x7722224c in ntdll!ZwWaitForMultipleObjects () from C:\WINDOWS\SYSTEM32\ntdll.dll #1 0x7566b923 in WaitForMultipleObjectsEx () from C:\WINDOWS\System32\KernelBase.dll #2 0x7566b7d8 in WaitForMultipleObjects () from C:\WINDOWS\System32\KernelBase.dll #3 0x64b42e41 in ?? () from C:\Program Files (x86)\gnucash\bin\libwinpthread-1.dll #4 0x64b42030 in ?? () from C:\Program Files (x86)\gnucash\bin\libwinpthread-1.dll #5 0x64b4236d in ?? () from C:\Program Files (x86)\gnucash\bin\libwinpthread-1.dll #6 0x64b4288c in ?? () from C:\Program Files (x86)\gnucash\bin\libwinpthread-1.dll #7 0x6feeed15 in ?? () from C:\Program Files (x86)\gnucash\bin\libstdc++-6.dll #8 0x07085552 in ?? () from C:\Program Files (x86)\gnucash\bin\libjavascriptcoregtk-3.0-0.dll #9 0x07086d7f in ?? () from C:\Program Files (x86)\gnucash\bin\libjavascriptcoregtk-3.0-0.dll #10 0x0722aecc in ?? () from C:\Program Files (x86)\gnucash\bin\libjavascriptcoregtk-3.0-0.dll #11 0x765b6d5f in msvcrt!_beginthreadex () from C:\WINDOWS\System32\msvcrt.dll #12 0x765b6e21 in msvcrt!_endthreadex () from C:\WINDOWS\System32\msvcrt.dll #13 0x74b86359 in KERNEL32!BaseThreadInitThunk () from C:\WINDOWS\System32\kernel32.dll #14 0x77217a94 in ntdll!RtlGetAppContainerNamedObjectPath () from C:\WINDOWS\SYSTEM32\ntdll.dll #15 0x77217a64 in ntdll!RtlGetAppContainerNamedObjectPath () from C:\WINDOWS\SYSTEM32\ntdll.dll #16 0x00000000 in ?? () Thread 12 (Thread 8416.0x52a4): #0 0x7722224c in ntdll!ZwWaitForMultipleObjects () from C:\WINDOWS\SYSTEM32\ntdll.dll #1 0x7566b923 in WaitForMultipleObjectsEx () from C:\WINDOWS\System32\KernelBase.dll #2 0x7566b7d8 in WaitForMultipleObjects () from C:\WINDOWS\System32\KernelBase.dll #3 0x64b42e41 in ?? () from C:\Program Files (x86)\gnucash\bin\libwinpthread-1.dll #4 0x64b42030 in ?? () from C:\Program Files (x86)\gnucash\bin\libwinpthread-1.dll #5 0x64b4236d in ?? () from C:\Program Files (x86)\gnucash\bin\libwinpthread-1.dll #6 0x64b4288c in ?? () from C:\Program Files (x86)\gnucash\bin\libwinpthread-1.dll #7 0x6feeed15 in ?? () from C:\Program Files (x86)\gnucash\bin\libstdc++-6.dll #8 0x07085552 in ?? () from C:\Program Files (x86)\gnucash\bin\libjavascriptcoregtk-3.0-0.dll #9 0x07086d7f in ?? () from C:\Program Files (x86)\gnucash\bin\libjavascriptcoregtk-3.0-0.dll #10 0x0722aecc in ?? () from C:\Program Files (x86)\gnucash\bin\libjavascriptcoregtk-3.0-0.dll #11 0x765b6d5f in msvcrt!_beginthreadex () from C:\WINDOWS\System32\msvcrt.dll #12 0x765b6e21 in msvcrt!_endthreadex () from C:\WINDOWS\System32\msvcrt.dll #13 0x74b86359 in KERNEL32!BaseThreadInitThunk () from C:\WINDOWS\System32\kernel32.dll #14 0x77217a94 in ntdll!RtlGetAppContainerNamedObjectPath () from C:\WINDOWS\SYSTEM32\ntdll.dll #15 0x77217a64 in ntdll!RtlGetAppContainerNamedObjectPath () from C:\WINDOWS\SYSTEM32\ntdll.dll #16 0x00000000 in ?? () Thread 11 (Thread 8416.0x5ae4): #0 0x7722224c in ntdll!ZwWaitForMultipleObjects () from C:\WINDOWS\SYSTEM32\ntdll.dll #1 0x7566b923 in WaitForMultipleObjectsEx () from C:\WINDOWS\System32\KernelBase.dll #2 0x7566b7d8 in WaitForMultipleObjects () from C:\WINDOWS\System32\KernelBase.dll #3 0x64b42e41 in ?? () from C:\Program Files (x86)\gnucash\bin\libwinpthread-1.dll #4 0x64b42030 in ?? () from C:\Program Files (x86)\gnucash\bin\libwinpthread-1.dll #5 0x64b4236d in ?? () from C:\Program Files (x86)\gnucash\bin\libwinpthread-1.dll #6 0x64b4288c in ?? () from C:\Program Files (x86)\gnucash\bin\libwinpthread-1.dll #7 0x6feeed15 in ?? () from C:\Program Files (x86)\gnucash\bin\libstdc++-6.dll #8 0x07085552 in ?? () from C:\Program Files (x86)\gnucash\bin\libjavascriptcoregtk-3.0-0.dll #9 0x07086d7f in ?? () from C:\Program Files (x86)\gnucash\bin\libjavascriptcoregtk-3.0-0.dll #10 0x0722aecc in ?? () from C:\Program Files (x86)\gnucash\bin\libjavascriptcoregtk-3.0-0.dll #11 0x765b6d5f in msvcrt!_beginthreadex () from C:\WINDOWS\System32\msvcrt.dll #12 0x765b6e21 in msvcrt!_endthreadex () from C:\WINDOWS\System32\msvcrt.dll #13 0x74b86359 in KERNEL32!BaseThreadInitThunk () from C:\WINDOWS\System32\kernel32.dll #14 0x77217a94 in ntdll!RtlGetAppContainerNamedObjectPath () from C:\WINDOWS\SYSTEM32\ntdll.dll #15 0x77217a64 in ntdll!RtlGetAppContainerNamedObjectPath () from C:\WINDOWS\SYSTEM32\ntdll.dll #16 0x00000000 in ?? () Thread 10 (Thread 8416.0x428): #0 0x7722224c in ntdll!ZwWaitForMultipleObjects () from C:\WINDOWS\SYSTEM32\ntdll.dll #1 0x7566b923 in WaitForMultipleObjectsEx () from C:\WINDOWS\System32\KernelBase.dll #2 0x7566b7d8 in WaitForMultipleObjects () from C:\WINDOWS\System32\KernelBase.dll #3 0x64b42e41 in ?? () from C:\Program Files (x86)\gnucash\bin\libwinpthread-1.dll #4 0x64b42030 in ?? () from C:\Program Files (x86)\gnucash\bin\libwinpthread-1.dll #5 0x64b4236d in ?? () from C:\Program Files (x86)\gnucash\bin\libwinpthread-1.dll #6 0x64b4288c in ?? () from C:\Program Files (x86)\gnucash\bin\libwinpthread-1.dll #7 0x6feeed15 in ?? () from C:\Program Files (x86)\gnucash\bin\libstdc++-6.dll #8 0x07085e2b in ?? () from C:\Program Files (x86)\gnucash\bin\libjavascriptcoregtk-3.0-0.dll #9 0x0722aecc in ?? () from C:\Program Files (x86)\gnucash\bin\libjavascriptcoregtk-3.0-0.dll #10 0x765b6d5f in msvcrt!_beginthreadex () from C:\WINDOWS\System32\msvcrt.dll #11 0x765b6e21 in msvcrt!_endthreadex () from C:\WINDOWS\System32\msvcrt.dll #12 0x74b86359 in KERNEL32!BaseThreadInitThunk () from C:\WINDOWS\System32\kernel32.dll #13 0x77217a94 in ntdll!RtlGetAppContainerNamedObjectPath () from C:\WINDOWS\SYSTEM32\ntdll.dll #14 0x77217a64 in ntdll!RtlGetAppContainerNamedObjectPath () from C:\WINDOWS\SYSTEM32\ntdll.dll #15 0x00000000 in ?? () Thread 9 (Thread 8416.0x5974): #0 0x77221cbc in ntdll!ZwWaitForSingleObject () from C:\WINDOWS\SYSTEM32\ntdll.dll #1 0x7565e159 in WaitForSingleObjectEx () from C:\WINDOWS\System32\KernelBase.dll #2 0x7565e0b2 in WaitForSingleObject () from C:\WINDOWS\System32\KernelBase.dll #3 0x0722b3ab in ?? () from C:\Program Files (x86)\gnucash\bin\libjavascriptcoregtk-3.0-0.dll #4 0x0722b737 in ?? () from C:\Program Files (x86)\gnucash\bin\libjavascriptcoregtk-3.0-0.dll #5 0x03d4926a in ?? () from C:\Program Files (x86)\gnucash\bin\libwebkitgtk-3.0-0.dll #6 0x03d4a7a4 in ?? () from C:\Program Files (x86)\gnucash\bin\libwebkitgtk-3.0-0.dll #7 0x0722aecc in ?? () from C:\Program Files (x86)\gnucash\bin\libjavascriptcoregtk-3.0-0.dll #8 0x765b6d5f in msvcrt!_beginthreadex () from C:\WINDOWS\System32\msvcrt.dll #9 0x765b6e21 in msvcrt!_endthreadex () from C:\WINDOWS\System32\msvcrt.dll #10 0x74b86359 in KERNEL32!BaseThreadInitThunk () from C:\WINDOWS\System32\kernel32.dll #11 0x77217a94 in ntdll!RtlGetAppContainerNamedObjectPath () from C:\WINDOWS\SYSTEM32\ntdll.dll #12 0x77217a64 in ntdll!RtlGetAppContainerNamedObjectPath () from C:\WINDOWS\SYSTEM32\ntdll.dll #13 0x00000000 in ?? () Thread 8 (Thread 8416.0x5a30): #0 0x77221cdc in ntdll!ZwReadFile () from C:\WINDOWS\SYSTEM32\ntdll.dll #1 0x756510ec in ReadFile () from C:\WINDOWS\System32\KernelBase.dll #2 0x7659c34d in read () from C:\WINDOWS\System32\msvcrt.dll #3 0x0000058c in ?? () #4 0x0f56fb84 in ?? () #5 0x7659c07a in read () from C:\WINDOWS\System32\msvcrt.dll #6 0x00000007 in ?? () #7 0x0f56fb84 in ?? () #8 0x6e79e8b1 in read_finalization_pipe_data (data=0xf56fb84) at C:/gcdev64/gnucash/releases/src/guile-2.2.4.68-65d98/libguile/finalizers.c:199 #9 0x70bd312e in GC_do_blocking_inner (data=0xf56fb38 "\220èyn"ûV\017\220èyn"ûV\017\210ËZ\fFE\200n\220èyn"ûV\017", context=0x0) at C:/gcdev64/gnucash/releases/src/bdwgc/win32_threads.c:878 #10 0x70bc86fa in GC_with_callee_saves_pushed (fn=0x70bd30d0 <GC_do_blocking_inner>, arg=arg@entry=0xf56fb38 "\220èyn"ûV\017\220èyn"ûV\017\210ËZ\fFE\200n\220èyn"ûV\017") at C:/gcdev64/gnucash/releases/src/bdwgc/mach_dep.c:303 #11 0x70bcdb17 in GC_do_blocking (fn=0x6e79e890 <read_finalization_pipe_data>, client_data=0xf56fb84) at C:/gcdev64/gnucash/releases/src/bdwgc/misc.c:2041 #12 0x6e804546 in scm_without_guile (func=func@entry=0x6e79e890 <read_finalization_pipe_data>, data=data@entry=0xf56fb84) at C:/gcdev64/gnucash/releases/src/guile-2.2.4.68-65d98/libguile/threads.c:722 #13 0x6e79e968 in finalization_thread_proc (unused=0x0) at C:/gcdev64/gnucash/releases/src/guile-2.2.4.68-65d98/libguile/finalizers.c:212 #14 0x6e790540 in c_body (d=0xf56fe24) at C:/gcdev64/gnucash/releases/src/guile-2.2.4.68-65d98/libguile/continuations.c:422 #15 0x6e8140f8 in vm_regular_engine (thread=0xce11e60, vp=0xd55df30, registers=0xf56fc90, resume=0) at C:/gcdev64/gnucash/releases/src/guile-2.2.4.68-65d98/libguile/vm-engine.c:786 #16 0x6e8171ee in scm_call_n (proc=proc@entry=0xe6f6870, argv=argv@entry=0x0, nargs=nargs@entry=0) at C:/gcdev64/gnucash/releases/src/guile-2.2.4.68-65d98/libguile/vm.c:1260 #17 0x6e795a3f in scm_call_0 (proc=0xe6f6870) at C:/gcdev64/gnucash/releases/src/guile-2.2.4.68-65d98/libguile/eval.c:479 #18 0x6e805051 in catch (tag=0x404, thunk=0xe6f6870, handler=0xe6f6860, pre_unwind_handler=0xe6f6850) at C:/gcdev64/gnucash/releases/src/guile-2.2.4.68-65d98/libguile/throw.c:137 #19 0x6e805380 in scm_catch_with_pre_unwind_handler (pre_unwind_handler=<optimized out>, handler=<optimized out>, thunk=<optimized out>, key=<optimized out>) at C:/gcdev64/gnucash/releases/src/guile-2.2.4.68-65d98/libguile/throw.c:377 #20 scm_c_catch (tag=<optimized out>, tag@entry=0x404, body=<optimized out>, body@entry=0x6e790530 <c_body>, body_data=<optimized out>, body_data@entry=0xf56fe24, handler=<optimized out>, handler@entry=0x6e790740 <c_handler>, handler_data=handler_data@entry=0xf56fe24, pre_unwind_handler=pre_unwind_handler@entry=0x6e790550 <pre_unwind_handler>, pre_unwind_handler_data=pre_unwind_handler_data@entry=0xd55a510) at C:/gcdev64/gnucash/releases/src/guile-2.2.4.68-65d98/libguile/throw.c:377 #21 0x6e790a95 in scm_i_with_continuation_barrier (body=body@entry=0x6e790530 <c_body>, body_data=body_data@entry=0xf56fe24, handler=handler@entry=0x6e790740 <c_handler>, handler_data=handler_data@entry=0xf56fe24, pre_unwind_handler=pre_unwind_handler@entry=0x6e790550 <pre_unwind_handler>, pre_unwind_handler_data=0xd55a510) at C:/gcdev64/gnucash/releases/src/guile-2.2.4.68-65d98/libguile/continuations.c:360 #22 0x6e790b34 in scm_c_with_continuation_barrier (func=0x6e79e950 <finalization_thread_proc>, data=0x0) at C:/gcdev64/gnucash/releases/src/guile-2.2.4.68-65d98/libguile/continuations.c:456 #23 0x6e803ba5 in with_guile (base=0xf56fe8c, data=0xf56feb4) at C:/gcdev64/gnucash/releases/src/guile-2.2.4.68-65d98/libguile/threads.c:661 #24 0x70bcdadc in GC_call_with_stack_base (fn=0x6e803b60 <with_guile>, arg=0xf56feb4) at C:/gcdev64/gnucash/releases/src/bdwgc/misc.c:1935 #25 0x6e8044f0 in scm_i_with_guile (dynamic_state=<optimized out>, data=0x0, func=0x6e79e950 <finalization_thread_proc>) at C:/gcdev64/gnucash/releases/src/guile-2.2.4.68-65d98/libguile/threads.c:704 #26 scm_with_guile (func=func@entry=0x6e79e950 <finalization_thread_proc>, data=data@entry=0x0) at C:/gcdev64/gnucash/releases/src/guile-2.2.4.68-65d98/libguile/threads.c:710 #27 0x6e79e887 in run_finalization_thread (arg=0x0) at C:/gcdev64/gnucash/releases/src/guile-2.2.4.68-65d98/libguile/finalizers.c:236 #28 0x64b44ea1 in ?? () from C:\Program Files (x86)\gnucash\bin\libwinpthread-1.dll #29 0x765b6d5f in msvcrt!_beginthreadex () from C:\WINDOWS\System32\msvcrt.dll #30 0x765b6e21 in msvcrt!_endthreadex () from C:\WINDOWS\System32\msvcrt.dll #31 0x74b86359 in KERNEL32!BaseThreadInitThunk () from C:\WINDOWS\System32\kernel32.dll #32 0x77217a94 in ntdll!RtlGetAppContainerNamedObjectPath () from C:\WINDOWS\SYSTEM32\ntdll.dll #33 0x77217a64 in ntdll!RtlGetAppContainerNamedObjectPath () from C:\WINDOWS\SYSTEM32\ntdll.dll #34 0x00000000 in ?? () Thread 7 (Thread 8416.0x1e60): #0 0x77221cbc in ntdll!ZwWaitForSingleObject () from C:\WINDOWS\SYSTEM32\ntdll.dll #1 0x7565e159 in WaitForSingleObjectEx () from C:\WINDOWS\System32\KernelBase.dll #2 0x7565e0b2 in WaitForSingleObject () from C:\WINDOWS\System32\KernelBase.dll #3 0x70bd400c in GC_wait_marker () at C:/gcdev64/gnucash/releases/src/bdwgc/win32_threads.c:2119 #4 0x70bcb0a9 in GC_help_marker (my_mark_no=my_mark_no@entry=172) at C:/gcdev64/gnucash/releases/src/bdwgc/mark.c:1201 #5 0x70bd3f8a in GC_mark_thread@4 (id=0x2) at C:/gcdev64/gnucash/releases/src/bdwgc/win32_threads.c:1745 #6 0x765b6d5f in msvcrt!_beginthreadex () from C:\WINDOWS\System32\msvcrt.dll #7 0x765b6e21 in msvcrt!_endthreadex () from C:\WINDOWS\System32\msvcrt.dll #8 0x74b86359 in KERNEL32!BaseThreadInitThunk () from C:\WINDOWS\System32\kernel32.dll #9 0x77217a94 in ntdll!RtlGetAppContainerNamedObjectPath () from C:\WINDOWS\SYSTEM32\ntdll.dll #10 0x77217a64 in ntdll!RtlGetAppContainerNamedObjectPath () from C:\WINDOWS\SYSTEM32\ntdll.dll #11 0x00000000 in ?? () Thread 6 (Thread 8416.0x5a78): #0 0x77221cbc in ntdll!ZwWaitForSingleObject () from C:\WINDOWS\SYSTEM32\ntdll.dll #1 0x7565e159 in WaitForSingleObjectEx () from C:\WINDOWS\System32\KernelBase.dll #2 0x7565e0b2 in WaitForSingleObject () from C:\WINDOWS\System32\KernelBase.dll #3 0x70bd400c in GC_wait_marker () at C:/gcdev64/gnucash/releases/src/bdwgc/win32_threads.c:2119 #4 0x70bcb0a9 in GC_help_marker (my_mark_no=my_mark_no@entry=172) at C:/gcdev64/gnucash/releases/src/bdwgc/mark.c:1201 #5 0x70bd3f8a in GC_mark_thread@4 (id=0x1) at C:/gcdev64/gnucash/releases/src/bdwgc/win32_threads.c:1745 #6 0x765b6d5f in msvcrt!_beginthreadex () from C:\WINDOWS\System32\msvcrt.dll #7 0x765b6e21 in msvcrt!_endthreadex () from C:\WINDOWS\System32\msvcrt.dll #8 0x74b86359 in KERNEL32!BaseThreadInitThunk () from C:\WINDOWS\System32\kernel32.dll #9 0x77217a94 in ntdll!RtlGetAppContainerNamedObjectPath () from C:\WINDOWS\SYSTEM32\ntdll.dll #10 0x77217a64 in ntdll!RtlGetAppContainerNamedObjectPath () from C:\WINDOWS\SYSTEM32\ntdll.dll #11 0x00000000 in ?? () Thread 5 (Thread 8416.0x3258): #0 0x77221cbc in ntdll!ZwWaitForSingleObject () from C:\WINDOWS\SYSTEM32\ntdll.dll #1 0x7565e159 in WaitForSingleObjectEx () from C:\WINDOWS\System32\KernelBase.dll #2 0x7565e0b2 in WaitForSingleObject () from C:\WINDOWS\System32\KernelBase.dll #3 0x70bd400c in GC_wait_marker () at C:/gcdev64/gnucash/releases/src/bdwgc/win32_threads.c:2119 #4 0x70bcb0a9 in GC_help_marker (my_mark_no=my_mark_no@entry=172) at C:/gcdev64/gnucash/releases/src/bdwgc/mark.c:1201 #5 0x70bd3f8a in GC_mark_thread@4 (id=0x0) at C:/gcdev64/gnucash/releases/src/bdwgc/win32_threads.c:1745 #6 0x765b6d5f in msvcrt!_beginthreadex () from C:\WINDOWS\System32\msvcrt.dll #7 0x765b6e21 in msvcrt!_endthreadex () from C:\WINDOWS\System32\msvcrt.dll #8 0x74b86359 in KERNEL32!BaseThreadInitThunk () from C:\WINDOWS\System32\kernel32.dll #9 0x77217a94 in ntdll!RtlGetAppContainerNamedObjectPath () from C:\WINDOWS\SYSTEM32\ntdll.dll #10 0x77217a64 in ntdll!RtlGetAppContainerNamedObjectPath () from C:\WINDOWS\SYSTEM32\ntdll.dll #11 0x00000000 in ?? () Thread 4 (Thread 8416.0x27f8): #0 0x7722224c in ntdll!ZwWaitForMultipleObjects () from C:\WINDOWS\SYSTEM32\ntdll.dll #1 0x7566b923 in WaitForMultipleObjectsEx () from C:\WINDOWS\System32\KernelBase.dll #2 0x7566b7d8 in WaitForMultipleObjects () from C:\WINDOWS\System32\KernelBase.dll #3 0x6166311b in ?? () from C:\Program Files (x86)\gnucash\bin\libgio-2.0-0.dll #4 0x74b86359 in KERNEL32!BaseThreadInitThunk () from C:\WINDOWS\System32\kernel32.dll #5 0x77217a94 in ntdll!RtlGetAppContainerNamedObjectPath () from C:\WINDOWS\SYSTEM32\ntdll.dll #6 0x77217a64 in ntdll!RtlGetAppContainerNamedObjectPath () from C:\WINDOWS\SYSTEM32\ntdll.dll #7 0x00000000 in ?? () Thread 3 (Thread 8416.0x2c30): #0 0x7722224c in ntdll!ZwWaitForMultipleObjects () from C:\WINDOWS\SYSTEM32\ntdll.dll #1 0x7566b923 in WaitForMultipleObjectsEx () from C:\WINDOWS\System32\KernelBase.dll #2 0x7566b7d8 in WaitForMultipleObjects () from C:\WINDOWS\System32\KernelBase.dll #3 0x0a4431f0 in WacEventEx () from C:\WINDOWS\SYSTEM32\Pen_Tablet.dll #4 0x00000002 in ?? () #5 0x0ccc1fb8 in ?? () #6 0x0a470f0c in WacEventEx () from C:\WINDOWS\SYSTEM32\Pen_Tablet.dll #7 0x0a4622c0 in WacEventEx () from C:\WINDOWS\SYSTEM32\Pen_Tablet.dll #8 0x6e4ce1a7 in Wintab32!WTMgrOpen () from C:\WINDOWS\system32\Wintab32.dll #9 0x007620a0 in ?? () #10 0x6e4ce094 in Wintab32!WTMgrOpen () from C:\WINDOWS\system32\Wintab32.dll #11 0x00729e78 in ?? () #12 0x6e4ce89b in Wintab32!WTMgrOpen () from C:\WINDOWS\system32\Wintab32.dll #13 0x0a3bfd62 in ?? () #14 0x6e4971f8 in Wintab32!WTMgrOpen () from C:\WINDOWS\system32\Wintab32.dll #15 0x0a3bfe28 in ?? () #16 0x6e496fdf in Wintab32!WTMgrOpen () from C:\WINDOWS\system32\Wintab32.dll #17 0x00729e50 in ?? () #18 0x6e495de9 in Wintab32!WTMgrOpen () from C:\WINDOWS\system32\Wintab32.dll #19 0x0a3bfe28 in ?? () #20 0x6e4f5c31 in Wintab32!WTMgrOpen () from C:\WINDOWS\system32\Wintab32.dll #21 0x0a3bfe28 in ?? () #22 0x6e4f5da8 in Wintab32!WTMgrOpen () from C:\WINDOWS\system32\Wintab32.dll #23 0x0a3bff80 in ?? () #24 0x74b86359 in KERNEL32!BaseThreadInitThunk () from C:\WINDOWS\System32\kernel32.dll #25 0x77217a94 in ntdll!RtlGetAppContainerNamedObjectPath () from C:\WINDOWS\SYSTEM32\ntdll.dll #26 0x77217a64 in ntdll!RtlGetAppContainerNamedObjectPath () from C:\WINDOWS\SYSTEM32\ntdll.dll #27 0x00000000 in ?? () Thread 2 (Thread 8416.0x80): #0 0x76be708c in win32u!NtUserMsgWaitForMultipleObjectsEx () from C:\WINDOWS\System32\win32u.dll #1 0x7597e069 in USER32!MsgWaitForMultipleObjectsEx () from C:\WINDOWS\System32\user32.dll #2 0x7597df2e in USER32!MsgWaitForMultipleObjects () from C:\WINDOWS\System32\user32.dll #3 0x6d345666 in gdiplus!GdiplusStartup () from C:\WINDOWS\WinSxS\x86_microsoft.windows.gdiplus_6595b64144ccf1df_1.1.18362.295_none_5f5bd679821eb566\GdiPlus.dll #4 0x6d3455fa in gdiplus!GdiplusStartup () from C:\WINDOWS\WinSxS\x86_microsoft.windows.gdiplus_6595b64144ccf1df_1.1.18362.295_none_5f5bd679821eb566\GdiPlus.dll #5 0x74b86359 in KERNEL32!BaseThreadInitThunk () from C:\WINDOWS\System32\kernel32.dll #6 0x77217a94 in ntdll!RtlGetAppContainerNamedObjectPath () from C:\WINDOWS\SYSTEM32\ntdll.dll #7 0x77217a64 in ntdll!RtlGetAppContainerNamedObjectPath () from C:\WINDOWS\SYSTEM32\ntdll.dll #8 0x00000000 in ?? () Thread 1 (Thread 8416.0x544c): #0 0x7722224c in ntdll!ZwWaitForMultipleObjects () from C:\WINDOWS\SYSTEM32\ntdll.dll #1 0x7566b923 in WaitForMultipleObjectsEx () from C:\WINDOWS\System32\KernelBase.dll #2 0x7566b7d8 in WaitForMultipleObjects () from C:\WINDOWS\System32\KernelBase.dll #3 0x64b42e41 in ?? () from C:\Program Files (x86)\gnucash\bin\libwinpthread-1.dll #4 0x64b42030 in ?? () from C:\Program Files (x86)\gnucash\bin\libwinpthread-1.dll #5 0x64b4236d in ?? () from C:\Program Files (x86)\gnucash\bin\libwinpthread-1.dll #6 0x64b4288c in ?? () from C:\Program Files (x86)\gnucash\bin\libwinpthread-1.dll #7 0x6feeed15 in ?? () from C:\Program Files (x86)\gnucash\bin\libstdc++-6.dll #8 0x07085599 in ?? () from C:\Program Files (x86)\gnucash\bin\libjavascriptcoregtk-3.0-0.dll #9 0x07087780 in ?? () from C:\Program Files (x86)\gnucash\bin\libjavascriptcoregtk-3.0-0.dll #10 0x0708974d in ?? () from C:\Program Files (x86)\gnucash\bin\libjavascriptcoregtk-3.0-0.dll #11 0x0708a14b in ?? () from C:\Program Files (x86)\gnucash\bin\libjavascriptcoregtk-3.0-0.dll #12 0x0708a1de in ?? () from C:\Program Files (x86)\gnucash\bin\libjavascriptcoregtk-3.0-0.dll #13 0x03bbc277 in ?? () from C:\Program Files (x86)\gnucash\bin\libwebkitgtk-3.0-0.dll #14 0x03bbc4c5 in ?? () from C:\Program Files (x86)\gnucash\bin\libwebkitgtk-3.0-0.dll #15 0x03b83a58 in ?? () from C:\Program Files (x86)\gnucash\bin\libwebkitgtk-3.0-0.dll #16 0x0408e227 in ?? () from C:\Program Files (x86)\gnucash\bin\libwebkitgtk-3.0-0.dll #17 0x1ae7388f in ?? () #18 0x2002a5a1 in ?? () #19 0x1c7fac0b in ?? () #20 0x1a2485bb in ?? () #21 0x1ae433ce in ?? () #22 0x1a2f2a0f in ?? () #23 0x1ae4997d in ?? () #24 0x20009aba in ?? () #25 0x0710312b in ?? () from C:\Program Files (x86)\gnucash\bin\libjavascriptcoregtk-3.0-0.dll #26 0x070d1599 in ?? () from C:\Program Files (x86)\gnucash\bin\libjavascriptcoregtk-3.0-0.dll
An interesting collection. Do you have a Wacom tablet to go with WacEventEx in thread 3? Otherwise your debugger thread on top, 4 threads showing only WinNT functions, 7 javascriptcore threads (how many report tabs do you have open?), 3 bdwgc (the garbage collector for guile), and 1 guile thread stuck on a file read. I guess that that one (#8) is most likely to be the GnuCash main thread, but there's not enough info to be sure.
- I have the Wacom drivers installed as from time to time the machine has a graphics tablet plugged in. I have been driving it with a mouse for weeks, though, there is no tablet attached at this point in time. - Seven report tabs, but the majority have not been computed yet. The seven are all in the default tab set opened on launch, but I haven't visited all-but-one of them at this point, it's visiting the first which is getting it locked up.
I think following the guile route is more likely to produce a result than the webkit one. vote?
(In reply to Mike from comment #66) I'd like to reinforce what Mike and other people have said, I'm not sure why other people are ignoring the gorilla-in-the-room, but here goes again: > I just did some more testing, here are the results: > > As expected, the issue exists in 2019-06-13 and not in 2019-06-07. This is in the original report right up the top. What the heck happened to solving problems? We have a "before it worked" and a "afterwards it didn't work".
I have rebuilt my VM on Windows 10 64bit. First, I successfully rebuilt Webkit with just the newer compiler without debugging symbols since I ran into issues before and it still hangs, so a simple rebuild is not the solution. I am now continuing to work on building a debug version of webkit gtk. I did find a webpage where someone tried to build a slightly newer version of webkit on mingw, so if I do not have success with a debug build again, I will attempt to work through this process. For reference, that URL is https://gist.github.com/baylej/d32be86616104569b29b
> declared that they wouldn't support WebKitGtk on Windows after 2.4.x Rats. From baylej's gist: "It is impossible to compile WebKitGTK+ with mingw as-is, this document is the result of my journey to get it to build with mingw (yes, I spent several days trying)." That's because the WebKitGtk team declared that they wouldn't support WebKitGtk on Windows after 2.4.x and stripped out all of the Windows accommodation code.
I had another thought: I used the "depends.exe" tool to find out what libwebkit dependencies had changed since 7 June and looked those libraries up at http://repo.msys2.org/mingw/i686/ to see which of them upgraded between 7 and 13 June. The build script starts off with a system update so it has the latest MSYS2 packages. Maybe not the best way to get reproducible builds, but that's what it does. *Except* that WebKitGtk isn't getting updated since April and it depends on ICU. ICU changes their library names with each major version so we have to freeze WebKitGtk to keep the update from removing it, and ICU so that WebKitGtk still works, and Harfbuzz and Boost because they also depend on ICU and break if we let them upgrade. I found 3 packages that upgraded that week: glib from 2.60.3 to 2.60.4; libc++ from 8.0.0-4 to 8.0.0-8, and libxml2 from 2.2.9-1 to 2.2.9-2. I think it very unlikely that any of those would cause the javascript thread to wander off, but it might be worth trying. If you're able to get GnuCash to hang without making a setup.exe and installing it in c:\Program Files (x86) you could just downgrade them in MSYS2 by running pacman -U /path/to/tarball Otherwise you'll need to do that and then build and install GnuCash. The three package tarballs are: http://repo.msys2.org/mingw/i686/mingw-w64-i686-glib2-2.60.3-4-any.pkg.tar.xz http://repo.msys2.org/mingw/i686/mingw-w64-i686-libc%2B%2Babi-8.0.0-4-any.pkg.tar.xz http://repo.msys2.org/mingw/i686/mingw-w64-i686-libxml2-2.9.9-1-any.pkg.tar.xz
Maybe we can disable pthreads on Windows?
Hi all, I just reported Bug 797470 which Christopher Lam pointed out is likely the same bug. Obviously the bug has been identified, but in the meantime, is there a workaround I can use? I tried to download the 2019-06-07 release but couldn't find it on the gnu cash website. If someone could point me to a working release or other workaround that would be appreciated.
@armanschwartz, there's a link to the 2019-06-07 nightly in comment 65. You could also use GnuCash-3.5 which you'll find on SourceForge and Github. @chris, at present we're using a pre-built webkit that already has pthreads linked in. Leaving pthreads out of the AIO would just mean that it wouldn't load at all. I *think* that webkit requires some sort of threading to build, and I don't know if it can work with whatever threading msvcrt provides nor if using that threading would work with Gtk.
Has the problem actually been identified? Triage: we know there is a problem it wasn't there a while ago, it is there now we can actually date the problem occurring by scrolling through this thread presumably someone thought whatever it was they did was a good enough reason to fuck up a lot of reports and doesn't really care ... that's how open source works sometimes But ... do we know what the actual problem is? I'm not sure we do.
In case anyone needs a reminder, this problem is 2 versions old :(
Good News! I have made progress. I did as John suggested in Comment 80 and rolled back those three packages, rebuilt everything and so far I have not gotten GnuCash to hang like before. I will see if I can figure out how to make the appropriate changes to the gnucash on windows script as my next step if no one beats me to it.
Matt, Awesome! I can take care of the setup script. I'll first make a change on the buildserver and make an installer so that everyone else here can try it.
The build with downgraded dependencies is ready at https://code.gnucash.org/builds/win32/maint/gnucash-3.7-2019-11-10-git-3.7-209-ga482c2507+.setup.exe Everyone please test!
In use, graphs seem slightly quicker and no problems. I am feeling positive. If you don't hear from me for a few days all is well.
Even on the new build, I have managed to reproduce the problem twice on area/bar charts. It may be happening less often now, or that might just be me being hopeful, but it appears to me that the problem has not been resolved.
@Simon and all: if something *isn't* working maybe we should be more specific, I'm not sure what an area/bar graph is although I am aware we have used many terms above in describing our problems.
...and after ten more minutes, it's even failed for me on line charts as well. I think that, with the experience I have had, the build provided in comment 88 is no more functional than the builds which originally caused this bug to be created. With respect to Comment 91, I can't put my finger on it because it seems to be that -all- chart types I generally use fail at some arbitrary point, but work just fine at other times. It's neither deterministic enough nor contains enough log messages somewhere to tell me what is happening. For clarity, when I say the same issue, I mean CPU drops to 0 during rendering of a chart and then Windows fades the application and asks if I would like to force quit it, the temporary directory contains a copy of the chart which is openable in my browser of choice and works fine.
(please disregard my reference to an area chart in comment 90, it was actually just a bar chart with a sufficient number of lines that they were all squashed together closely enough to look like an area chart, using Excel terminology).
rats, I've just had a fail on a line graph ".vg values" is my ref. Weird thing is it worked a few hours ago. @Simon: do you always get a chart in temp? @All: does everyone get a result even if it isn't displayed? I'm trying to triage between the output not being produced and the output being produced but not displayed.
From what I can tell, it always makes a gnc-report-* file in Temp for me. The sequence is: 1. Open the tab for a report that hasn't yet loaded 2. GnuCash CPU usage ramps up while graph generates 3. File appears in Temp Then either: 4(i). Graph displays as expected, or 4(ii). GnuCash CPU crashes to 0, Windows marks the program as not responding And, in either case: 5. I can open the gnc-report-* file in my browser and it loads correctly. Notepad++ shows clearly that the closing </html> has been inserted, so the file is not truncated.
Since not everyone seems to have the same success as I did, I tested John's build on my VM to make sure that his installer achieved the same results with my test setup. His works just like mine did. I still have not had a single hang with either his build or my build. My test is a book that has about 20-30 graphical reports open when I start gnucash and I just click from one to the next as each one is rendered. Then, after I've ran each one on startup, I will go in and change an option on each to get it to rerender the report. I'm not sure how much more I can do to help diagnose the problem unless there is something else that might be different between my testing and your testing. My development VM happens to still be on Windows 7, though I am working on getting a windows 10 machine setup, but that will probably be a few weeks before I get it fully setup. If anyone has anything else they are doing differently, let me know and I'll see if I can reproduce it.
*** Bug 797470 has been marked as a duplicate of this bug. ***
MattF, thank you for your effort. You're stressing gnc way more than I am, I get failures on single charts. All: Let's try applying some logic to this problem, feel free to shoot anything I say down, this is thinking not ego. It can't be Windows versions because it did work before on all Windows versions available at the time, thus: it has to be something else. What changed? We have a very specific occurrence if you (plural, not any specific person) look at the top of this thread and read through it. Why don't we rewind? We know something happened, we know it worked before and didn't work afterwards. What is so important that we can't go back to what worked before? I do understand that progress is generally good and I am generally enthusiastic about it. I think we have an unusual case here in that something that was introduced for the general good hasn't worked out as expected. I think I'm going to have to go back to a version that worked. I'm not moaning, just saying. ==== At the moment the status of this is "NEEDINFO" what more do you need to now?
Wm, While the problem has been resolved for me, it's obviously not for everyone. So, to answer your other question. What the new build did is roll back to the versions of libraries just before it started having issues, so more or less, the current environment should be identical to what was there prior to the problem appearing. It solved it for me, but unfortunately did not solve it for everyone. At this point, i'm not sure how else to try to help solve the issue as I'm very much a newbie programmer, but as I know how frustrating these types of issues can be, I'm doing my best to see if there is anything else we can try. If anyone has ideas, I'm all for it. I did toy with the idea of seeing if I could make it launch reports in a webbrowser, but then that would break any of the hyperlink functionality. I'm not sure what info is needed at this point, but since the developers that have spent time on gnucash don't see the issue and the wannabe developer (me) has spent quite a bit of time on it and it's better, I'm not sure how else to help unless someone still seeing the issue can spend time helping troubleshoot further. I'm open to any ideas that people have that my simple skill level can handle.
I can confirm that the build made available through comment 88 (https://bugs.gnucash.org/show_bug.cgi?id=797283#c88) still freezes when trying to render custom reports. Some render but most of my reports do not. I am on Win 10 Pro. The last version that has no rendering issues for me is 3.5.1 Regards.
MattF, if I or anyone else left you with the impression that I/we *didn't* appreciate your work I am the person in the wrong. Don't put yourself down :) gilberto, I think a big part of the problem is we don't actually know what the problem is. I think we know it is only a Windows issue and that means it is a big problem not a little one as most gnc users use Win however much we (people that believe in open sw) dislike the monster that is MS I think we know which Win version a person is using doesn't matter. I think we know when the problem was introduced near to the day (someone else can probably work it out near to the minute if they are interested in that level of detail). So, MattF tried to go back and that has worked for some but not all. Help me think, please! It isn't an issue of the people reading this lacking brain power!
Setting processor affinity to a single processor fixes this for me.
wvdo, I believe you're absolutely correct. I started gnucash with the following PowerShell command: [System.Diagnostics.Process]::start("C:\Program Files (x86)\gnucash\bin\gnucash.exe").ProcessorAffinity=0x0001 And loaded every graph without crashing. I then closed and reopened gnucash, repeating the process, four more times. I then launched gnucash normally again (and validated it had all-core affinity), and it immediately crashed opening my asset barchart. I ran five tests total with all-core affinity and gnucash failed on three separate runs. I believe that forcing the process to be single threaded is a valid workaround (although a bad overall solution) to this.
Dear All, I also confirm wvdo's findings. Setting processor affinity to a single processor apparently fixes the issue for me in version 3.7 I have had no more crashes on my custom reports.
Simon and Gilberto, *very* interesting. For clarity though don't you mean hang rather than crash?
You're right, I mean hang. I guess the reason I keep mixing it up is that when the only option on the windows dialog box telling me it's frozen is the choice to force quit it, it feels extremely like a crash to me. :) In an attempt to be clear, though, yes, the window stops responding and Windows greys it out.
John to be honest with you I am not really sure about the difference between hang and crash in this case. I'll try to explain what used to happen in my case before setting the processor affinity. Hopefully this helps a bit. :) In my case the problem occurred when normally using Gnucash (after it loads and opens the xml file containing my transactions) and trying to open reports (I tested with custom reports because I do not use the default reports very often). The program used to stop working followed by a Windows dialog asking if I wanted to close the program or wait. The dialog and Gnucash appeared in gray. I hope this helps!
I thin Gilberto is describing something different to most
The problem we're talking about is an actual failure. Want to know the weird thing? JohnR appears to not believe it is real. How strange is that?
wvdo - I confirm I cannot make GnuCash hang with the above cmdline run. Thanks for finding a suitable solution!
this is getting weirder by the day, is the Windows dialogue box I or other people get when gnc fails a crash or a hang? does it matter? why are we even discussing whether it is a crash or a hang? FFS
Wm - Crash or hang makes a difference in what the potential cause can be and how you can get the relavent information to troubleshoot further. I've been busy for a few days, but I'm going to try to do some more testing with multi threading vs. single threading on my development stuff and see if I can get some more insight as to whether rolling back the libraries really solved it or just made it less common.
Matt, you should know you didn't make this problem and it isn't actually yours to fix. Someone else did something. Maybe someone that doesn't care about facts like the majority of gnc users being on Win.
what this thread needs is a leader. Someone with an open mind, someone able to say "a mistake was made". who is that person?
I did confirm my development VM has 4 cores assigned to it and so Gnucash is running in a multithreaded environment. I still cannot get it to crash after the changes I made earlier. I have tested on both a Windows 7 and Windows 10 VM's.
Hmm, and my Win10 VM is configured with only 2 cores and I've never been able to reproduce the problem. wvdo, Simon Hollingshead and Gilberto Reis Filho: How many cores do you have (if you don't know look at Task Manager>Performance>CPU, it's in the text under the graph)? Can one or more of you try setting processor affinity to different numbers of cores and figure out what is the minimum number that induces the hang? According to https://mywindowshub.com/find-number-cores-processor-limit-core-use-apps-windows-10/ you can do that on the fly from Task Manager.
Matt Forbis, can you try removing the ignores for the 3 packages and rebuilding WebKit with this change: --- a/Source/WTF/wtf/ThreadingPthreads.cpp 2016-04-09 23:48:36.000000000 -0700 +++ b/Source/WTF/wtf/ThreadingPthreads.cpp 2019-12-14 11:12:18.000000000 -0800 @@ -128,6 +128,7 @@ wtfThreadData(); s_dtoaP5Mutex = new Mutex; initializeDates(); + pthread_set_num_processors_np(2); } static ThreadMap& threadMap() pthread_set_num_processors_np() is a MinGW64 customization that sets the ProcessorAffinity mask to limit the number of cores.
I'll see what I can do. I believe I got close to building webkit before, but ran into issues with not enough memory on some of the last linking steps, but I've rebuilt my development vm since then.
You said in comment 78 that you'd been unable to build with debugging turned on because you ran out of memory, but that you'd succeeded with a non-debug build and found that rebuilding with the latest dependency versions made no difference. Meanwhile I find that I'd mis-remembered. My Win10 VM is also set to 4 cores. I just upped it to 8 and I'm going to see if I can make it hang.
John, You are correct. That's been a few months now. I am currently working on building it with your patch. We'll see in a few hours. My previous VM before changing the libraries was only 2 cores and I saw the problem and the fix, so I'm not sure it's completely related to the number or cores.
It seems not to be entirely that. Even with 8 cores set on my VM and 9 graphical reports the closest I got was a few seconds of spinner. Double clicking during one of them got me the "not responding" dialog, but it went away and the chart drew a few seconds later. That's with stock GnuCash3.7.
Just to chime in from my side: I appear to have the same issue. GnuCash 3.7 (Windows 10 on hexacore i7) freezes at random moments quickly after adding a "Expenses Chart" report (which contains a bar chart). It is not completely predictable when it happens, but once the barchart is displayed it never takes more than a few operations before the window becomes unresponsive. This all confirms the suspicion of a threading problem in the report rendering code. The workaround of calling via PowerShell command line: [System.Diagnostics.Process]::start("C:\Program Files (x86)\gnucash\bin\gnucash.exe").ProcessorAffinity=0x0001 appears to prevent the freeze. So, no new info from my side, but a confirmation of what was stated before. If there are builds with fixes available I'd be happy to try them out in my scenario that appears to provide a rather reliable repro.
Note that you can also change processor affinity from Task Manager after GnuCash is launched. Switch to the Details tab, find GnuCash and right-click on it, then select affinity from the context menu.
Addendum: I did experience a freeze after all, even with the processor affinity workaround. It took about an hour to happen instead of seconds,but it looked very similar.
Rats. Well, I guess an hour is better than seconds, but I have to wonder if it can really be a WebKit Javascript thread issue if the graph is already drawn and displayed.
All: I think the graph gets drawn regardless, it is the display bit that is failing [1] [1] don't take my word for this, please yell if it doesn't match your experience. I think the affinity thing is interesting but non-conclusive, some of my users don't even know if they have more than one affinity. They're just "dumb" charitable organisations. NEEDINFO? yup this is puzzling
Thinking: if it was all about processor affinity, why do reports sometimes work and other times fail? My availability of processors and affinity don't change moment to moment. I *know* people are trying to help but can it really be a hardware issue?
All: please bear in mind the following: reports that used to work at some point in the past no longer work reliably. The reports haven't changed, something in gnc changed. Some people want to go forward, other people want to go back. How about we work out what the problem is before we do anything? Yeah, I know this will upset some people, how about some honesty?
if there is another gnc bug with more people following it, let me know
Wm, I'm not quite sure why you keep reiterating the same points and seem to think someone is lying to you. Like was mentioned early on in the bug, nothing in GNUCash source changed between the time it was working and not, but some dependencies in the build environment changed. That's what I've been working on solving the whole time, but I'm not an expert programmer like others. In some of my tests, I have solved it for my local environment and at this point I'm trying to help others out, but those of us working on the problem don't see it as much as others, so it's harder to figure out. I'm not sure continuing to add opinions to a bug helps anyone solve it faster, maybe the contrary. All others, I'm still working on building webkit with John's patch. I'm stuck on some ld errors at this point.
I finally built webkit with the current dependencies. So far, I have not had a hang, but I wasn't having repeated hangs either after some of my other rebuilds. I had to make a few more patches in addition to what was required back when mingw dropped support in order to get it to compile successfully (all of those, might not be the best way to do it, but it worked.) John, what would be the best way to have someone else test it to see if it made any difference? Do you want me to upload patches to mingw/webkit, upload either the pacman webkit package and/or upload the gnucash installer somewhere? I was having trouble getting the patches to apply cleanly by themselves, so a few I had to do by hand, so it wasn't a complete hands off process.
Matt, The quickest way to get a package for others to test would be to send me your installer. At ~90MB they're too big to attach here, so we'd need to find another location. I don't suppose you have a Sourceforge id... The next quickest would be to attach the pacman webkit tarball here (it should be around 10MB and I think the limit is 20) and I'll set up the nightly build to use it. I'd like to have the patches as well. If you have patchfiles and notes about the manual interventions you could tar those up and attach them. Otherwise you could tar up the source directory with all of the changes and I can diff that against the original distribution tarball with Alex's patches and turn that into a patch.
To verify any potential fix, it would be good to have it either as runtime switch or as two builds with and without the fix that are otherwise identical. Only a direct comparison will assure that it really is the fix that makes the difference.
I still am trying to figure out how to reorganize my commits for the patches, but I think I got them all working finally and have pushed my webkit branch to https://github.com/mdforbis/MINGW-packages/commits/WebkitGTKChanges. Hopefully these work for you. The one change is also just to skip gtk2 to save time. It still takes almost 24 hours to build on my machine. As to the installer, I don't have sourceforge, but I have hosting space. If you want me to send you a link and you can upload to sourceforge, I can do that. I'm not sure I want the link in bugzilla for all eternity.
Norbert, that's a worthwhile point: In addition to my one-line patch from comment 117 Matt has had to make several other patches to WebKit to build it. I'll change it to call pthread_set_num_processors_np() to check for an environment variable that can be set to a number and rebuild. Matt, I've got your branch and merged it into my mingw-packages repo. Since I'll be changing the patch I won't need your built package.
Hi guys, I just took the time to read through this whole discussion. A few essential insights: a) The strongest indicator for the root cause in my opinion is that two different lists of stack traces mention libguile/finalizers in one thread and bdwgc in another. It appears like the system is trying to free memory and ends up in a deadlock. This suggests that the real problem happens some while before the hang. Rendering may just be the cause for significant memory allocation, triggering the garbage collector to run. The offending code seems to be something related to guile. Possibly the code creating a bar chart? b) There were very few changes between the builds when the issue first appeared. The most likely candidates for triggering this issue were the changes of dependencies ("3 packages that upgraded that week: glib from 2.60.3 to 2.60.4; libc++ from 8.0.0-4 to 8.0.0-8, and libxml2 from 2.2.9-1 to 2.2.9-2.") The version jumps are small, so it should be possible to either find out what changed and try various combinations of these version to further narrow down the trigger of the problem. (Note that these changes only triggered the problem. The actual bug might still be somewhere else! Still, understanding the trigger might help finding the bug.) c) The idea of the processor affinity was brought up without much backing beyond "This works for me". In fact, while processor affinity may severely affect performance and timings and may make a race condition more or less likely to occur, it cannot not have any effect on the correctness of a program. I'm not even sure what processor affinity would actually do on a typical modern single-processor multi-core machine. In any case: good for you if this trick helps you get your work done, but do not expect this to fix or even reliable work around the problem. d) The best reliable workaround appears to be rolling back to the last known good release 3.5.1 Greetings, Norbert
Matt Forbis, The only thing you missed in your commits was adding the sha256 for each patch to the list at the bottom of PKGBUILD.
Hi John, Thanks for that hint. It was much easier to update that I realized and I have pushed the updated pkgbuild file to github just for the sake of anyone else following this bug. If there is anything else anyone can think of to help me go further with this bug, let me know.
A had another close look at the issue, this time managing to create stack traces myself. Turns out, my previous suspicion about finalizers&bdwgc was bogus: These threads look just like that when the program is running idle and looking at the code that make perfect sense. So: for all I can see, the stack trace does not provide any valuable information. Unfortunately, I have not yet managed to build gnucash myself on Windows. I did manage to run gnucash-on-windows.git to the point where it calls the configure script, but then it complains about a missing msys-readline8.dll which I can't find anywhere. Not sure whether building gnucash on my machine would help much, since gdb in msys2/mingw appears to be extremely limited.
@norbert, gdb's main limitation in MinGW is that it doesn't recognize the MSys2terminal as a terminal so it won't handle ctrl-C to break execution. There's a workaround at http://www.mingw.org/wiki/Workaround_for_GDB_Ctrl_C_Interrupt. I find that it works a little better when run under Powershell, but in that case you have to set up PATH to include C:/gcdev64/msys2/usr/bin;C:/gcdev64/msys2/mingw32/bin;C:/gcdev64/gnucash/maint/inst/bin;c:/gcdev64/gnucash/maint/build/gnucash/bin so that it can link the executable. msys-readline8.dll should be in /c/gcdev64/msys2/usr/bin. It's required by several of the base packages installed by setup_mingw64.ps1. Did you run that to setup your build environment?
Thanks, John, the Ctrl-C workaround sounds like exactly what I need. For building: yes, I did run setup_mingw64.ps1 - however, it had some issues. On running the jhbuild command, it immediately complained about missing libraries. Turned out that 'pacman -S openssl libopenssl mingw-w64-i686-gnutls' was needed to fix the first issues. (It seems like msys2 does not pull in all dependencies.) For msys-readline8.dll however, I could not install any package that would provide that. Curiously, 'pacman -S readline' does not find the package even though it is lists on the msys2 package website.
setup_mingw64.ps1 doesn't run jhbuild. buildserver/build_package.ps1 does that. The package you want for msys-readline8.dll is libreadline. If for some strange reason `pacman -S libreadline` doesn't work try `pacman -U http://repo.msys2.org/msys/i686/libreadline-8.0.001-1-i686.pkg.tar.xz`
When I have been building on windows, I have had to install a few packages the script does not pull in: openssl-devel, mingw-w64-i686-gnutls, glib2-devel, libxml2-devel, libxslt-devel icu also installs a newer version as a dependency, but the version 61 installed by the gnucash script still meets the requirement. I end up having to install icu 64 with a force command option because the dependencies in pacman aren't happy even though they should be. For GDB, I am having luck with using visual studio code and gdb. I still have some things to work on on cscode to compile with it, but debugging and editing it works pretty well as an option.
I'll take a look at why those aren't getting pulled in and fix the script. As for VSCode, cool. Could you add something to https://wiki.gnucash.org/wiki/Building_on_Windows about how to get that set up?
Matt, are you perhaps running an msys2 shell instead of a mingw32 one? All of those devel packages are for building with msys2. That's not what we do because it creates a dependency on Cygwin so that a user would have to have MSYS2 installed in order to run GnuCash. The problem with mingw-w64-gnutls seems to be that the archived mingw-w64-i686-webkitgtk3 isn't getting installed because of a missing dependency, mingw-w64-i686-anglefish. Webkit also requires libsoup, which requires glib-networking, which requires gnutls. It's also what pulls in gtk3 and its dependency stack. I'll get all of that sorted and pushed in a couple of days.
No, I've been running an mingw32 shell. If there is a mingw version that's similarly, I might have installed that instead, but shortened the name.
Well, something's wrong if you need msys2 devel packages for anything. Are mingw-w64-i686-openssl, mingw-w64-i686-glib2, mingw-w64-libxml2, and mingw-w64-i686-libxslt installed?
I do have those 4 packages installed. My notes had for openssl-devel - this seemed to keep python's hashlib from working correctly and not able to go very in the build process (I didn't start keeping notes right at the beginning). I'm going to start a clean VM and see if I can figure out what the issue was that lead me to install those, and maybe there was a better package to install instead.
You might want to hold off on that for a bit until I get a revised webkitgtk3 ready that doesn't depend on angleproject. It's for WebGL which we certainly don't need for GnuCash so I've modified PKGBUILD to leave it and a couple of other options that we don't need out of the build. It's building now so I should be able to put it on sourceforge tomorrow and change the URI in setup_mingw64.ps1.
I'm just watching again, sigh
Well, now you can test. The 3.8 release bundle includes a re-built WebKitGtk with a processor_affinity setting. It's controlled by the environment variable WEBKIT_PROCESSORS. If that's set to something between 1 and 15 inclusive it will call pthread_set_num_processors_np with its value. The easiest way to enable/adjust it is to add the line (substitute an actual number for 'x') WEBKIT_PROCESSORS=x to c:\Program Files (x86)\gnucash\etc\gnucash\environment.local That file doesn't exist by default. You can edit environment instead if you like, but if you do the next install will overwrite it. You'll need to launch your editor with "run as administrator".
John Ralls: I'm interested in testing this but I can't find the binary that you've built. I had a look on sourceforge (https://sourceforge.net/projects/gnucash/files/) but couldn't find it.
armanschwarz, it's the 3.8 release bundle, https://sourceforge.net/projects/gnucash/files/gnucash%20%28stable%29/3.8/gnucash-3.8.setup.exe/download or https://github.com/Gnucash/gnucash/releases/download/3.8b/gnucash-3.8.setup.exe
Thanks John. This seems to work great. I'm not sure this is expected but that 3.8b binary works fine for me regardless of pthread settings. I tried WEBKIT_PROCESSORS=1, WEBKIT_PROCESSORS=2, WEBKIT_PROCESSORS=15 and with the environment.local file completely removed. I can't get this to crash at all. To verify something else hadn't changed I tried downloading 3.7 and it crashed straight away with various charts. As far as I can tell this is resolved now in the 3.8b you put up. I'm a bit confused though as to what the actual fix is, was it just removing the angleproject dependency? In any case, nice work :)
Interesting indeed, but there are others to hear from before we can declare victory. For the record: In addition to angleproject (for various forms of GL rendering) I also removed GStreamer (for audio and video), geoclue (for location services), and enchant (for spellcheck) because GnuCash doesn't have any use for any of that and I figured the lighter I can make it the better.
I also confirm that I cannot get build 3.8b+ (2019-12-29) to crash. I did not mess with the environment variables. Thanks, John!
I had success before with my own build, but I can confirm on my machine, the released version is stable also. I have not created a hang yet.
Good news: The 3.8 build appears to fix the issue for me as well without need for setting processor affinity. The same report that would reliably cause a freeze within seconds of opening it now shows up fine without any problems.
Good news on my side too. No more hangs with 3.8b+ from 29/12/2019. Great work from all involved in solving this issue!!
Haven't tested it yet -- the next step may be to slowly reintroduce components and investigate the cause for the hang... who is up for it?
Why would we want to do that? We have no need of any of the components I left out.
I'm definitely going to test the latest maintenance build this weekend to see if the issue is resolved for me as well. Will report back then.
Sadly, when using this build: > gnucash-3.8-2020-01-04-git-3.8b-23-gb5fdcfcb5+.setup.exe Out of the box without any environment variables, when running the Income Barchart I encountered this behaviour. The Income Barchart was the 11th report that I ran, back to back, of which 8 of the 11 reports were graphical. 1. The Windows menus (File, Edit, etc) still respond to clicks 2. The toolbar UI is frozen (the "Options" button remains "clicked" for example) but it still responds when clicked (clicking the Options button still opens the report options dialogue). Screenshot: https://i.imgur.com/fdn7VE3.png 3. Clicking on the open tabs to try to navigate to other reports, does not work. 4. Right clicking on tabs to use the menu no navigate: the right click menu appears, and selecting a report it spins and looks to load something, but the pane is still frozen and does not change view; the frozen report remains displayed. In my case, I started at the Income Barchart (frozen), and tried to navigate to the Balance Sheet. The cursor spin for a bit and it seems to have loaded, but the UI pane is still frozen at the Income Barchart. 5. After using the File menu to quit, and relaunch, upon launching I'm loaded at the Balance Sheet, so it suggests that nothing "broke"; simply only the UI pane was frozen on the Barchart.
So far I have not been able to consistently replicate, so I'm somewhat tempted to conclude that this might be idiosyncratic and not related to this particular issue, perhaps? Either way, the "full application non-responsive freeze/hang" issue seems to have been solved.
So far, it seems like the "ncome Over Time barchart is what is most likely to cause a freeze. This time when it froze, everything (Windows menus, toolbars UI, tabs) all did not respond to input. But again, when I force close GNUcash, relaunching does return me to the last open report (the income barchart in this case), so GNUcash still saved the open report state correctly. It's just a UI freeze issue it seems.
@CDB-Man may I suggest the Income Over Time Barchart is where *you* notice something general?
(In reply to CDB-Man from comment #163) > Sadly, when using this build: > > gnucash-3.8-2020-01-04-git-3.8b-23-gb5fdcfcb5+.setup.exe [snip] > 5. After using the File menu to quit, and relaunch, upon launching I'm > loaded at the Balance Sheet, so it suggests that nothing "broke"; simply > only the UI pane was frozen on the Barchart. If your Balance Sheet isn't working you have a different problem to most people in this thread. Further, although I have had a number of bar charts fail it is mainly line charts that fail for me. -- Wm
> @CDB-Man may I suggest the Income Over Time Barchart is where *you* notice something general? Correct. I seem to somewhat consistently run into issues when running specifically the income over time bar chart, especially after generating other charts immediately prior. Would be interesting to see if other people notice something similar if they try to run several back to back reports, then run an income bar chart after. > If your Balance Sheet isn't working you have a different problem to most people in this thread. I think you misunderstand, and I didn't explain it well. The balance sheet is NOT broken. What I mean is this: 1. Normally, when you launch GNUcash, it loads on the report that was last opened. 2. In the scenario I described in comment 163, the UI froze on the income bar chart. However in that particular instance, right click still worked, and I was able to select my previously open balance sheet. The mouse cursor spins and the balance sheet seems to load in the background, but the UI is still frozen on the income bar chart. 3. After this, I use the File menu to exit, then restart the program. 4. Referencing point #1, the last visible report upon close was the frozen income bar chart. However what opened at launch was instead the balance sheet. This suggests to me that my guess in point #2 is correct, in that the balance sheet did in fact load in the background. The only issue is UI freeze (that kept the display on the income bar chart, instead of loading the balance sheet). In other words, the balance sheet report is NOT broken. Rather, I just used it to help identify that the issue is the actual UI freezing, rather than the "report generation" freezing.
Has anyone noticed this isn't as much of a problem in 3.9 ? If it has been fixed in the course of something else being fixed I am happy with that. Should we reduce the importance?
Unless someone is still suffering these horrible reports using 3.10 I think this should be demoted from Importance: High critical to Importance: probably fixed but we have no idea how we fixed it so we don't know if it has actually been fixed Version: should be updated to 3.10 NEEDINFO ? Yup, we need some reports about it being fixed or not. Criticism is good but people should also say if something is better.
I can confirm that so far I have yet to see the issue resurface on this build: > gnucash-3.8-2020-01-25-git-3.8b-89-ga9d51dd9e+.setup.exe I'll go grab the latest and test.
3.10, after running about 15 different reports, report #16 was a transaction report. The Report's edit screen responded, but the actual main window itself was frozen. Changes to the report options screen committed, but the main window was dead.
The File, Edit, etc menus still responded, but the tabs were dead.
Hmm, I cannot replicate it with certainty. However, given that it died on a non-graphical report (transaction report), I think at least it is safe to assume that it is a separate issue.
Let's go with that. If you can get the new hang to reproduce--and figure out exactly what's hanging--open a new bug.
*** Bug 797325 has been marked as a duplicate of this bug. ***
