After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 651645 - Windows SVN trunk nightly builds fails to open compressed xml files
Windows SVN trunk nightly builds fails to open compressed xml files
Status: RESOLVED FIXED
Product: GnuCash
Classification: Other
Component: Windows
git-master
Other Windows
: Normal major
: ---
Assigned To: Christian Stimming
Geert Janssens
Depends on:
Blocks:
 
 
Reported: 2011-06-01 15:27 UTC by Bob
Modified: 2018-06-29 22:58 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Trace file with no compression (113.14 KB, text/plain)
2011-06-01 15:28 UTC, Bob
Details
Trace file with compression (99.82 KB, text/plain)
2011-06-01 15:29 UTC, Bob
Details

Description Bob 2011-06-01 15:27:30 UTC
I have noticed that if your preferences are set to compress XML files then you will not be able to open them after a save, you end up with a blank accounts page and selecting View new Accounts page makes no difference.

Non compressed files work OK and I can open a compressed file created by my Windows XP VM on my Linux VM OK so the data is in there OK.

To reproduce I started gnucash with the --nofile option, edit\preference\general to set compress option off, create a new set of accounts and save to XML. If you now open gnucash it works, change the compress option to on and force a save. If you now try to open file you end up with a blank accounts page.

I will attach two trace debug files, one without compression and one with.
Comment 1 Bob 2011-06-01 15:28:13 UTC
Created attachment 189015 [details]
Trace file with no compression
Comment 2 Bob 2011-06-01 15:29:05 UTC
Created attachment 189016 [details]
Trace file with compression
Comment 3 Bob 2011-06-01 15:32:40 UTC
Forgot to mention I think this stems back from 2.4.5 split and all the windows updates that happened as I could not find a successful nightly build there after that did not have this problem and looking at the logs was unsuccessful in trying to find cause.
Comment 4 Christian Stimming 2011-06-01 19:51:21 UTC
(In reply to comment #3)
> Forgot to mention I think this stems back from 2.4.5 split and all the windows
> updates that happened as I could not find a successful nightly build there
> after that did not have this problem and looking at the logs was unsuccessful
> in trying to find cause.

I didn't understand this last statement. Did it work with version 2.4.5, but does not work with 2.4.6? Or does it work with both 2.4.5 and 2.4.6, but not the nightly trunk build?
Comment 5 Bob 2011-06-02 10:39:00 UTC
Sorry for the misunderstanding, 2.4.5 and 2.4.6 work but the nightly trunk builds do not. I tried installing a lot of nightly builds as follows and have just rechecked my findings again...

r20540, installs with copying guile 1.8 dir to 1.6 and works but says its 20525
r20552, installs with copying guile 1.8 dir to 1.6 and works but says its 20525

r20560,20561 and r20570, will not start but get the following error, not sure why I have not seen it before..

'The procedure entry point deflateSetHeader could not be located in the dynamic link library zlib1.dll'

r20596, installs with copying guile 1.8 dir to 1.6 and fails to open a compressed file and results in a blank accounts tab.

The guile directory issue was fixed in a later build, hope this helps.
Comment 6 Christian Stimming 2011-06-02 19:11:10 UTC
Thanks for this details. Indeed any nightly build of trunk between r20525 and something shortly after r20596 didn't compile at all on windows due to the rather large changes in the build system. Your bugreport confirms there is still something broken after those large changes, namely the opening of compressed files.
Comment 7 Rich 2011-06-08 11:46:19 UTC
I have also noticed the same problem, except I did not know it was due to compressed files.
Comment 8 Geert Janssens 2011-10-03 17:03:41 UTC
I finally managed to track this problem back to a bad libxml2. It turned out to be a nice example of dependency hell.

The build scripts in r20596 and later contain rules to build libxml2-2.6.27 instead of using the gnome supplied libxml2 binaries. However, the custom build was done without zlib support, exactly what is needed to open compressed GnuCash data files.

My first attempt to simply enable zlib support in libxml2-2.6.27 failed, because libxml2-2.6.27 is not compatible with the version of zlib we use (1.2.5).

Next try was to use the libxml2-2.7.7 binaries supplied by gnome. This attempt failed as well. It seems these libraries don't export the xmlGenericError function (and some others), causing GnuCash to crash. This may be because I didn't rebuild libbonoboui after this attempt, I haven't tested this route.

Instead I chose to build libxml2-2.7.7 from source WITH zlib support. With this combination, I can open compressed data files again. Patch committed as r21369.

Note for self-builders: you will have to make sure libbonoboui is rebuilt because of the interaction with the gnome module (of which libxml is a part). You can do this by removing the libbonoboui directory (and to be sure also the gnome directory) from your build directory before starting the build.

If the problem still persists after this revision, please reopen the report.
Comment 9 Christian Stimming 2011-10-03 19:25:08 UTC
Impressive! Geert, thanks a lot!
Comment 10 John Ralls 2018-06-29 22:58:30 UTC
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=651645. Please update any external references or bookmarks.