GNOME Bugzilla – Bug 602602
CSV Import crash with current svn after importing german credit card balances
Last modified: 2018-06-29 22:31:03 UTC
Created attachment 148246 [details] backtrace from gnucash after importing csv Hi! I just checked out svn (r18431) to see if I can csv import my credit card balances. If I don't delete all the descriptive lines from the file, I get a segmentation fault, after gnucash asks for the account to import the balances to. If I do export MALLOC_CHECK_=3 I get no segfault, but I have to remove all the lines from the file that are not according to specs, in order to get a working import. (I also have to move negative amounts to an extra column.) To me this looks different from the crash in https://bugzilla.gnome.org/show_bug.cgi?id=571161 Backtrace attached, my credit card number (in the filename) removed for obvious reasons, I hope it contains all the information you need, if not, get back to me, I think I can come up with a file to reproduce this. I'll be glad to provide any more information you need. Kind regards Friedel
Thanks for submitting this bugreport. Which libregexp library version do you have installed, if this is possible for you to find out? Also, can you attach a (small) example CSV file which reproduces this crash every time? That would help a lot.
It looks like gnucash-bin is linked against /lib/libpcre.so.3.12.1, which is part of the libpcre3 package (from debian testing): Package: libpcre3 Priority: important Section: libs Installed-Size: 456 Maintainer: Mark Baker <mark@mnb.org.uk> Architecture: amd64 Source: pcre3 Version: 7.8-3 Depends: libc6 (>= 2.3) Conflicts: libpcre3-dev (<= 4.3-3) Size: 214628 Description: Perl 5 Compatible Regular Expression Library - runtime files This is a library of functions to support regular expressions whose syntax and semantics are as close as possible to those of the Perl 5 language. . This package contains the runtime libraries. I will try to come up with a small example file that reproduces the crash. Should be easy, I think.
Created attachment 148417 [details] testcase csv file, looks like a credit card balance export from a german bank Ok, here's what I do: I select import -> csv, get the file, select ';' as separator and deselect ',', choose date, description and balance column and press "OK". Without MALLOC_CHECK_=3 I get a crash the first time, with MALLOC_CHECK_=3 I get the import window again, with complaints about wrong format and when I just press OK a second time, gnucash will also crash and dump core.
I think I provided the info now, so maybe I have to change the status of this bug? The only setting that makes sense is "unconfirmed" now.
I can't see a crash here. The import doesn't work, though, but that's a different (i.e. non-crashing) bug. It looks as if the current importer isn't able to ignore lines, is it? Does it crash also if you remove all the heading lines and use only the valid lines?
Does it crash also if you remove all the heading lines and use only the valid lines?
Sorry for the late answer. No, it does *not* crash if I remove the heading lines. I didn't reproduce with a fresh checkout, though.
From the dates of this report, I gather the bug was reported between 2.2 and 2.4 development cycles. The current stable release is 2.4.11. How much of the original problem still appears in this version ? Also, the new svn trunk branch (working towards 2.6) includes a completely rewritten csv importer. I have used your test case successfully on that version. Given the new cvs importer coming up, I doubt someone will be spending time on the old one for the 2.4 series, so I wonder if this bug isn't better marked as fixed in the next major release ?
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for. Thanks! If the bug still reappears in the upcoming 2.5/2.6 versions, feel free to reopen this bug report.
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=602602. Please update any external references or bookmarks.