There doesn't seem to actually be any noticeably memory leaks on Weston
when running dEQP. We do seem to leak quiet a bit in the client, so we
still have to run the dEQP runner in batches.
This removes the risk of Weston not restarting properly and introducing
spurious failures.
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
while [ -s /tmp/case-list.txt ]; do
head -$BATCH_SIZE /tmp/case-list.txt > /tmp/next-batch.txt
./deqp-gles2 $DEQP_OPTIONS --deqp-log-filename=/dev/null --deqp-caselist-file=/tmp/next-batch.txt >> /tmp/result.txt
- deqp_status=$?
-
- kill $(pidof weston)
- sleep 1 # Give some time for Weston to release the VT
- weston --tty=7 &
- sleep 1 # Give some time for Weston to start up
-
- if [ $deqp_status -ne 0 ]; then
+ if [ $? -ne 0 ]; then
# Continue from the subtest after the failing one
crashed_test=$(grep "Test case" /tmp/result.txt | tail -1 | sed "s/Test case '\(.*\)'\.\./\1/")
sed -i "0,/^$crashed_test$/d" /tmp/case-list.txt