JDK-4398496 : merlin b45, 1.4.0+ and 1.4.1+: "Couldn't flush system prefs..." thrown
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util
  • Affected Version: wtk2.0_fcs-b2,1.3.0,1.4.0,1.4.1
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS:
    generic,linux,solaris_1,solaris_2.6,solaris_7 generic,linux,solaris_1,solaris_2.6,solaris_7
  • CPU: generic,x86,sparc
  • Submitted: 2000-12-15
  • Updated: 2003-01-10
  • Resolved: 2003-01-08
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
1.4.2 betaFixed
Related Reports
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Relates :  
Description
Please see the Comments area and Evaluation for the latest update. The bug is still in 1.4.1+ and 1.4.0+ releases.

###@###.### 2003-01-08
======================================================================
Run the attached test, when finish, close window, the following message is thrown, and it continues, until you explicitly kill the process:

Couldn't flush system prefs: java.util.prefs.BackingStoreException: Couldn't get file lock.



ingrid.yao@Eng 2001-01-04

Forte tool group also reports the same problem:
J2SE Version (please include all output from java -version flag):

	cruella<257> /export/home2/jdk1.4.0/bin/java -version
	java version "1.4.0-beta"
	Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-beta-b46)
	Java HotSpot(TM) Client VM (build 1.4beta-B45, mixed mode)

Does this problem occur on J2SE 1.3?  Yes / No (pick one)

	No. it works fine with Meriln build 44.

Operating System Configuration Information (be specific):

	uname: SunOS cruella 5.6 Generic_105181-20 sun4u sparc SUNW,Ultra-60
	uptime: 12:37pm up 55 day(s), 2:12, 2 users, load average: 0.02, 0.11, 0.31

Hardware Configuration Information (be specific):

	model: SUNW,Ultra-60
	memory: Memory size: 512 Megabytes
	cpu: 2 at 360 MHz,

Bug Description:





Steps to Reproduce (be specific):


    1. Download FFJ Community Edition from:	
	http://edist.central/edist-cgi/showtool.cgi?tool=Forte+for+Java&version=2.0
	(Download the file: forte_ce_2.class)
	
    2. Install it
    	/usr/j2se/bin/java forte_ce_2	
	<InstallShield starts... do the obvious>

    3. Assuming you have a jdk 1.3 available at /usr/j2se, you should be able
    	to just start it up with no errors:   	
    	./forte4j/bin/runide.sh
    	
    4. Run it with 1.4 b46 as follows:   
        ./forte4j/bin/runide.sh -jdkhome /export/home2/jdk1.4.0
    	
    	And you get a raft of exceptions, look at file:
    		./forte4j/system/ide.log

*********** Exception occurred ************

Couldn't flush system prefs: java.util.prefs.BackingStoreException: Couldn't get file lock.
Exception in thread "main" java.lang.InternalError
        at sun.misc.ClassReflector$2.run(ClassReflector.java:1072)
        at java.security.AccessController.doPrivileged(Native Method)
        at sun.misc.ClassReflector.createClassReflector(ClassReflector.java:1055)
        at sun.misc.ClassReflector.getClassReflector(ClassReflector.java:1043)
        at sun.misc.ClassReflector.access$100(ClassReflector.java:27)
        at sun.misc.ClassReflector$Factory.getClassReflector(ClassReflector.java:87)
        at java.io.ObjectStreamClass.validateClass(ObjectStreamClass.java:384)
        at java.io.ObjectStreamClass.initNonProxyDesc(ObjectStreamClass.java:302)
        at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1373)
        at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1288)
        at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1373)
        at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1288)
        at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1489)
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1161)
        at java.io.ObjectInputStream.readObject(ObjectInputStream.java:283)
        at org.netbeans.core.NbProjectOperation.openOrCreateProject(NbProjectOperation.java:172)
        at org.netbeans.core.NonGui.run(NonGui.java:400)
        at org.netbeans.core.Main.run(Main.java:191)
        at org.openide.TopManager.initializeTopManager(TopManager.java:120)
        at org.openide.TopManager.getDefault(TopManager.java:81)
        at org.netbeans.core.Main.main(Main.java:275)

    	

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mantis-beta merlin merlin-beta FIXED IN: mantis-beta INTEGRATED IN: mantis-beta VERIFIED IN: mantis-beta
14-06-2004

PUBLIC COMMENTS User did not have write permissions on lock files. The bug was fixed by moving lock files to /tmp/.
10-06-2004

EVALUATION Needs to be fixed minchi.tien@eng, 01-12-2001 ----------------------------------------------- This bug still occurs in 1.4.1 as well as 1.4.0_01 ###@###.### 2002-12-09 ----------------------------------------------- I retested with 1.4.1, 1.4.0_01 and 1.4.2 b09, I don't see the bug in any of the build. Maybe they need to install some patches? ###@###.### 2002-12-10 ----------------------------------------------- System prefs are normally rooted at /etc/.java/.systemPrefs in a "local install", or <java.home>/.systemPrefs in a "network install." (The install type is specified to the installation script--I believe that "local install" is the default.) This can be overridden by setting the System Property java.util.prefs.systemRoot, in which case user prefs are rooted at <java.util.prefs.systemRoot>/.systemPrefs. In 1.4.0, the Solaris Java installation script didn't create a system prefs directory. In 1.4.1, the script lets you choose which system prefs directory to create. In both releases, if the system root directory does not exist, the application attempts to create it the first time it attempts to use prefs. If the java.util.prefs.systemRoot system Property is set, this is where the application attempts to create system prefs. Otherwise it attempts to use /etc/.java/. If the attempt fails, it tries to create a directory in <java.home> as a last resort. In either case, the creation attempt generally fails. Except for a few details, the behavior of the Unix prefs implementation didn't change between 1.4.0 and 1.4.1. The directory creation attempt generally fails at run time, but there is one key difference: in 1.4.0, it failed *silently*. In 1.4.1, it emits a warning (using the logging API). The warnings can generally be ignored, as few applications actually use system prefs, but they are very annoying. There are several ways to work around the problem: (1) Create the standard system prefs directory ("/etc/.java/.systemPrefs") manually; (2) Specify an alternate system prefs directory where user has write permission, via the System Property java.util.prefs.systemRoot. In Mantis (1.4.2), applications that use only user prefs (not system prefs) will not even attempt to initialize system prefs, which should eliminate the spurious warnings. ###@###.### 2003-01-08 ========================================================================== verified in mantis b12, not reproducible. ###@###.### 2003-01-10 ==========================================================================
10-01-2003