Menu

#1378 V3.40 crash

v1.0_(example)
closed
nobody
None
1
2016-12-09
2016-09-26
pete
No

This morning on 2 different computers PasswordSafe V3.40 crashed after I'd entered the password to unlock the app. Both cases it was Win10. Identical copies of the database were being used. Upon crashing, I got the pop-up to forward information about the crash and I gave it permission to do so. In both cases, the instance of PWS had been running for more than 1 day and I'd used it without any problems several times. I restarted and PWS seemed to be running fine.

Related

Bugs: #1376

Discussion

  • Rony Shapiro

    Rony Shapiro - 2016-09-26

    Thanks for reporting this.

    The information is in a generated file that's described in the error message. If possible, attach it to this ticket via the "Add attachments" link to the right of the Post button.

     
  • pete

    pete - 2016-09-26

    Ooops, thought the dump files were forwarded automatically. Here they are. They are from 2 different computers and were located in C:\Users\USERNAME\AppData\Local\Temp directory.

     
  • Rony Shapiro

    Rony Shapiro - 2016-09-27

    Both "minidump" files show a crash after double-clicking on an entry, possibly after clicking on OK on the Edit window. Nothing obviously wrong.

    Was the database in question created or editied by another application, such as an Android or iOS clone of PasswordSafe?

    Does this happen when you doble-click on any entry in the database?

    Can you reproduce this on a "dummy" database?

     
  • pete

    pete - 2016-09-27

    It just happened again, twice within a few hours on the same computer. New minidump files are attached. It is definitely when I hit enter after typing the password. To answer your 2nd question, I can double-click on an entry and it opens another window for editing the entry; i.e. no problems there.

    Your first question, may or may not be significant. I use synctoy to automatically push the PWS DB from a master computer to a "slave" computer. Albeit, the master computer did have one crash. And the crashes today were both on the slave computer and the last push of DB was yesterday morning. So it would appear that in 3 of the 4 crashes, the synctoy reading or writing the DB wouldn't be a factor.

    My normal way of using PWS is to double-click an entry to launch the edit window which allows changing an entry. But I don't edit and I just leave it up and after some time, the app will transition to the state where I need to enter the master PW. And usually (i.e. when things are working) after entering the master PW, then I'll usually be back in the previously opened edit entry window. I tried purposely leaving the edit window open, letting the timeout lock the app. I tried once where I left "unsaved" edits in the window (didn't hit the apply button) and another time where I didn't do any edit (which is my standard way of operating). In neither case did it crash. I'll try some more variations like highlighting stuff in the edit window, etc.

     
  • Rony Shapiro

    Rony Shapiro - 2016-09-28

    3.40 has a more, er, active approach to writing the database when changes are made.

    My guess is that the modified database is being read upon unlock and something is changing that the edit window didn't expect, henve the crash, and that's why it appears to me to be in the edit window code.

    As a workaround, you might want to uncheck the "Save database immediately after any change" in Manage->Options...->Backups.

     
  • pete

    pete - 2016-09-29

    Thanks for your timely analysis and suggestions. It has happened at least one more time since the last posting. For now at least, I'm going to leave the option enabled to aggressively save changes. I'm kind of intrigued with coming up with a way to recreate the problem. And when it crashes, it is just a matter of relaunching the app and there's no lasting damage that I'm aware of.

     
  • DrK

    DrK - 2016-10-17

    Fixed with commit ce13622. Will be in next release.

    The cause is that we didn't handle correctly the case when an Add/Edit dialog is open when the database is locked (normally via the idle time-out). Before the next release, I suggest that you complete/cancel any Add/Edit before the time-out occurs or significantly increase the time-out value.

    I suggest that Rony, as Admin, moves this to Bug Reports.

     

    Last edit: DrK 2016-10-18
  • Rony Shapiro

    Rony Shapiro - 2016-10-26

    Ticket moved from /p/passwordsafe/support-requests/476/

     
  • Rony Shapiro

    Rony Shapiro - 2016-11-02
    • status: open --> pending
     
  • Rony Shapiro

    Rony Shapiro - 2016-12-09
    • Status: pending --> closed
     

Log in to post a comment.