[
https://issues.apache.org/jira/browse/DAFFODIL-2726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17584494#comment-17584494
]
Mike Beckerle commented on DAFFODIL-2726:
-----------------------------------------
Appears to be due to that due to bitOrder changes and layering it's possible
for a split DOS to be required in the data output data stream when there is no
infoset node on stack any more.
Modifications to make the UStateForSuspension accept a `Maybe[DINode]` lead to
the same failure becoming an assertion failure in the split DOS logic.
This appears to be related to the bit-order changes in my schema.
* First header is MSBF, byte aligned.
* Second header is LSBF, bit aligned, but has a final alignment to byte
boundary.
* data payload is a zip-file image. The zipLayerTransformer creates an array
of data for the zip entries which is MSBF, byte aligned.
* Each zip Entry data block has a element named data the type of which is
application defined.
* My schema has that data element's type defined to be LSBF, bit-aligned data.
This ends with an alignment to a byte boundary.
This LBSF data is full of presence bits and repeat flag bits that require
suspensions on unparsing, as they are all defined in terms of elements that are
after them, although this is mostly immediately after them. There are also
large suspensions due to the fact that the very first header starts with an
overall length of the entire structure, second header stores the length of the
data payload, etc.
> Index out of bounds -1 during unparsing
> ---------------------------------------
>
> Key: DAFFODIL-2726
> URL: https://issues.apache.org/jira/browse/DAFFODIL-2726
> Project: Daffodil
> Issue Type: Bug
> Components: Unparsing
> Affects Versions: 3.4.0
> Reporter: Mike Beckerle
> Assignee: Mike Beckerle
> Priority: Blocker
>
> 3.4.0-SNAPSHOT - as of 2022-08-23.
> I have unparsing in a large complex DFDL schema failing with a Index out of
> bounds - an empty stack of infoset nodes.
> I think this is going to be a blocker for the release as I think there is no
> workaround, but further work may change this.
> By inspection it looks to be a bug where the index value isn't being checked,
> as the function can return Nope or One(value), but instead throws the
> exception.
> Working on a way to reproduce this outside of this very large schema project.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
