Race Condition Determination – Pt. 15

UP
-bash-3.00$ printf "^[[A" | od -X
0000000 1b5b41
0000003
DOWN
-bash-3.00$ printf "^[[B" | od -X
0000000 1b5b42

LEFT
-bash-3.00$ printf "^[[D" | od -t x1
0000000 1b 5b 44
0000003

RIGHT
-bash-3.00$ printf "^[[C" | od -t x1
0000000 1b 5b 43
0000003

It appears to be a blind race!?!? :[ But it is NOT so. There is a way to determine where my cool cat program IS in the race!! By adding the overflow entry as a USER_PROCESS entry, it can be determined by the output whether the insertion is happening BEFORE or AFTER the forked ‘w’ process loads all entries. If we are too early, the entry will show up in w’s output, too late and it won’t show up at all. The problem is that there is another factor — The file size of UTMPX increases by a good 0x174 * 2 bytes every test run. Meaning that the metrics are innacurate to a degree. The relation between the metrics and the filesize increase is unknown.

There are many things to do:

1) Modify program to fork a PTY, this code can be extracted from Apply-hack and will be used to provide the same master-level real-time control of variables such as UP/DOWN/LEFT/RIGHT to control sleep dials before the utmpx-entry write and exec ‘w’ .

2) It may help to add a number of processes that do nothing but chew up CPU.. Try 100 processes that do nothing but echo “DADADA” to the screen.. This can prolly be done in a bash script, no?

script.sh

#!/bin/bash
while :
do
  echo "HELLO"
done

script2.sh

#!/bin/bash
for (( c=1; c<=$1; c++ ))
do
   ./script.sh &
done