Fedora Account System
Red Hat Associate
Red Hat Customer
+++ This bug was initially created as a clone of Bug #645204 +++ --- Additional comment from bws on 2010-10-25 10:08:37 EDT --- This version of Java (currently in updates) is broken. I've had to downgrade to get anything Java related to reall work. For example, the popular EVO collab tool won't work with Fedora 13 right now: http://evo.caltech.edu/evoNext/koala.jnlp --- Additional comment from omajid on 2010-10-25 10:27:40 EDT --- Hi Brad, (In reply to comment #2) > This version of Java (currently in updates) is broken. I've had to downgrade > to get anything Java related to reall work. For example, the popular EVO > collab tool won't work with Fedora 13 right now: > > http://evo.caltech.edu/evoNext/koala.jnlp This bug report is about a crash in the JVM. Are you getting this crash as well when you run the EVO collab tool? If not, could you please file a separate bug report against java-1.6.0-openjdk? Also please describe the problem in a little more detail. If this is indeed broken, I would really like to identify the problem and fix it. Thanks! --- Additional comment from bws on 2010-10-25 10:57:35 EDT --- I get the following problem: [bws@localhost:~:1050]$ javaws http://evo.caltech.edu/evoNext/koala.jnlpnet.sourceforge.jnlp.LaunchException: Fatal: Launch Error: Could not launch JNLP file. at net.sourceforge.jnlp.Launcher.launchApplication(Launcher.java:462) at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:731) Caused by: java.lang.RuntimeException: Unable to create locks directory (/tmp/bws/netx/locks) at net.sourceforge.jnlp.services.SingleInstanceLock.getLockFile(SingleInstanceLock.java:132) at net.sourceforge.jnlp.services.SingleInstanceLock.<init>(SingleInstanceLock.java:55) at net.sourceforge.jnlp.services.XSingleInstanceService.checkSingleInstanceRunning(XSingleInstanceService.java:131) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at net.sourceforge.jnlp.services.ServiceUtil$PrivilegedHandler$1.run(ServiceUtil.java:187) at java.security.AccessController.doPrivileged(Native Method) at net.sourceforge.jnlp.services.ServiceUtil$PrivilegedHandler.invoke(ServiceUtil.java:192) at net.sourceforge.jnlp.services.$Proxy9.checkSingleInstanceRunning(Unknown Source) at net.sourceforge.jnlp.services.ServiceUtil.checkExistingSingleInstance(ServiceUtil.java:139) at net.sourceforge.jnlp.Launcher.launchApplication(Launcher.java:389) ... 1 more Caused by: java.lang.RuntimeException: Unable to create locks directory (/tmp/bws/netx/locks) at net.sourceforge.jnlp.services.SingleInstanceLock.getLockFile(SingleInstanceLock.java:132) at net.sourceforge.jnlp.services.SingleInstanceLock.<init>(SingleInstanceLock.java:55) at net.sourceforge.jnlp.services.XSingleInstanceService.checkSingleInstanceRunning(XSingleInstanceService.java:131) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at net.sourceforge.jnlp.services.ServiceUtil$PrivilegedHandler$1.run(ServiceUtil.java:187) at java.security.AccessController.doPrivileged(Native Method) at net.sourceforge.jnlp.services.ServiceUtil$PrivilegedHandler.invoke(ServiceUtil.java:192) at net.sourceforge.jnlp.services.$Proxy9.checkSingleInstanceRunning(Unknown Source) at net.sourceforge.jnlp.services.ServiceUtil.checkExistingSingleInstance(ServiceUtil.java:139) at net.sourceforge.jnlp.Launcher.launchApplication(Launcher.java:389) at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:731) I suppose that is not a sigabrt, but an unhandled exception. Whatever it is, I've had to yum downgrade to get *anything* java related to work after this upgrade. Including my payroll application which caused me a large degree of consternation of course. Let me know if I should enter an new bug report. There are so many bugs open on OpenJDK I just kind of assumed that everyone had the same problem. I wanted to provide a simple test case -- EVO. --- Additional comment from bws on 2010-10-25 10:59:56 EDT --- Crap, ignore this. I assumed two of the same problem were related. My payroll application is indeed broken. Maybe its as simple as a stale lock directory as well.
Netx (the javaws implementation in the java-1.6.0-openjdk package) creates this locks directory: Caused by: java.lang.RuntimeException: Unable to create locks directory (/tmp/bws/netx/locks) Netx needs a directory to hold locks (which is required by the SingleInstanceService api), but cant create/find it. Is this directory write protected? Are you not allowed to create this directory?
Any updates on this? Are you still having issues with java-1.6.0-openjdk's javaws? If you do have any problems with javaws, please let me know, and I will attempt to get them fixed upstream.
Ping. Is this still a problem? Is there a publicly available reproducer somewhere?
This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '13'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 13's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 13 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.