[
https://issues.apache.org/jira/browse/UIMA-6168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17111398#comment-17111398
]
Marshall Schor commented on UIMA-6168:
--------------------------------------
There must be some use case I'm missing. This fix might be covering up some
other issue.
Here's what's supposed to happen, and why this code was removed in PR 20.
There are multiple cases where alternations to CAS FSs might need "protecting".
Protecting means that before the alteration, the FS is removed from all
indexes in all views where it is indexed. Then the alteration(s) happen. At
the end of the protection block, the FS is added back (to all the indexes) in
all the views.
The mechanism for doing this is to record the FSs that need to be added back,
and at the end, add them.
That record is kept in instances of FSsToBeAddedback. For some operations
(e.g. deserialization) a single instance of this class may suffice. For other
operations (users invoking protectIndexes in a try / finally block, for
example, see
[https://uima.apache.org/d/uimaj-current/references.html#ugr.ref.cas.updating_indexed_feature_structures]
)
the user code could, inside the body of the protected block, invoke another
protectIndexes, ending up with multiple nested blocks. Each one of these is
kept in a stack, rooted in the baseCAS in svd.fssTobeAddedback.
Each time the add back code is called (CASImpl.addbackModifiedFSs), it looks at
this stack, and sees if the instance of FSsTobeAddedback is the last one in the
stack, and if so, it removes it from the stack.
I think I see one use case which was forgotten in the previous fix. This was
the case where the user did the
{code:java}
try (AutoCloseable ac = my_cas.protectIndexes()) {
... arbitrary user code which updates features
which may be "keys" in one or more indexes
}{code}
In this case, the "close()" method of FSsTobeAddedback (need to look at the
subclasses) is called, and that needs to check and drop the last one. So the
fix is kind-of right, but misses the other cases, and needs to be moved up to
the close method I think. It should also do the previous impl, which has
additional checking to insure it's the last item in the chain:
{code:java}
int last_index = svd.fssTobeAddedback.size() -1;
if (last_index < 0) return;
FSsTobeAddedback last_one = svd.fssTobeAddedback.get(last_index);
if (fssTobeAddedback == last_one) {
svd.fssTobeAddedback.remove(last_index)
}
{code}
Do you want me to make this change to the pull request, or do you want to?
> protect indexes fails when there were no indexed fs that needed protecting
> --------------------------------------------------------------------------
>
> Key: UIMA-6168
> URL: https://issues.apache.org/jira/browse/UIMA-6168
> Project: UIMA
> Issue Type: Bug
> Components: Core Java Framework
> Affects Versions: 2.10.4SDK, 3.1.1SDK
> Reporter: Marshall Schor
> Assignee: Richard Eckart de Castilho
> Priority: Major
> Fix For: 3.2.0SDK, 2.10.5SDK
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> While testing Annotation trim (UIMA-6152) it had cases where protect indexes
> was used with no indexed items - and exposed an index out-of-bounds error in
> the actions taken for this case.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)