[
https://issues.apache.org/jira/browse/OAK-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16702018#comment-16702018
]
Julian Reschke edited comment on OAK-7906 at 11/29/18 12:58 PM:
----------------------------------------------------------------
Turns out that this happens because
org.apache.jackrabbit.oak.security.authentication.LoginContextProviderImpl#getLoginContext()
suddenly returns a wrong LoginContext. This in turn happens because
LoginContextProviderImpl#getSubject() calls
java.security.AccessController#getContext():
{code:java}
public static AccessControlContext getContext()
{
AccessControlContext acc = getStackAccessControlContext();
if (acc == null) {
// all we had was privileged system code. We don't want
// to return null though, so we construct a real ACC.
return new AccessControlContext(null, true);
} else {
return acc.optimize();
}
}
{code}
, which behaves unexpectedly: enabling -Djava.security.debug=all (note that
this issue is apparently not reproducible with a debugger attached) shows that
acc.optimize() is not called, which in turn means that the native method
getStackAccessControlContext() returned null, which per documentation means
that there was only privileged system code on the call stack, which is
obviously not the case. So, this appears to be a bug in this native
implementation.
was (Author: baedke):
Turns out that this happens because
org.apache.jackrabbit.oak.security.authentication.LoginContextProviderImpl#getLoginContext()
suddenly returns a wrong LoginContext. This in turn happens because
LoginContextProviderImpl#getSubject() calls
java.security.AccessController#getContext():
{code:java}
public static AccessControlContext getContext()
{
AccessControlContext acc = getStackAccessControlContext();
if (acc == null) {
// all we had was privileged system code. We don't want
// to return null though, so we construct a real ACC.
return new AccessControlContext(null, true);
} else {
return acc.optimize();
}
}
{code}
, which behaves unexspectedly: enabling -Djava.security.debug=all (note that
this issue is apparently not reproducible with a debugger attached) shows that
acc.optimize() is not called, which in turn means that the native method
getStackAccessControlContext() returned null, which per documentation means
that there was only priviliged system code on the call stack, which is
obviously not the case. So, this appears to be a bug in this native
implementation.
> StackOverFlowError
> SessionStatsTest.testInitStackTraceEnabledAfterOpeningManySessions with jdk-12
> -------------------------------------------------------------------------------------------------
>
> Key: OAK-7906
> URL: https://issues.apache.org/jira/browse/OAK-7906
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: jcr
> Affects Versions: 1.9.11
> Reporter: Julian Reschke
> Priority: Major
> Labels: Java12
>
> Happens with version 20 (2018/11/15).
> It appears that the StackOverflowError happens when obtaining many sessions.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
