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.

Close

Recent Mac Java update renders 0.7 useless

2009-06-24
2012-09-17
  • PasswordSafe no longer launches after the recent Mac java update.

     
    • David
      David
      2009-06-24

      Hi all,

      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...

      Cheers,
      Roxon

       
    • 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:

    • Preferences: anything to do with re-entering the password to unlock the database, doesn't work. It could just be that the 're-enter database password' dialog box is screwed. The good news is that your master password will still work when you launch the app, so best advice is not to 'enable' any of the Security preferences that will re-lock the database eg after inactivity, minimization etc.
    • Dont 'omit' to assign a Group to any entry, leastways when using a verision-2 database file format. Nothing bad will happen, but it makes your GUI listing of passwords look cosmetically strange if you dont enter a Group assignation (ie the integrity of the password database is not affected).

    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!

     
  • David
    David
    2009-10-14

    Hi nobody,

    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
    appreciated.
    
    
    Stephan
    
    
    : [http://sourceforge.net/projects/jpwsafe/forums/forum/880712/topic/3378720](
    http://sourceforge.net/projects/jpwsafe/forums/forum/880712/topic/3378720)
    
    
     
  • Actually, it crashes completely. Even if I want to create a new password file.

    Stephan

     
  • David
    David
    2009-11-12

    Stephan, exchanging the swt.jar shouldn't be necessary anymore with
    PasswordSafeSWT-0.8-beta2a.dmg download.

    Can you confirm this?

     
  • On Snow Leopard 10.6.2 with latest JVM (1.6.0_17), which has a 64-bit hotspot
    JVM.

    Just tried

    PasswordSafeSWT-0.8-beta3-x86_64.dmg

    error message is

    java.lang.UnsatisfiedLinkError: Cannot load 64-bit SWT libraries on 32-bit JVM

    Then I tried

    PasswordSafeSWT-0.8-beta3-carbon.dmg

    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
    (java.lang.NullPointerException)

    at org.eclipse.swt.SWT.error(Unknown Source)

    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 org.eclipse.jface.window.Window.runEventLoop(Window.java:825)

    at org.eclipse.jface.window.Window.open(Window.java:801)

    at
    org.pwsafe.passwordsafeswt.PasswordSafeJFace.main(PasswordSafeJFace.java:486)

    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

    at
    sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)

    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImp
    l.java:25)

    at java.lang.reflect.Method.invoke(Method.java:597)

    at apple.launcher.LaunchRunner.run(LaunchRunner.java:115)

    at apple.launcher.LaunchRunner.callMain(LaunchRunner.java:50)

    at
    apple.launcher.JavaApplicationLauncher.launch(JavaApplicationLauncher.java:52)

    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.eclipse.swt.widgets.Display.readAndDispatch(Unknown Source)

    at org.pwsafe.passwordsafeswt.dialog.StartupDialog.open(Unknown Source)

    at org.pwsafe.passwordsafeswt.PasswordSafeJFace.displayOpeningDialog(PasswordS
    afeJFace.java:206)

    at org.pwsafe.passwordsafeswt.PasswordSafeJFace.access$0(PasswordSafeJFace.jav
    a:199)

    at
    org.pwsafe.passwordsafeswt.PasswordSafeJFace$1.run(PasswordSafeJFace.java:238)

    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 :)

    THANKS!

     
  • 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
    10.6.2 1.6.0_17

     
  • @nobody, thanks! Indeed

    PasswordSafeSWT-0.8-beta3-carbon.dmg

    works perfectly now. Great news! Long live Password Safe!

     


Anonymous


Cancel   Add attachments