On 07/06/2016 04:51 AM, Alan Bateman wrote:
On 06/07/2016 05:32, Weijun Wang wrote:
On 7/5/2016 23:50, Mandy Chung wrote:
Max - are you running the test with exploded image (see JDK-8155858
[1])?
No. The test also fails with recent promoted builds (ever since
java.sql is de-priveleged).
I assume this is a general issue with security manager implementations
where the checkPermission implementation triggers permission checks and
so leads to stack overflow (and depending on the area can surface with
different errors or exceptions). Do we have older issues on this?
Yes. Typically you can avoid these by either putting the custom SM on
the bootclasspath or granting it AllPermission, or implementing a policy
provider that checks if the caller's ProtectionDomain is the same as the
custom SM.
This one is a little different though. I will need to look into it some
more.
Does your SSL code match up with the stack trace? The test only has 27
lines, but the stack trace says it was called from line 42.
--Sean
