GNOME Bugzilla – Bug 738477
WebKit is broken on Win32.
Last modified: 2018-06-29 23:34:56 UTC
I installed 2.6.4-2 on Windows 7 Professional SP1, 64-bit. When closing the application, it freezes: the main window gets dimmed, the title bar gets the (Not Responding) suffix and no amount of waiting fixes the issue. The only outcome is force closing the window, with the accompanying warnings from Windows, regarding possible data loss. Task Manager shows that the gnucash.exe*32 process is not using any CPU and it hasn't released any memory yet.
Other users have been reporting this as well on the gnucash-user mailing list and seemed to have found a reliable way to trigger it as well: Ian K wrote > I have installed the 2.6.4-2 release on Windows 7 x64 and the above > problems have been resolved. > I did experience a hang on exiting. I exited using the menu rather than > closing the window, and GnuCash hung with 'not responding' in the title. I > had to force close it. I had been inputting transactions and had run a > couple of reports. I then reopened it and exited again, without changing > enything, and this time it didn't hang. Mike T wrote > I have experienced the same "not responding" issue on Windows 7 x64 after > installing the 2.6.4-2 release. This shutdown problem happens after running > pretty much any report, closing the report, and then attempting to close > GnuCash. And this was after beginning with a new account hierarchy. I > intend to use 2.6.3 until this is fixed.
It there anything in the gnucash trace file [1] that is generated during for the hanging session ? [1] http://wiki.gnucash.org/wiki/Tracefile
No, but it displays the problem behavior in the debugger. Unfortunately it looks like the problem might be that something in msvcrt is getting corrupted. Here's what happens: Breakpoint 4, gnc_shutdown (exit_status=0) at c:/gcdev/gnucash.git/src/gnome-utils/gnc-gnome-utils.c:784 784 gnc_engine_shutdown(); (gdb) n Cannot remove breakpoints because program is no longer writable. Further execution is probably impossible. 785 exit(exit_status); warning: Error removing breakpoint -2805 warning: Error removing breakpoint -2806 (gdb) n Warning: Cannot insert breakpoint -2816. Error accessing memory address 0x6430cd30: Input/output error. Cannot insert breakpoint -2815. Error accessing memory address 0x7c343646: Input/output error. (gdb) At which point 'kill' works to terminate it.
msvcrt.dll ? That rings a bell. Are you debugging your local build or the released one ? While experimenting with guile 2 I was "strongly" adviced to revert back to the v3 api and runtime, while we had been using the v4 api and runtime for some time now. So I changed the versions in defaults.sh. However I'm not sure the installer script will downgrade automatically. I manually removed the v4 api and runtime before restarting a build. IIRC I did the same on the build server. I should have been a bit more vocal about that. John, what happened on your windows build system ? Is it still using the v4 api? You can quickly see this by looking at the date of c:\gcdev\mingw\bin\mingwm10.dll If it's 2012-06-29 then you have v3 of the runtime, if it's 2013-09-22 then you have v4 of the runtime. The way this may play a role is that you have built the newer versions of gtk/cairo/glib. Perhaps against v4 of the api, while the rest of gnucash was built against v3. It's just one possible lead to follow...
Just as another data point: so far I haven't been able reproduce this on Windows XP. I tried what Mike T said on the mailing list: - open gnucash - run a report and close it - exit gnucash => normal exit Tried this also: - open gnucash - run a report (don't close it) - exit gnucash => normal exit I haven't tried in the debugger.
I'm debugging a local build. The date on mingwm10.dll is June 29 2012.
Hmm, so you are using the v3 api... Then I have no more suggestions :(
*** Bug 738593 has been marked as a duplicate of this bug. ***
*** Bug 739062 has been marked as a duplicate of this bug. ***
*** Bug 739126 has been marked as a duplicate of this bug. ***
(In reply to comment #2) > It there anything in the gnucash trace file [1] that is generated during for > the hanging session ? > > [1] http://wiki.gnucash.org/wiki/Tracefile for the freezing on exit problem in windows 7 I found the following in the gnucash log: * 12:20:41 WARN <Pango> 'c:/gcdev/gnome/lib/pango\1.8.0\modules\pango-basic-win32.dll': The specified module could not be found.
I think I know what the problem is: We need a freshly-built WebKit. I managed to get that done by hand on my local machine and it seemed to fix the problem, but I've had trouble transferring it to the build machine for building a distributable package for you guys to test. I'll let you know as soon as I have something ready for you.
*** Bug 739556 has been marked as a duplicate of this bug. ***
*** Bug 739852 has been marked as a duplicate of this bug. ***
I have at long last gotten the immediate problems out of the build with a new WebKit and new Gtk stack. Please download it from http://code.gnucash.org/builds/win32/maint/gnucash-2.6.4-2014-11-10-git-766bb51+-setup.exe and test it; if it works well we'll do a new release. Note that this is a maintenance branch snapshot, not the 2.6.4 release, so some of the other 2.6.4 bugs are fixed as well.
I have downloaded today's build (2014-11-12). While it installs fine it won't run. During startup it complains that libjpeg-7.dll can't be found. This error happens before any gui is shown. Dependency Walker shows this dll is needed by the new webkit package.
I can confirm that the release is missing libjpeg-7.dll I was able to extract libjpeg-7.dll from the 2.6.4-2 release and the program would start but then complains about missing a gcrypto-xxx.dll. A quick look shows that the maintenance release includes libjpeg-9.dll Seems like there are still some remnants of older packages/dependencies. Things could get dicey if you try to hookup two different versions of the same library, e.g. libjpeg-7 and libjpeg-9.dll. Guess this means unfortunately that many of the libraries might have to be re-built from scratch.
Oh - most important part I forgot to add. After dropping in libjpeg-7, despite missing gcrypto.dll, GnuCash still started up fine, displayed the budget, and I was able to quit via File|Quit _without_any_problems. So good news is that this does appear to fix the problem whatever it was that was forcing a hang on exit.
This is great news. Should I download the version above or wait for the official update?
It's up to you. If you're able to do the surgery that Harold did then you can use the daily; otherwise you should wait for me to rebuild WebKit with the right libjpeg dependency and upload it.
I think I'll wimp out and wait for the official build. Don't have the know how to do the work. :)
*** Bug 740179 has been marked as a duplicate of this bug. ***
We *finally* have a working build: http://code.gnucash.org/builds/win32/maint/gnucash-2.6.4-2014-11-17-git-e59c3e0+-setup.exe Please test!
Just installed the file above and it is running perfect for my everyday use. Opening and closing without any problems. Can't get budget reports to show any graphs only blank pages but this is not a problem as I don't use them very much. I was able to open my file, make an entry and close it with no problems. Great work.
The good news: the freeze on exit has been fixed. Even with open reports GnuCash exists just fine. The bad news: as Hairways already noted none of the graphs work. It seems like javascript is disabled or something similar. There is nothing in the trace file, nor on the console that gives any hint.
Yup. I exported the report and opened it in Chrome and it displayed fine. On the other hand, when I opened it in IE 7 on WinXP it doesn't. libjavascriptcore is present and DependencyWalker doesn't show anything missing, so I'm a bit stumped.
When I opened a saved bar chart report ported over from release 2.4.13 on my Lenovo tower, there was white space where the chart should have been, no title, but the table was correctly shown. I am testing in a Windows 7 environment on a HP Probook laptop machine that, I think, never had the mysterious blank report problem with the 2.4 series Gnucash that sometimes appeared over the last few years. A couple of random thoughts: It seems like if the issue was with one of the tools that you use to generate the Windows build, there would be other program developers having similar issues with their programs. I just noticed that Mozilla is currently having issues with their calendar program that seems to be linked to certain hardware and/or drivers, which they are still working on. I am seeing that problem on my Lenovo tower but not my HP Probook laptop. These may be completely unrelated, or?
(In reply to comment #26) > Yup. I exported the report and opened it in Chrome and it displayed fine. On > the other hand, when I opened it in IE 7 on WinXP it doesn't. > > libjavascriptcore is present and DependencyWalker doesn't show anything > missing, so I'm a bit stumped. I was looking at this page: http://webkitgtk.org/reference/webkitgtk/stable/webkit-environment.html It suggests WebKit can generate some logging that may help debugging this issue. However this only seems to be enabled if webkit itself was built with the --enable-debug switch. When I set WEBKIT_DEBUG in my Windows test box, I get the following entry in the log: WEBKIT_DEBUG is not empty, but this is a release build. Notice that many log messages will only appear in a debug build. And nothing else. Maybe you can upload a webkitgtk package with --enable-debug set for further testing ?
*** Bug 740448 has been marked as a duplicate of this bug. ***
*** Bug 740183 has been marked as a duplicate of this bug. ***
(In reply to comment #28) > And nothing else. Maybe you can upload a webkitgtk package with --enable-debug > set for further testing ? Unfortunately setting that breaks the build by attempting to create a libWebCore.a that's larger than Windows can handle.
Has this issue been solved and replaced by an issue with JQPlot? If so, shouldn't this bug be closed and the future work be documented under Bug 737815? Or is there some residual garbage to deal with?
Maybe I referenced the wrong bug. That one seems to be about the stacked bars issue.
Well, it's true that GnuCash doesn't freeze on exit with the latest WebKit build, but it's not really acceptable that WebKit won't run JavaScript, so I can't really call it a fix. To allay your concerns I changed the bug summary to be more general.
*** Bug 740918 has been marked as a duplicate of this bug. ***
Another issue. OFX imports try to import all transactions to today's date and with no descriptions or memos. This is with files that import correctly in release 2.6.4 in OSX or release 2.4.13 in Windows. This is confirmed in the November 25 weekly build for windows. Please do not shoot the messenger.
OK, I found the problem with WebKit 1.8.3 and JavaScript. Ridiculously simple, and something I thought I'd tested last week, but I guess not: WebKit wasn't finding the jquery files because the uri in the web page started with file://c: instead of the correct file:///c:. The other browsers (including Chrome, which is also WebKit based) were liberal enough to ignore the problem and load the file. David's issue with OFX is resolved by forcing recompilation of LibOFX, so today's maint build solves that too. Please test http://code.gnucash.org/builds/win32/maint/gnucash-2.6.4-2014-12-03-git-a26801a+-setup.exe
As discussed on IRC the build referred to in comment 37 suffers extremely slow startup times when run under Windows XP: from double-clicking the icon to the splash screen appearing it takes 35-45 seconds depending on the machine it was tested on. John didn't see this on his Windows 7 build server. He also reported that he didn't see this startup slowness on Windows XP when building against webkit 1.2.7. David: don't you also test on Windows 7 ? How much time (roughly) does the above build take on your system between starting the application and the splash screen appearing ?
For today's build I have a stripped-down WebKit library that reduces the load time on XP by about half, to around 15 seconds. It also shrinks the download by 20MB. http://code.gnucash.org/builds/win32/maint/gnucash-2.6.4-2014-12-06-git-a6230fb+-setup.exe
Testing the December 6 build in Windows 7 with 8 G of RAM on a very large compressed XML data file with a couple of reports left open it opens in 2 min 40 sec, which is noticeably faster than release 2.4.13 was on this machine. Some reports with few accounts seem to open almost instantly. Nice! So far, the program has not crashed and charts are visible. I did notice a problem with the standard net worth barchart that seems to be losing amounts from one or more accounts (probably investment accounts with sparse price data). I am having trouble selecting some sub-accounts to investigate that further. Right now I am vacationing at a resort with very limited Wi-fi and even very limited cellphone access, so you won't be hearing much from me.
(In reply to comment #39) > For today's build I have a stripped-down WebKit library that reduces the load > time on XP by about half, to around 15 seconds. It also shrinks the download by > 20MB. > http://code.gnucash.org/builds/win32/maint/gnucash-2.6.4-2014-12-06-git-a6230fb+-setup.exe And I tried out rebuilding WebKit with glib's unicode instead of icu. It shrinks the download by ~4M, but slows down loading on XP by 5 seconds.
Everything working fine for me now. Opening and closing no problem. Charts are loading no blank pages. Great work. Thanks for the update.
Fix released in Gnucash-2.6.5.
*** Bug 738668 has been marked as a duplicate of this bug. ***
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=738477. Please update any external references or bookmarks.