Description of problem: 1. invoke MyPasswordSafe 2. enter password *** stack smashing detected ***: MyPasswordSafe terminated Version-Release number of selected component: MyPasswordSafe-0.6.7-18.20061216.fc20 Additional info: reporter: libreport-2.1.9 backtrace_rating: 4 cmdline: MyPasswordSafe crash_function: GenRandhash executable: /usr/bin/MyPasswordSafe kernel: 3.11.10-301.fc20.x86_64 runlevel: N 5 type: CCpp uid: 1000 Truncated backtrace: Thread no. 1 (10 frames) #5 GenRandhash at src/pwsafe/Util.cpp:116 #6 BlowfishLizer::checkPassword at src/serializers.cpp:212 #7 Safe::checkPassword at src/safe.cpp:537 #8 MyPasswordSafe::open at src/mypasswordsafe.ui.h:245 #9 StartupDlgBase::okClicked at src/startupdlgbase.ui.h:55 #10 StartupDlgBase::qt_invoke at .moc/moc_startupdlgbase.cpp:115 #11 QObject::activate_signal at kernel/qobject.cpp:2359 #13 QButton::clicked at .moc/release-shared-mt/moc_qbutton.cpp:152 #14 QDialog::keyPressEvent at dialogs/qdialog.cpp:574 #15 QWidget::event at kernel/qwidget.cpp:4751
Created attachment 836090 [details] File: backtrace
Created attachment 836091 [details] File: cgroup
Created attachment 836092 [details] File: core_backtrace
Created attachment 836093 [details] File: dso_list
Created attachment 836094 [details] File: environ
Created attachment 836095 [details] File: limits
Created attachment 836096 [details] File: maps
Created attachment 836097 [details] File: open_fds
Created attachment 836098 [details] File: proc_pid_status
Created attachment 836099 [details] File: var_log_messages
I hope this gets fixed soon, since it's been my password manager for a couple of years, and it was working in F19. Unfortunately, there seems to have been no updates for it the whole time.
i tried to duplicate the crash on 32-bit. It came up properly, but it was already configured on that machine using the F19 config settings. On the 64-bit machine where it crashes, I have to configure it from scratch, and due to the crash, the settings don't stick. Where are the config files for MyPasswordSafe located? I could try copying the old F19 config files to see if that works around the crash.
I'm not on F20 yet, and I cannot reproduce this under F19. I've had a look at the code, and I'm at a bit of a loss how it manages to trash it's stack there. Will try again after upgrade.
Both of my F20 machines are clean installs, and contain identical copies of safe.dat. But the one where the bug doesn't happen apparently has a copy of whatever config file(s) suppress the Info/License/Credits screen and remember where my default safe is, since on that machine it immediately asks for the pass-phrase for /home/$USER/safe.dat. The machine where the bug happens doesn't have a copy of those config file(s), since it shows the intro screen, which I dismiss, then asks what I would like to do (Create new safe/Browse/Create new safe), then I tell it to "Open default safe" and select safe.dat, then I enter my pass-phrase for /home/andre/safe.dat, and at that instant it crashes. Currently, I'm running strace on MyPasswordSafe to try to figure out what config file(s) tell it to suppress the intro screen, and remember where my default safe is. It's well hidden. My guess is that if I can copy over my copy of my F19 config file, it may suppress the bug. If you want to try to reproduce this in F19, you would have to delete those files (but keep a copy in case the bug exists in F19 as well).
I found that the config file is /home/$USER/.qt/mypasswordsaferc, and I was able to copy it over, so that MyPasswordSafe starts on both machines without the intro screen. Unfortunately, it still crashes on the 64-bit machine, but not on the 32-bit one, so that wasn't the problem.
I tested on another 32-bit machine, also with a clean F20 install, and MyPasswordSafe doesn't crash on that, either. It even runs without crashing if I delete /home/$USER/.qt/mypasswordsaferc and allow it to be recreated. So this bug may be limited to 64-bit. I was able to generate an strace file < 300K by running "strace -f -o MyPasswordSafe.txt MyPasswordSafe" after copying over the config file (to eliminate all the irrelevant activity caused by creating it). I'm not sure if there is any sensitive info in it (the crash only happens after entering my pass-phrase) but I could at least provide selected parts of it if it would help.
I have found this additional scenario which might be of help. I have two identitical 64 bit systems, one running F19 with a working MyPassordSafe and the other running F20 (RC1.1) with a fresh F20 MyPasswordSafe installation using the configuration and data files from the F19 system. The F20 MPS crashes as described above. Also regenerating the MPS executable from source on the F20 system with rpmbuild --rebuild continues to result in the crash. Now the interesting part, if you copy the /usr/bin/MyPasswordSafe executable from the working F19 system to the F20 system then we have normal operation on F20 with no further crash. Does this suggest that there is an issue or interaction with the F20 build environment?
I believe this is a compiler issue, although at a quick glance I cannot see any major changes between F19 and F20. There's also a new glibc. I need to get my hands on an F20 system to reproduce this.
(In reply to Bob Whitinger from comment #17) > Now the interesting part, if you copy the /usr/bin/MyPasswordSafe executable > from the working F19 system to the F20 system then we have normal operation > on F20 with no further crash. I confirm that if I extract the files in the F19 x86_64 RPM with the command rpm2cpio MyPasswordSafe-0.6.7-16.20061216.fc19.x86_64.rpm | cpio -idmv and use the executable ./usr/bin/MyPasswordSafe , that runs in F20 x86_64 without crashing. Nice workaround.
Same crash on 64-bit Rawhide. The Versions are essentially the same as F20 except for glibc. gcc-4.8.2-7.fc21.x86_64 glibc-2.18.90-17.fc21.x86_64 MyPasswordSafe-0.6.7-18.20061216.fc20.x86_64
Reducing the Severity to "high" since using the F19 x86_64 binary as in comment 19 has been working fine for me.
I've located the issue (an array overflow on the stack that's found by -fstack-protector-strong introduced by the F20 build system. This is reproducible on F19 if this flag is introduced into the build). I'll build an updated version this evening.
*** Bug 1037804 has been marked as a duplicate of this bug. ***
MyPasswordSafe-0.6.7-19.20061216.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/MyPasswordSafe-0.6.7-19.20061216.fc20
MyPasswordSafe-0.6.7-19.20061216.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/MyPasswordSafe-0.6.7-19.20061216.fc19
Package MyPasswordSafe-0.6.7-19.20061216.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing MyPasswordSafe-0.6.7-19.20061216.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-23812/MyPasswordSafe-0.6.7-19.20061216.fc19 then log in and leave karma (feedback).
Another user experienced a similar problem: gave the wrong password, but it crashes just like when the right password is given. reporter: libreport-2.1.10 backtrace_rating: 4 cmdline: MyPasswordSafe crash_function: GenRandhash executable: /usr/bin/MyPasswordSafe kernel: 3.12.5-302.fc20.x86_64 package: MyPasswordSafe-0.6.7-18.20061216.fc20 reason: MyPasswordSafe killed by SIGABRT runlevel: N 5 type: CCpp uid: 1002
MyPasswordSafe-0.6.7-19.20061216.fc20.x86_64 fixed the problem for me too. Works. "# rpm -q --changelog MyPasswordSafe | head -3 * Sat Dec 21 2013 Ralf Ertzinger <ralf (atta) skytale.net> - 0.6.7-19.20061216 - Fix stack trashing due to wrong size calculation, closes bz1042667 - Fix compiler warnings about narrowing longs into chars"
MyPasswordSafe-0.6.7-19.20061216.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
MyPasswordSafe-0.6.7-19.20061216.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.