river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: An interesting concurrency bug
Date Wed, 04 Aug 2010 11:32:44 GMT
Oddly enough, in the test that passes, I don't see the implies call for 
DownloadPermission

Peter Firmstone wrote:
> Hi,
>
> Got an interesting concurrency bug to solve, if you check out the 
> latest revision, you can simulate this bug.  Go back to rev 981386, 
> the bug isn't apparent.
>
> Basically the changes are:
>
> DynamicConcurrentPolicyProvider:
>
> implies(ProtectionDomain, Permission)
>    old version calls underlying basePolicy.implies() first, then 
> basePolicy.getPermissions()
>    new version skips implies and calls basePolicy.getPermissions()
>
> grant( Class ...)
>   Changed to use AccessController.checkPermission()  instead of 
> SecurityManager call of same name.
>
> Only implies() is involved in this case.
>
> The test in question:
> com/sun/jini/test/spec/loader/pref/preferredClassLoader/GetPermissionsSecurityException.td

>
>
> The 7 tests that fail are related to PreferredPolicyProvider, no 
> DynamicPolicy tests fail.
>
> The reason the basedPolicy.implies() is no longer called is to remove 
> the possiblity of a ConcurrentModificationException that would occur 
> when an implies from a concurrent thread causes UnresolvedPermission's 
> to become resolved, changing underlying state during an Enumeration.
>
> Oh and the test passes when -Djava.security.debug=access:failure is used.
>
> Test results attached.
>
> I'll commit a changed to the build.xml file for qa, so you can run the 
> test from the qa directory using ant run-tests
>
> Cheers,
>
> Peter.
>
>
>


Mime
View raw message