Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.
PasswordSafe no longer launches after the recent Mac java update.
You seem to have CSS turned off.
Please don't fill out this field.
I guess this (https://sourceforge.net/forum/forum.php?thread_id=3017458&forum_id=880712) forum thread is about the same topic.
Over there is a description of a workaround, which has been tested to work (thanks corvi42 for the test).
Besides that I plan to build a V0.8 beta2 Version within the next few days, where this workaround could be included.
BUT I am not sure what happens to Mac users on older Mac OS X versions...
That solution is absolute bunk. You do not need to switch the JVM (though you could). Here's my solution
The solution you describe is exactly the same as in the other thread, namely to replace the swt jar with a 64 bit version (though with a newer swt version).
In order to provide mac users of 32bit <b>and</b> 64bit jvms with a version of java passwordsafe, there is still a need for two build targets in our deployment process.
Okay, my bad. I thought he/she proposed using a different JVM. Thanks!
I have encountered the same problem, and can no longer use PasswordSafe. Is there any workaround available? Is there a plan to resolve this? Thanks!
yea! I was the original poster and I'd been using password gorilla to get at my password file for a few days. glad to have passwordsafe back!
Here's what i did to render pws 0.7.105 useable on Leopard 1.5.8 (i'm still
evaluating PasswordSafeSWT !):
The problem: SWT wants to run 32-bit code, Leopard defaults to launching pws
in a 64-bit environment, but the two don't party. Luckily, leopard seems to
have a 32-bit java envionment available but it is not the default.
Fortunately, you can tweak PasswordSafeSWT.app to 'request' a 32-bit java
machine - thereby enabling pws and your Mac to 'get it on'.
What I did: Go to /Applications and find PasswordSafeSWT.app. Right mouse on
it and select 'Show Package Contents'. The .app is really a directory and not
a file, and doing what I just said will enable you to look into the
subdirectories of 'PasswordSafeSWT.app'. Now you need to do a 1 line edit of
Info.plist. Doubleclick on it to edit it (you are about to do the mac
equivalent of editing a .ini file on windows --- remember when!). Expand the
right-pointy arrow next to "Java" at the bottom of the plist. You
will see an attribute called 'JVMVersion' with property set to
"1.5+". Leave this as it is. Now right-mouse on JVMVersion and
select 'Add row' from your pop-up menu, and Add a new attribute called
'JVMArchs'. Set the Value column of your new row to "i386". Hit the
usual red 'Close' button on this mac window - at which point you'll be asked
to save your changes. Save them.
What you have just done is inserted an 'advisory' directive in your startup
file for this application which will attempt to run with a 32-bit java-
virtual-machine instead of the default (incompatible) 64 bit machine.
My observations whilst testing this workaround are below - I cannot tell
whether this workaround has manifested these bugs, or whether these bugs are
just ... bugs in the code, but first impressions are that the sanity of the
underlying password file seems intact when I run against a version-2 data file
(I'd already created the latter by using the macports command-line version,
called 'pwsafe' and was pleasantly surprised that PasswordSafeSWT could work
with this data file ). Anyways, my list of bugs would be:
So, in summary, I seemed to get an awful lot of program running, just for the
want of adding a single line to a config file ! Happy so far!
thanks for your detailed description, I included this key in the new 0.8 beta
2 release fro macs.
I am bit suprised about the effects with passphrase entry you describe while
testing, they might be due to using a v2 database.
Can you reproduce them with a new passwordsafe created with PasswordSafe SWT
(defaults to v3 database)?
I believe v2 does not support group entries, but that behaviour is still
wrong. Could you file this as a bug, please?
ERROR! The markdown supplied could not be parsed correctly.
Did you forget to surround a code snippet with "~~~~"?
I got a Mac OS X 10.5.8 (Intel) and tried to upgrade passwordsafe v 6.0 to 7
or the 8 beta. Thanks to exchanging the swt.jar () I managed to finally start
the programm. However, I could not open my existing password file. My correct
password is considered invalid and both new versions cannot import the files I
exported previous to the update (neither text nor xml). Help would be much
Actually, it crashes completely. Even if I want to create a new password file.
Stephan, exchanging the swt.jar shouldn't be necessary anymore with
Can you confirm this?
On Snow Leopard 10.6.2 with latest JVM (1.6.0_17), which has a 64-bit hotspot
error message is
java.lang.UnsatisfiedLinkError: Cannot load 64-bit SWT libraries on 32-bit JVM
Then I tried
and the DMG is not mountable.
.7, just like .8, does not work correctly if you sub in the 32-bit SWT. This
is the error
org.eclipse.swt.SWTException: Failed to execute runnable
at org.eclipse.swt.SWT.error(Unknown Source)
at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Unknown Source)
at org.eclipse.swt.widgets.Display.runAsyncMessages(Unknown Source)
at org.eclipse.swt.widgets.Display.readAndDispatch(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
Caused by: java.lang.NullPointerException
at org.eclipse.swt.widgets.Shell.sendToolTipEvent(Unknown Source)
at org.eclipse.swt.widgets.Shell.windowSendEvent(Unknown Source)
at org.eclipse.swt.widgets.Display.windowDelegateProc(Unknown Source)
at org.eclipse.swt.internal.cocoa.OS.objc_msgSendSuper(Native Method)
at org.eclipse.swt.widgets.Display.applicationSendEvent(Unknown Source)
at org.eclipse.swt.widgets.Display.applicationProc(Unknown Source)
at org.eclipse.swt.internal.cocoa.OS.objc_msgSend(Native Method)
at org.eclipse.swt.internal.cocoa.NSApplication.sendEvent(Unknown Source)
at org.pwsafe.passwordsafeswt.dialog.StartupDialog.open(Unknown Source)
at org.eclipse.swt.widgets.RunnableLock.run(Unknown Source)
... 13 more
Please help as if I didn't have my Sourceforge password in Firefox, I would've
had to post as anonymous :)
Try to download again PasswordSafeSWT-0.8-beta3-carbon.dmg.
On my side it is mountable and that's the version I installed. It works with
@nobody, thanks! Indeed
works perfectly now. Great news! Long live Password Safe!