jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Julian Reschke (Updated) (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (JCR-3086) potential infinite loop around InternalVersionImpl.getSuccessors
Date Thu, 29 Sep 2011 12:24:45 GMT

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

Julian Reschke updated JCR-3086:
--------------------------------

    Description: 
There's an infinite loop waiting to happen when the underlying persisted version storage is
defect:


at
org.apache.jackrabbit.core.version.InternalVersionImpl.getSuccessors(InternalVersionImpl.java:148)

at
org.apache.jackrabbit.core.version.InternalVersionHistoryImpl.init(InternalVersionHistoryImpl.java:165)

at
org.apache.jackrabbit.core.version.InternalVersionHistoryImpl.reload(InternalVersionHistoryImpl.java:180)

at
org.apache.jackrabbit.core.version.InternalVersionHistoryImpl.getVersion(InternalVersionHistoryImpl.java:299)


(line numbers from 2.2)

What happens here is that when a version can not be instantiated, reload() is called, which
in turn calls init(), which, as part of piece of code labeled "fix legacy" will call getSuccessors(),
which in turn wants to instantiate versions.



  was:
There's an infinite loop waiting for happen when the underlying persisted version storage
is defect:


at
org.apache.jackrabbit.core.version.InternalVersionImpl.getSuccessors(InternalVersionImpl.java:148)

at
org.apache.jackrabbit.core.version.InternalVersionHistoryImpl.init(InternalVersionHistoryImpl.java:165)

at
org.apache.jackrabbit.core.version.InternalVersionHistoryImpl.reload(InternalVersionHistoryImpl.java:180)

at
org.apache.jackrabbit.core.version.InternalVersionHistoryImpl.getVersion(InternalVersionHistoryImpl.java:299)


(line numbers from 2.2)

What happens here is that when a version can not be instantiated, reload() is called, which
in turn calls init(), which, as part of piece of code labeled "fix legacy" will call getSuccessors(),
which in turn wants to instantiate versions.



    
> potential infinite loop around InternalVersionImpl.getSuccessors
> ----------------------------------------------------------------
>
>                 Key: JCR-3086
>                 URL: https://issues.apache.org/jira/browse/JCR-3086
>             Project: Jackrabbit Content Repository
>          Issue Type: Bug
>          Components: jackrabbit-core
>    Affects Versions: 2.2.8, 2.4
>            Reporter: Julian Reschke
>            Assignee: Julian Reschke
>         Attachments: JCR-3086.patch
>
>
> There's an infinite loop waiting to happen when the underlying persisted version storage
is defect:
> at
> org.apache.jackrabbit.core.version.InternalVersionImpl.getSuccessors(InternalVersionImpl.java:148)
> at
> org.apache.jackrabbit.core.version.InternalVersionHistoryImpl.init(InternalVersionHistoryImpl.java:165)
> at
> org.apache.jackrabbit.core.version.InternalVersionHistoryImpl.reload(InternalVersionHistoryImpl.java:180)
> at
> org.apache.jackrabbit.core.version.InternalVersionHistoryImpl.getVersion(InternalVersionHistoryImpl.java:299)

> (line numbers from 2.2)
> What happens here is that when a version can not be instantiated, reload() is called,
which in turn calls init(), which, as part of piece of code labeled "fix legacy" will call
getSuccessors(), which in turn wants to instantiate versions.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message