GNOME Bugzilla – Bug 775567
Importing QIF file from PayPal crashes GnuCash 2.6.14 on Windows XP service pack 3
Last modified: 2018-06-29 23:52:22 UTC
Created attachment 341313 [details] Screenshot The file "crashes-GnuCash-2.6.14-on-Windows-XP-service-pack-3.QIF" does exactly what it says. The hardware is a Sun
Created attachment 341314 [details] Complete GnuCash file, with QIF file that causes crash. I meant to attach this before. This has the GnuCash file, lock file, plus the QIF file that causes the problem. Note the currency of this is GBP. The transaction is USD. It seemed to crash on an almost empty file too, which had no transactions in it.
Oops, the original got submitted before I intended it. The hardware here is a Sun Ultra 27 running OpenSolaris. The Sun has 24 GB RAM, of which about 1.5 GB is allocated to a Windows XP service pack 3 guest operating system.
The QIF loads for me in an empty file, as well as with your sample file, although your sample file displays the Loading... dialog endlessly. I don't think the importer is causing the crash. BTW, it is better to attach the files separately, rather than in a zip file, since unscrupulous types can embed viruses in zip files...
Didn't crash for me either, also on MacOS. I'll try on an XP VM later. Is there some reason you're running it in Windows instead of natively?
Crashes for me on both Win7 and XP.
The cause of the crash is that there's a Byte Order Mark in the file and gnucash's UTF validate routine doesn't like it.
Is a byte order mark supposed to be there or not? If not, can you be quite specific, and I'll speak to PayPal about it. What byte is it? If I know what it is, I can rip it out with sed, vi or something similar. (Despite this is running on XP, the host operating system is Unix, and I'm much happier in a Unix environment). But irrespective of whatever is in the file, an application should not crash. Dave
(In reply to Dr. David Kirkby from comment #8) > Is a byte order mark supposed to be there or not? If not, can you be quite > specific, and I'll speak to PayPal about it. It's optional. GnuCash should be able to handle it. > > What byte is it? If I know what it is, I can rip it out with sed, vi or > something similar. (Despite this is running on XP, the host operating system > is Unix, and I'm much happier in a Unix environment). It's the first 3 bytes in a UTF-8 encoded file. See https://en.wikipedia.org/wiki/Byte_order_mark > > But irrespective of whatever is in the file, an application should not > crash. Yup.
This problem has been fixed in our software repository. The fix will go into the next software release. Once that release is available, you may want to check for a software upgrade provided by your Linux distribution. Two fixes, actually: One to fix the crash when there's a parsing error and the other to conditionally strip the BOM. David and I weren't able to reproduce the problem on our Macs because the Mac and Linux builds use Guile-2.0, for which there are build problems in MinGW. Guile-2.0 recognizes the BOM and removes it from the stream before passing it on for reading.
(In reply to John Ralls from comment #10) > This problem has been fixed in our software repository. The fix will go into > the next software release. I'm impressed with the speed of the fix - about 31 hours from being reported by a newbie, to being fixed. > Once that release is available, you may want to > check for a software upgrade provided by your Linux distribution. Currently I'm running OpenSolaris on the desktop - not Linux. I only run Linux on a couple of IBM servers for an engineering application, and a Raspberry Pi. But I'll probably built GnuCash from source once I actually get Linux on the desktop, which I hope to do in the next week or two. > Two fixes, actually: One to fix the crash when there's a parsing error and > the other to conditionally strip the BOM. Will the second bit by a user selecting a tick-box, or an automatic decision made by GnuCash? If the former, I would suggest the documentation would need updating too, as this BOM is not exactly an obvious thing to most people. > David and I weren't able to reproduce the problem on our Macs because the > Mac and Linux builds use Guile-2.0, for which there are build problems in > MinGW. Guile-2.0 recognizes the BOM and removes it from the stream before > passing it on for reading. It is amazing how testing on multiple operating systems uncovers bugs. Cheers Dave
Heh, that's a canned blurb courtesy of the Gnome folks. No user action is required for the fix. You might have a go at compiling GnuCash on Solaris. You might have to build all of the dependencies from scratch, in which case you can probably use the build instructions and facilities described in http://wiki.gnucash.org/wiki/MacOSX/Quartz as a starting point.
(In reply to John Ralls from comment #12) > You might have a go at compiling GnuCash on Solaris. You might have to build > all of the dependencies from scratch, in which case you can probably use the > build instructions and facilities described in > http://wiki.gnucash.org/wiki/MacOSX/Quartz as a starting point. It will be too much hassle for an OS I intend get rid of very soon. I bought an identical Sun Ultra 27, have swapped RAM and disks around, so a switch to Linux is going to happen pretty soon. Building open-source software on Solaris takes a lot of effort. There are too many "gnu-isms" as I call them in 99% of Linux software. One program I wrote http://atlc.sourceforge.net/ has been tested on Debian Linux, Slackware Linux, Gentoo Linux, Redhat Linux, Suse Linux, IBM's AIX, Apples's OS X for Mac, HP's HP-UX (both PA-RISC and Itanium), SGI's IRIX, Sun's Solaris, SCO's UNIXWare, HP's Tru64, Cray's UNICOS, NetBSD, OpenBSD and FreeBSD. Dave
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=775567. Please update any external references or bookmarks.