Summary: | Crash after online update | ||
---|---|---|---|
Product: | [Applications] kmymoney | Reporter: | allan <agander93> |
Component: | general | Assignee: | KMyMoney Devel Mailing List <kmymoney-devel> |
Status: | RESOLVED FIXED | ||
Severity: | crash | CC: | asoliverez, nick |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | openSUSE | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
allan
2010-07-02 14:38:27 UTC
Did you click on Update account or in Update All Accounts?? (In reply to comment #1) > Did you click on Update account or in Update All Accounts?? As I said, "Click on Account/Update all Accounts". Update Account was not enabled. When I just did a save after some editing, I received a consistency check warning that a couple of accounts needed to be edited for the recent password fix. These two accounts are with the same institution as the account that I was using when the crash occurred. Both still are mapped, and showing to be updateable. The institution no longer provides an OFX service, and I had unmapped two accounts, but not two other less frequently used ones. I mention this in case it ties in with the crash. Oh, Bu****! Another crash. I was unmapping/editing these two accounts when it happened. I'll raise another bug tomorrow, as it's probably not related. This second crash occurred twice, but this morning, didn't. I was trying to unmap an account and also edit and close it to move the password. After clicking unmap, unmap still was showing in the context menu, and I tried again. Today, after unmapping, the context menu was correct, and there was no crash. I can't now check for the original type of crash as I no longer have a mapped account Are you able to reproduce this crash or it doesn't happen anymore after unmapping all accounts? (In reply to comment #5) > Are you able to reproduce this crash or it doesn't happen anymore after > unmapping all accounts? On doing a save I found that I still had a couple of mapped accounts. Also, I have two other accounts with this bank which are now unmapped. With the two that are still mapped, I can select 'Update account' and get a clean '404' error. Remember, the bank no longer offers an OFX service. If instead, I select 'Update ALL accounts', the crash still occurs. I suppose this suggests that the latter is attempting to update accounts that are not mapped, which presumably, it shouldn't? Shall I leave the mapped accounts mapped, in case you wish a test? What if you press the Update All accounts from other places? Does the crash still happen? When I click Account>Update all accounts, initially I get a dialog that the http request failed, with '404'. Another connect attempt occurs with another similar dialog. The first attempt resulted in a crash, but the second didn't. The third and fourth attempts failed after the first dialog box. The menu 'Update' does nothing apparent. Accounts view, followed by update all accounts worked once, but the second crashed. A final attempt from Ledger view in an unmapped account, update all accounts got past the first dialog box but failed on the second, which may be a credit card account. This 'works on the first but fails on the second' problem could be related to https://bugs.kde.org/show_bug.cgi?id=245233 which I just fixed. Can you update from SVN and see if the problem is still persistant? To comment #6: yes, please do leave those accounts mapped for now. I created a Bugzilla account and left a comment, but FYI, your fix appears to have worked. Thanks! -Mike Thomas Baumgart wrote: > https://bugs.kde.org/show_bug.cgi?id=243439 > > > > > > --- Comment #9 from Thomas Baumgart <ipwizard users sourceforge net> 2010-07-23 11:00:14 --- > This 'works on the first but fails on the second' problem could be related to > https://bugs.kde.org/show_bug.cgi?id=245233 which I just fixed. Can you update > from SVN and see if the problem is still persistant? > > To comment #6: yes, please do leave those accounts mapped for now. > > (In reply to comment #9) > This 'works on the first but fails on the second' problem could be related to > https://bugs.kde.org/show_bug.cgi?id=245233 which I just fixed. Can you update > from SVN and see if the problem is still persistant? > > To comment #6: yes, please do leave those accounts mapped for now. Hello Thomas Now on Version 3.98.2-svn1153479, but, no, sad to say, it still crashes at the same point. To me it looks like m_tmpFile is zero in KOfxDirectConnectDlg::slotOfxFinished() for whatever reason (see frames #6 and #7) in the backtrace in the description of the bug. I have no clue why that can happen. I tried to duplicate it here, but to no avail. I tried to get the 404 from a normal web-server which I received, but did not encounter any crash. SVN commit 1156368 by asoliverez: Checked whether temp file actually exists when checking for connection errors. Please try again whether the crash persists. BUG:243439 M +2 -0 kofxdirectconnectdlg.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1156368 (In reply to comment #13) > SVN commit 1156368 by asoliverez: > > Checked whether temp file actually exists when checking for connection errors. > > Please try again whether the crash persists. > > BUG:243439 > > M +2 -0 kofxdirectconnectdlg.cpp > > > WebSVN link: http://websvn.kde.org/?view=rev&revision=1156368 Numerous attempts to 'Update' and 'Update All' succeeded. Spot on! Thanks. SVN commit 1161121 by tbaumgart: Now really solve the problem. The temp file was not created in the case that a second account was updated at the same institution during an 'Update All' action and the HTTP(S) connection was not closed in between. In this case, the KIO slave does not emit the connected signal which was used to create the temp file. We resolve the issue by creating the temp file when we receive the first batch of data. BUG: 243439 CCMAIL: brendan@coupeware.com M +23 -28 kofxdirectconnectdlg.cpp M +0 -1 kofxdirectconnectdlg.h WebSVN link: http://websvn.kde.org/?view=rev&revision=1161121 (In reply to comment #15) > SVN commit 1161121 by tbaumgart: > > Now really solve the problem. The temp file was not created in the case that a > second account was updated at the same institution during an 'Update All' > action and the HTTP(S) connection was not closed in between. In this case, the > KIO slave does not emit the connected signal which was used to create the temp > file. We resolve the issue by creating the temp file when we receive the first > batch of data. > > BUG: 243439 > CCMAIL: brendan@coupeware.com > > M +23 -28 kofxdirectconnectdlg.cpp > M +0 -1 kofxdirectconnectdlg.h > > > WebSVN link: http://websvn.kde.org/?view=rev&revision=1161121 Yes, that seems to have nailed it! Several attempts all produced '404' responses, with no crash. Many thanks. |