plio2 fails to initialze fsb.iocb_p for "get string" construct.

[charles.unix.pro@…]

A pl1 program containing a line like:

    get string (translate (dottedaddr, ",", ".")) list (fields);

was observed to work correctly but sometimes crash with a command fault in the plio2_ library.

It was hypothesised that the random nature of the crashes pointed to an unitiailized stack variable. A version of the program that would fill the stack was fixed values was generated, experimentation showed that the plio2_ library was indeed using an uninitialized operand for a LPRP instruction, and if the two high bits in the uninitailzed operand were set, a command fault would occur (as per the LPRP instruction specification).

It was observed that if the instruction did not fault, the plio2 library would return the correct result; it seemed somewhat odd that an accessing an unitiialized variable would return correct results.

Investigation of the plio2_ source revealed the line:

    iocbp = ps.fsbp -> fsb.iocb_p;

The code was making a local copy of the variable, but not using it.

The variable in question is a pointer to an iocb block for the file being operated on. For the case of "get string", there is no actual file; the fsb buffer pointer and length are set to the string being read from, and as the buffer is already full, iox is never invoked. Thus the local copy of iocb_p is never dereferenced, and the plio2 code works for get string.

The plio2 code that sets up the fsb for "get string" operations was located and code to initialize the iocb was added. This resulted in code using "get string" to run without falling prey to random command faults.

cpa <plio2_get_util_.pl1 plio2_get_util_.pl1

Inserted in B:
B494                          fsb.iocb_p=null;
Preceding:
A494
A495                          if ps.varying_string then i=addrel(bptr,-1)->base
\cd_int;

Comparison finished: 1 difference, 1 line.