Segmentation fault when explicitly synchronising input stream with output offset by t-n for n>3

[pt7k]

Tau version: 0.7 (v0.7-alpha-136-g6df5e78)

I was able to create an output stream of desired length by synchronizing it with the length of a prepared input stream. But when there is a [t-n] offset used in my program's output, the first n steps of both input and output streams become implicitly zeroes and the stream's length is also elongated by n steps. It can be demonstrated by using an sbf sequence of 10 numbers as input and a simple program like o1[t] = o1[t-3] + i1[t]

In order to circumvent that behaviour I synchronized the input and output streams by explicitly stating that the first n steps of these streams are equal, as demonstrated in the second example (note how there are no null steps at the beginning of the output stream any more, and the total length is 10 steps as in the input file unlike the first example).

But when the offset is greater than 3 that same approach is causing the program to crash, as demonstrated in my third example with [t-4] offset.

Please find below the input file and 3 example scripts.
sbf10ones.txt
mydemo_1.2-test.tau.txt
mydemo_1.2a-test.tau.txt
mydemo_1.2b-test.tau.txt

[LuccaT95]

Dear pt7k,

thank you for the detailed report. We will investigate this segmentation fault issue soon. Sorry about the long wait due to Christmas/New Years season.

Regarding the Tau specification o1[t] = o1[t-3] + i1[t], the first valid value for t is 3, leading to o1[3] = o1[0] + i1[3]. Because an output cannot depend on future input/output, there is actually no restriction on o1[0]. The same holds for o1[1] and o1[2]. For this reason, the execution engine sets o1[0], o1[1] and o1[2] to 0, since this is the current default value for such a case.
This in turn leads to the fact that in the first three steps of execution, no input is required. The first defined input is i1[3]. As a result, since there are 10 inputs in sbf10ones.txt, there is enough information until i1[12].

Best,
Lucca