db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mamta A. Satoor (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-6352) Access denied ("java.lang.RuntimePermission" "modifyThread") in store.RecoveryAfterBackup test
Date Mon, 16 Dec 2013 18:23:09 GMT

    [ https://issues.apache.org/jira/browse/DERBY-6352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13849423#comment-13849423
] 

Mamta A. Satoor commented on DERBY-6352:
----------------------------------------

Not sure if it is the same failure but the test failed on trunk(revision 1550872) with IBM
jdk 1.6 on Windows machine.
http://people.apache.org/~myrnavl/derby_test_results/main/windows/testlog/ibm16/1550872-derbyall_diff.txt

*** Start: RecoveryAfterBackup jdk1.6.0 storeall:storerecovery 2013-12-13 19:47:10 ***
4 del
< Database shutdown completed
5 del
< Starting restore with roll-forward recovery..
6 del
< Verifying database ...
7 del
< Count: 256 Sum: 32640
7 add
> JVMDUMP034I User requested Java dump using 'C:\jartest\JarResults.2013-12-13\ibm16_derbyall\javacore.20131213.194713.4948.0001.txt'
through com.ibm.jvm.Dump.JavaDump
> JVMDUMP010I Java dump written to C:\jartest\JarResults.2013-12-13\ibm16_derbyall\javacore.20131213.194713.4948.0001.txt
> Exception in thread "main" java.security.AccessControlException: Access denied (java.lang.RuntimePermission
modifyThread)
Test Failed.
*** End:   RecoveryAfterBackup jdk1.6.0 storeall:storerecovery 2013-12-13 19:47:18 ***

> Access denied ("java.lang.RuntimePermission" "modifyThread") in store.RecoveryAfterBackup
test
> ----------------------------------------------------------------------------------------------
>
>                 Key: DERBY-6352
>                 URL: https://issues.apache.org/jira/browse/DERBY-6352
>             Project: Derby
>          Issue Type: Bug
>          Components: Test
>    Affects Versions: 10.10.1.1
>         Environment: IBM java 7 Derby version 10.10.1.2 - (1494414)
>            Reporter: Kathey Marsden
>         Attachments: DERBY-6352_trunk.diff, DERBY-6352_trunk2.diff
>
>
> I got a report of the following intermittent (6/60) exception in store.RecoveryAfterBackupTest.
> Exception in thread "main" java.security.AccessControlException: Access denied ("java.lang.RuntimePermission"
"modifyThread")
> 		 at java.security.AccessController.throwACE(AccessController.java:100)
> 		 at java.security.AccessController.checkPermission(AccessController.java:174)
> 		 at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
> 		 at java.lang.SecurityManager.checkAccess(SecurityManager.java:676)
> 		 at java.lang.Thread.checkAccess(Thread.java:459)
> 		 at java.lang.Thread.interrupt(Thread.java:588)
> 		 at org.apache.derby.iapi.services.context.ContextService$1.run(Unknown Source)
> 		 at java.security.AccessController.doPrivileged(AccessController.java:274)
> 		 at org.apache.derby.iapi.services.context.ContextService.notifyAllActiveThreads(Unknown
Source)
> 		 at org.apache.derby.impl.services.monitor.BaseMonitor.shutdown(Unknown Source)
> 		 at org.apache.derby.jdbc.InternalDriver.connect(Unknown Source)
> 		 at org.apache.derby.jdbc.Driver20.connect(Unknown Source)
> 		 at org.apache.derby.jdbc.AutoloadedDriver.connect(Unknown Source)
> 		 at java.sql.DriverManager.getConnection(DriverManager.java:571)
> 		 at java.sql.DriverManager.getConnection(DriverManager.java:233)
> 		 at org.apache.derbyTesting.functionTests.util.TestUtil.getConnection(TestUtil.java:836)
> 		 at org.apache.derbyTesting.functionTests.tests.store.RecoveryAfterBackup.main(RecoveryAfterBackup.java:82)
> modifyThread is a necessary permission if interrupting a thread other than the current
thread but is not in our policy file for derby.jar.
> The relevant code in ContextService is:
>            for (ContextManager cm : allContexts) {
> 				Thread active = cm.activeThread;
> 				if (active == me)
> 					continue;
> 				if (active == null)
> 					continue;
>                 final Thread fActive = active;
> 				if (cm.setInterrupted(c))
>                 {
>                     AccessController.doPrivileged(
>                             new PrivilegedAction<Void>() {
>                                 public Void run()  {
>                                     fActive.interrupt();
>                                     return null;
>                                 }
>                             });
>                 }
> 		
> I am not sure why this has never come up before.  Are we expecting in this context that
fActive is the current thread?
>  



--
This message was sent by Atlassian JIRA
(v6.1.4#6159)

Mime
View raw message