[
https://issues.apache.org/jira/browse/DAFFODIL-2361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17817642#comment-17817642
]
Mike Beckerle commented on DAFFODIL-2361:
-----------------------------------------
This issue is a DFDL v1.0 language design problem. The fix is not obvious, but
it is the interaction of dfdl:lengthKind='explicit' with a dfdl:length
expression that refers to preceding field or fields which have
dfdl:outputValueCalc.
When unparsing, DFDL v1.0 says the explicit length expression is evaluated.
This will demand the values of these preceding field(s) but those do not yet
exist because they have dfdl:outputValueCalc expressions referring to the
dfdl:valueLength / dfdl:contentLength of something the length of which depends
on the explicit length expression.
The simplest case is a direct cycle between a single length element and an
subsequent element of that length. The length element's dfdl:outputValueCalc
just evaluates the dfdl:valueLength of the subsequent element.
Fixing prefixedLength is high in priority here, as today in Daffodil we can't
depend on prefixedLength and so there are far more of these
length-expression/valueLength cycles that are necessary.
But when the length element is not immediately preceding the structure of that
length, then we have the cyclic problem.
Either we improve the diagnostic and inform the schema author at schema
compilation time that their expression is cyclic (and suggest what to do to fix
it, or we provide some sort of deadlock detection behavior where at unparse
time when we evaluate a length expression, if it suspends, we treat it
specially, and at unparse time we treat it as if we were obtaining the implicit
length of the element (all children + framing), and use that as the
valueLength, rather than evaluating the expression. One could then compute the
length expression again, and use that value for padding or truncating a string
element.
This has the shortcoming that if the length expression would not have
deadlocked, we can't compute a longer "box" for the data, and then have the
children fill in only part of it, leaving unused data. We also can't
New dfdl:lengthKinds may be helpful to separate the various cases more
explicitly, and giving names to them so they can be explained.
> valueLength not working as expected with complex elements, causing circular
> deadlocks during unparse
> ----------------------------------------------------------------------------------------------------
>
> Key: DAFFODIL-2361
> URL: https://issues.apache.org/jira/browse/DAFFODIL-2361
> Project: Daffodil
> Issue Type: Bug
> Components: Diagnostics, Unparsing
> Affects Versions: 2.6.0
> Reporter: Josh Adams
> Assignee: Mike Beckerle
> Priority: Minor
> Attachments: innerSeq.xsd, test.dat, test.info, test.xsd
>
>
> Ran into this issue while making changes to a production schema.
> Consider the following schema;
> <xs:element name="len" type="xs:unsignedInt" dfdl:outputValueCalc="\{
> dfdl:valueLength(../implicitLenComplex, 'bytes') }" />
> <xs:element name="implicitLenComplex">
> <xs:complexType>
> <xs:sequence>
> <xs:element name="item1" type="xs:hexBinary" dfdl:length="\{ ../../len }"
> dfdl:lengthUnits="bytes" dfdl:lengthKind="explicit" />
> </xs:sequence>
> </xs:complexType>
> </xs:element>
>
> I would reasonably expect that the outputValueCalc would work as expected and
> get the valueLength of the entire implicitLenComplex sequence, however this
> results in a circular deadlock.
>
> NOTE: if you change the outputValueCalc to
> dfdl:valueLength(../implicitLenComplex/item1, 'bytes') everything works as
> expected.
>
> I've attached a sample schema file and test data that demonstrates this issue.
>
> EDIT: I've added an additional schema that demonstrates that if the hexBinary
> element is wrapped inside an additional sequence and valueLength is called on
> the inner sequence it still results in the circular deadlock.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
