db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Myrna van Lunteren (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (DERBY-6352) Access denied ("java.lang.RuntimePermission" "modifyThread") in store.RecoveryAfterBackup test
Date Thu, 10 Oct 2013 03:19:42 GMT

     [ https://issues.apache.org/jira/browse/DERBY-6352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Myrna van Lunteren updated DERBY-6352:
--------------------------------------

    Attachment: DERBY-6352_trunk2.diff

Attaching another patch. I changed my mind about swallowing the exception, I think there is
a chance of a hang during system shutdown if we hit it. 
But  we could do with more information. So with sane builds, causing an Assert which will
dump info about the current threads to the console, and also identify which Thread is hitting
the exception.
With insane, rethrow the exception, and in the case of an IBM jvm, also cause a java dump
to be generated which will also contain a list of the current threads.

Patch ready for review.

> 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_trunk2.diff, DERBY-6352_trunk.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#6144)

Mime
View raw message