NxmLReader problem probably associated to assembly #718
Comments
|
This stack trace is deceptive, probably because of the reflection involved. It is hiding an array index out of bounds exception which is thrown from LinguisticPolarityEngine line 46. At that point there is a sentence with a token interval [3, 29] but incoming edges only from [0, 28]. val prepc_byed = (evt.tokenInterval filter (tok => deps.getIncomingEdges(tok).map(_._2).contains("advcl_by"))).toSet |
|
This may well have been fixed with clulab/processors#428 which should be in processors 8.2.2, but that's exactly what is supposed to be being used... |
|
Indeed. This should be fixed there... |
|
I know which sentence it is. Will report soon.
…On Tue, Jan 5, 2021, 7:32 AM Mihai Surdeanu ***@***.***> wrote:
Indeed. This should be fixed there...
@enoriega <https://github.com/enoriega>: if you can isolate this a
sentence, I will debug this.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#718 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACCHCOUO5XYJHPNYD3XE54DSYMPGLANCNFSM4VRKD53A>
.
|
|
It is this sentence, which is almost the only one in the attached file: AFAICT, the problem is in the processors project, file CoreNLPProcessor.scala, around line 129-130, in which these lines do not pass in a preferredSize when they call CoreNLPUtils.toDirectedGraph, unlike the code in FastNLPProcessor, method parseWithStanford, which might be used as a template. doc.sentences(offset).setDependencies(GraphMap.UNIVERSAL_BASIC, CoreNLPUtils.toDirectedGraph(basicDeps, in))
doc.sentences(offset).setDependencies(GraphMap.UNIVERSAL_ENHANCED, CoreNLPUtils.toDirectedGraph(enhancedDeps, in)) |
|
Thanks! I'll take a look soon. |
|
@enoriega's keen observational skills are greatly appreciated. Thanks for taking the time to report the problem. |
|
The processors PR has been merged. |
|
This has likely been handled with clulab/processors#439. |
|
I tested again with a freshly cloned processors version 8.2.4-SNAPSHOT and am still getting the same error trace. Could it be that there's still a corner case not covered in processors? |
|
I'll check. |
|
It looks like the same error, but has a completely different cause. This line in reach does not check the bounds correctly: case outOfBounds if outOfBounds == -1 || outOfBounds > words.size => false |
|
Can you please try to fix it? |
|
Yes, doing so. |
|
Thanks @kwalcock |
|
I have been running REACH using branch |
|
Thanks for the update. We're working on the merge to master and a new release. |
When I turn on assembly in the config, sometimes I see an an
NxmlReadererror that I didn't see otherwise. The stack trace points back to some of the assembly methods. I suspect there is an unexpected corner case with this class of files that crashes their processing.The error is not catastrophic, as processing of the other files carries on.
I attach the stack trace of the exception and an nxml file that triggers it for replication purposes.
PMC6797981.nxml.txt
Stack trace:
The text was updated successfully, but these errors were encountered: