Re: jdk16 and suite derbyall - 128 failures

[Ole Solberg]

Olav Sandstaa wrote:

Rick Hillegas wrote:

396638 enabled driver autoloading (DERBY-930). It's the patch which required us to migrate to Mustang build 81--that build fixes a bug which short-circuited autoloading from jar files under a SecurityManager. With DERBY-930 in place, the vm will execute its autoloading logic when running against jar files. Without DERBY-930, autoloading will not be triggered. Have you tried running against an older Mustang build with DERBY-930 in place?

I have run it with build 81 and build 84. I could try to run it against build 78? But as I wrote in the reply to David, I am not convinced this is a VM bug/problem.

I did a *build and test* on 396638 with b78: nist fails.

Inspecting the directory where derbyall is executed: "..../testDir/" I observe that *.diff, *.out, *.tmp, *.tmpstr etc. files and a nist directory from the derbyall/nist test run is placed in the 'top level' "testDir/", while for other sub-suites the "suite" directories are put inside "..../testDir/derbyall/". There is also a nist directory inside "..../testDir/derbyall/", but that is empty. It seems like the nist test creates "..../testDir/derbyall/nist/", but then writes to "..../testDir/" instead of "..../testDir/derbyall/nist/"?

DERBY-930 makes a couple changes. It would be interesting to see what happens if you back out all of DERBY-930 and just apply its build.xml changes. Those are the changes which trigger autoloading. This would help us tease apart whether we have a vm bug or some regression introduced by the other changes in DERBY-930.

This is on my list of things to try out, but I have not gotten to it yet. Right now I try to study the code to find the real cause for the test getting into trouble - it is "kind of" interesting to learn how the test harness' properties files, the security manger and the tests works together :-)

Olav

David Van Couvering wrote:

Looks like a VM bug -- I wonder if their attempt to get the user.dir property in java.io.UnixFileSystem.resolve is likely not encapsulated in a PrivilegedAction block.

Olav - why would a null value for "user.dir" cause a security exception?

David

Olav Sandstaa wrote:

The exception causing the Nist tests to fail when running derbyall using jdk1.6 has the following call stack:

   at java.lang.System.getProperty(System.java:652)
   at java.io.UnixFileSystem.resolve(UnixFileSystem.java:118)
   at java.io.File.getCanonicalPath(File.java:559)

   at java.security.AccessController.doPrivileged(Native Method)

   at java.sql.DriverManager.getConnection(DriverManager.java:548)
   at java.sql.DriverManager.getConnection(DriverManager.java:148)
   at org.apache.derby.impl.tools.ij.util.startJBMS(util.java:516)
   at org.apache.derby.impl.tools.ij.util.startJBMS(util.java:616)

   at org.apache.derby.impl.tools.ij.utilMain.<init>(utilMain.java:176)

   at org.apache.derby.impl.tools.ij.Main.<init>(Main.java:265)
   at org.apache.derby.impl.tools.ij.Main14.<init>(Main14.java:68)
   at org.apache.derby.impl.tools.ij.Main14.getMain(Main14.java:91)
   at org.apache.derby.impl.tools.ij.Main.mainCore(Main.java:189)
   at org.apache.derby.impl.tools.ij.Main14.main(Main14.java:55)
   at org.apache.derby.tools.ij.main(ij.java:60)

   at java.lang.Thread.run(Thread.java:619)



Regards,
Olav

java.security.AccessControlException: access denied (java.util.PropertyPermission user.dir read) at java.security.AccessControlContext.checkPermission(AccessControlContext.java:323) at java.security.AccessController.checkPermission(AccessController.java:546) at java.lang.SecurityManager.checkPermission(SecurityManager.java:532) at java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1285) at org.apache.derby.impl.io.DirStorageFactory.doInit(DirStorageFactory.java:190) at org.apache.derby.impl.io.BaseStorageFactory.init(BaseStorageFactory.java:87) at org.apache.derby.impl.services.monitor.StorageFactoryService.privGetStorageFactoryInstance(StorageFactoryService.java:201) at org.apache.derby.impl.services.monitor.StorageFactoryService.access$400(StorageFactoryService.java:64) at org.apache.derby.impl.services.monitor.StorageFactoryService$11.run(StorageFactoryService.java:774) at org.apache.derby.impl.services.monitor.StorageFactoryService.getCanonicalServiceName(StorageFactoryService.java:768) at org.apache.derby.impl.services.monitor.BaseMonitor.findProviderAndStartService(BaseMonitor.java:1537) at org.apache.derby.impl.services.monitor.BaseMonitor.startPersistentService(BaseMonitor.java:990) at org.apache.derby.iapi.services.monitor.Monitor.startPersistentService(Monitor.java:541) at org.apache.derby.impl.jdbc.EmbedConnection.bootDatabase(EmbedConnection.java:1591) at org.apache.derby.impl.jdbc.EmbedConnection.<init>(EmbedConnection.java:216) at org.apache.derby.impl.jdbc.EmbedConnection30.<init>(EmbedConnection30.java:72) at org.apache.derby.impl.jdbc.EmbedConnection40.<init>(EmbedConnection40.java:47) at org.apache.derby.jdbc.Driver40.getNewEmbedConnection(Driver40.java:64) at org.apache.derby.jdbc.InternalDriver.connect(InternalDriver.java:200) at org.apache.derby.impl.tools.ij.ConnectionEnv.init(ConnectionEnv.java:64) at org.apache.derby.impl.tools.ij.utilMain14.<init>(utilMain14.java:51) at org.apache.derby.impl.tools.ij.Main14.getutilMain(Main14.java:102) at org.apache.derbyTesting.functionTests.harness.RunIJ.run(Unknown Source) I am working on to figure out why this happens when running with jdk1.6 opposed to when running with earlier jdk versions. Since I am not very familiar with the security manager configuration used by the tests I appreciate all suggestions that other might have on why this happens.

--
Ole Solberg, Database Technology Group,
Sun Microsystems, Trondheim, Norway

smime.p7s
Description: S/MIME Cryptographic Signature