You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@daffodil.apache.org by "Josh Adams (Jira)" <ji...@apache.org> on 2020/07/01 15:38:00 UTC
[jira] [Updated] (DAFFODIL-2361) valueLength not working as
expected with complex elements, causing circular deadlocks during unparse
[ https://issues.apache.org/jira/browse/DAFFODIL-2361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Josh Adams updated DAFFODIL-2361:
---------------------------------
Attachment: innerSeq.xsd
Description:
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.
was:
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.
> 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: Unparsing
> Affects Versions: 2.6.0
> Reporter: Josh Adams
> Priority: Major
> 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.3.4#803005)