You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-issues@jackrabbit.apache.org by "Marcel Reutegger (Jira)" <ji...@apache.org> on 2020/03/31 12:06:00 UTC
[jira] [Resolved] (OAK-8984) A big number of NOOP changes can
result in a StackOverflow
[ https://issues.apache.org/jira/browse/OAK-8984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Marcel Reutegger resolved OAK-8984.
-----------------------------------
Fix Version/s: 1.28.0
Resolution: Fixed
Thanks for reporting and the collaboration on the patch.
I slightly changed it and put the restriction of the stack size into the JVM options for the entire test run.
In trunk: http://svn.apache.org/r1875929
> A big number of NOOP changes can result in a StackOverflow
> ----------------------------------------------------------
>
> Key: OAK-8984
> URL: https://issues.apache.org/jira/browse/OAK-8984
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: documentmk
> Reporter: José Andrés Cordero Benítez
> Assignee: Marcel Reutegger
> Priority: Minor
> Fix For: 1.28.0
>
> Attachments: infinite-recursion-OAK-8984.patch
>
>
> We have a case where a sync job sometimes produce a StackOverflow when a big number of NOOP changes are executed. The problem could be related with the wrapping of a new ModifiedDocumentNodeState object in every call.
> If the number of changes don't reach the UpdateLimit value, if will continue creating objects until it throws a StackOverflow error.
> The problem only happens in very specific conditions, but with help of [~mreutegg] we were able to reproduce in a test that artificially recreates the situation.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)