CAC 2020-04-14

# 384

A user reported an issue where a program they had written would sometimes crash with an instruction fault, sometimes not. Working on the assumption that the underlying issue was an uninitialized stack variable, they rigged up a framework that would allow initializing the stack space that would be used for varaibles with a user specified value. The value (a command line parameter) was specifed as a nine-bit decimal integer which was repeated four times per word. (0 would become (in octal) 000000000000, 7 would becomes 007007007007, 511 would become 777777777777). Testing with a 0 did not fault, testing with 511 (setting the words to all ones) produced a fault, thus confirming the unitialized variable theory. Seeking further clues, different values were tried to see if a pattern emerged. Values less then 384 did not fault, values greater or equal to 384 did fault.

Why 384. What is it about that value that is special?

The faulting instruction was LPRP — Load Pointer Register Packed. The instruction reads an word from memory and extracts three fields from it that are copied into the pointer register: a segment number, a word number and a bit number. The "bit number" field is six bits in length, so can hold values from 0 to 63, however only values of 0 to 35 are valid (as the word length is 36 bits). The LPRP instuction does not test for values greater the 35, but it does a simpler test: if the two high bits are set (110000), then the value (being 48) is obviously to large and the instruction throws a "command fault".

383 in binary is 101111111 so the stack would be filled with 101111111101111111101111111101111111.

384 in binary is 110000000 so the stack would be filled with 110000000110000000110000000110000000.

Note that 384 is smallest value that results in the two high bits being set in word, so all smaller values were used by LPRP without error, but after that with error.

page revision: 1, last edited: 14 Apr 2020 21:05