Importing a gnucash file from gnucash version 2.6.1. After approximately 65% completion (not sure exact percentage), KMyMoney crashed with a floating point exception. The crash can be reproduced every time. Reproducible: Always Steps to Reproduce: 1. Save data as file in gnucash. 2. Open KMyMoney. 3. Import from the gnucash file. Various import options have no effect on crashing. Actual Results: KMM crashed. Expected Results: KMM should have finished importing the data. I saved the backtrace but the web page has no option for attaching it? Email me if you need the file.
Created attachment 88538 [details] backtrace from the crash
Please specifiy the KMyMoney version you are using. Use Help/About to find out. Thx.
(In reply to Thomas Baumgart from comment #2) > Please specifiy the KMyMoney version you are using. Use Help/About to find > out. Thx. version 4.9.5
That looks more like the KDE version rather than the. KMM one. Allan moore3t1@cox.net wrote: >https://bugs.kde.org/show_bug.cgi?id=338772 > >--- Comment #3 from moore3t1@cox.net --- >(In reply to Thomas Baumgart from comment #2) >> Please specifiy the KMyMoney version you are using. Use Help/About to find >> out. Thx. > >version 4.9.5 > >-- >You are receiving this mail because: >You are the assignee for the bug. >_______________________________________________ >KMyMoney-devel mailing list >KMyMoney-devel@kde.org >https://mail.kde.org/mailman/listinfo/kmymoney-devel
Sorry, my mistake. It is version 4.6.3.
I traced this down to a number of transactions that had "quantity 0". These were stock transactions. I removed the transactions and the import no longer crashes. I originally migrated to gnucash from Quicken so it may be that these transactions were artifacts of the import from Quicken. In fact, the "date-entered" field matches the date I did the import.
Could you then create a gnucash test file that has such a transaction? I'm not really familiar with the format that's why I would like to ask you to do it. I take that you have an idea of how to enter such a transaction. KMyMoney should not crash regardless of the validity of the imported data.
Created attachment 88957 [details] attachment-28108-0.html Cristian, I will work on creating a "small-as-possible" and sanitized version you can try. I think it will crash with just the single transaction, so I just need to remove account information not related to that transaction. -- Richard On Thu, Oct 2, 2014 at 10:10 PM, Cristian Oneț <onet.cristian@gmail.com> wrote: > https://bugs.kde.org/show_bug.cgi?id=338772 > > Cristian Oneț <onet.cristian@gmail.com> changed: > > What |Removed |Added > > ---------------------------------------------------------------------------- > Resolution|--- |WAITINGFORINFO > CC| |onet.cristian@gmail.com > Status|UNCONFIRMED |NEEDSINFO > > --- Comment #7 from Cristian Oneț <onet.cristian@gmail.com> --- > Could you then create a gnucash test file that has such a transaction? I'm > not > really familiar with the format that's why I would like to ask you to do > it. I > take that you have an idea of how to enter such a transaction. KMyMoney > should > not crash regardless of the validity of the imported data. > > -- > You are receiving this mail because: > You reported the bug. > You are on the CC list for the bug.
Created attachment 88958 [details] Small test case that produces the floating point exception on import This file contains a single transaction that triggers a floating point exception when imported into KMyMoney.
A strange first split, showing a quantity of zero having a value while the second split of the transaction seems to show correct values. Not sure in which context this could be valid at all or how one can construct such a transaction. Nevertheless, the KMyMoney importer should not crash, that's for sure. <trn:splits> <trn:split> <split:id type="guid">3f5850433a06212fa573b1221ab17ec2</split:id> <split:memo>Realized Gain/Loss</split:memo> <split:reconciled-state>n</split:reconciled-state> <split:value>80000/100</split:value> <split:quantity>0/100000</split:quantity> <split:account type="guid">568b0b8ffa5584493960a9b97e7cc93b</split:account> <split:lot type="guid">8813b72f9bc537f51a2654b5be83a471</split:lot> <split:slots> <slot> <slot:key>gains-source</slot:key> <slot:value type="guid">1037a1c99592722061a0742a47d8fc1f</slot:value> </slot> </split:slots> </trn:split> <trn:split> <split:id type="guid">fcc21b4cee86b2f8de32cb6d9063428a</split:id> <split:memo>Realized Gain/Loss</split:memo> <split:reconciled-state>n</split:reconciled-state> <split:value>-80000/100</split:value> <split:quantity>-80000/100</split:quantity> <split:account type="guid">76c0a62de5ca4047cb09a56e4f70b1b9</split:account> </trn:split> </trn:splits>
Created attachment 88973 [details] attachment-20999-0.html As I mentioned, I think Gnucash constructed this transaction (and others like it) when I imported from Quicken. When I found the matching transactions in GC and removed them, it had no effect on balances and I was subsequently able to import to KMM. - Richard On Oct 5, 2014 1:01 AM, "Thomas Baumgart" <ipwizard@users.sourceforge.net> wrote: > https://bugs.kde.org/show_bug.cgi?id=338772 > > --- Comment #10 from Thomas Baumgart <ipwizard@users.sourceforge.net> --- > A strange first split, showing a quantity of zero having a value while the > second split of the transaction seems to show correct values. Not sure in > which > context this could be valid at all or how one can construct such a > transaction. > Nevertheless, the KMyMoney importer should not crash, that's for sure. > > <trn:splits> > <trn:split> > <split:id type="guid">3f5850433a06212fa573b1221ab17ec2</split:id> > <split:memo>Realized Gain/Loss</split:memo> > <split:reconciled-state>n</split:reconciled-state> > <split:value>80000/100</split:value> > <split:quantity>0/100000</split:quantity> > <split:account > type="guid">568b0b8ffa5584493960a9b97e7cc93b</split:account> > <split:lot type="guid">8813b72f9bc537f51a2654b5be83a471</split:lot> > <split:slots> > <slot> > <slot:key>gains-source</slot:key> > <slot:value > type="guid">1037a1c99592722061a0742a47d8fc1f</slot:value> > </slot> > </split:slots> > </trn:split> > <trn:split> > <split:id type="guid">fcc21b4cee86b2f8de32cb6d9063428a</split:id> > <split:memo>Realized Gain/Loss</split:memo> > <split:reconciled-state>n</split:reconciled-state> > <split:value>-80000/100</split:value> > <split:quantity>-80000/100</split:quantity> > <split:account > type="guid">76c0a62de5ca4047cb09a56e4f70b1b9</split:account> > </trn:split> > </trn:splits> > > -- > You are receiving this mail because: > You reported the bug. > You are on the CC list for the bug. >
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days, the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please set the bug status as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!