Sometimes the "state" data structure is corrupted. What is the state vector? How can I fix the problem?
Discussion
A function box is composed of various methods that operate on the function boxes' "state" data structure. The state structure contains pointers to input and output streams, dynamic queues, parameters, local state variables, the boxes execution granularity, and dimension and family size variables. The contents of the state structure are dictated largely by the function box description file, particularly the Input, Output, and Local sections.
For example consider the function box v_demux below:
Name: v_demux
Type: static
Input: {
stream float in[n](m);
}
Output: {
stream float [m]out[n](1);
}
Apply: {
int N = size(in)/n;
int fam=0;
int j=0;
while (N--) { /* loop thru input vectors */
e_vmov(in,1,out[fam]+j,1,n); /* vector move */
in += n; /* point to next input vector */
if ( (++fam) >=m) {fam=0;j+=n;} /* inc family with walking wrap */
}
}
The state vector for this box is:
typedef struct {
int granularity; /* granularity of box firing */
float *in; /* pointer to input data stream in */
int N_in; /* number of samples in input data stream in */
float **out; /* family of output streams */
int m; /* number of family members in output stream */
int n; /* dimension n of input stream "in" */
} StateRec, *State;
The state structure contains all the information needed for the Apply
method to run. The Apply method is implemented as a function that
takes as its one input parameter the state vector. The code
generation for the Apply method is shown below.
static void Apply(void *vstate) {
State state = vstate;
int granularity = state->granularity;
int m = state->m;
int n = state->n;
float **out = (state->out);
float *in = (state->in);
int _size_in = state->N_in;
int N = _size_in/n;
int fam=0;
int j=0;
while (N--) {
e_vmov(in,1,out[fam]+j,1,n);
in += n;
if ( (++fam) >=m) {fam=0;j+=n;}
}
}
Solution
If the state vector is corrupted the function box will fail to run
correctly. There are several reasons that the state vector could be
corrupted. One common reason is that a function box is written in
such a way that the Apply method of the box overwrites the bounds of an array.
In this case it might corrupt the memory of some other box's
state vector.
Another cause, however, comes from editing a primitive function box
within a Gedae session. The problem is that currently the Input,
Output, and Local sections of a function box are read once in a Gedae
session and are not re-read even if the user modifies them from the
primitive editor within Gedae. If the user modifies these sections and
runs the code generator, Gedae will dynamically link in the new methods
and state vector description. However, this state vector will not agree
with the description of the box already read into Gedae, and Gedae
will not initialize the state correctly as a result. Currently the work
around is to exit Gedae after modifying a primitive definition's Input,
Output, or Local section. This problem will be fixed in a future
release and can be tracked as SCR220.
return to top
