Linux & Bash · Part II · Module 34 · Defensive Automation Around EDA Tools

Truncated, Missing and Partial Output

A check written as 'no error line was found' answers the same way for a clean run, an empty file, half a file and no file at all. This chapter measures all four, finds that a truncated 'TEST PASSED' still matches a loose pattern because it was cut mid-word, and rebuilds the check around positive evidence that a complete run leaves behind.

Advanced25 min readLinuxPart IIEDALogsDefensive

Part II · Module 34 · Chapter 34.2 · Truncated, Missing and Partial Output

Chapter 34.1 moved the verdict from the exit status into the log. This chapter attacks the assumption that move rests on: that there is a log, and that it is all there.

1. Four Inputs, One Answer

The check every flow contains somewhere:

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

if [ "$(grep -c 'ERROR' "$log")" -eq 0 ]; then verdict=PASS; else verdict=FAIL; fi

Four files — a real passing run, an empty file, the first 60 bytes of the real one, and a path that does not exist:

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

  FILE           grep rc   count   verdict   is that right?
  good.log       1         0       PASS      yes -- it really passed
  empty.log      1         0       PASS      NO -- the file is empty
  truncated.log  1         0       PASS      NO -- half a log
  absent.log     2         (none)  PASS      NO -- there is no file

Three of four are wrong, and all three are wrong in the direction that ships.

`grep` did distinguish them, and the check discarded it

Look at the grep rc column rather than the count:

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

  good.log       1      no match
  empty.log      1      no match
  truncated.log  1      no match
  absent.log     2      could not read the file

grep returns 0 when it matched, 1 when it did not, and 2 when something went wrong — a missing file, a permissions error, a directory. That is a three-way answer, and $(grep -c …) keeps only the count.

So the information needed to catch the worst case was available and thrown away one character at a time: the command substitution captured the output, the status went nowhere, and the empty string that came back compared equal to zero.

Worse, the -eq comparison on an empty string is itself a hazard. Here it happened to work because the test was guarded; written plainly it is a syntax error, which Chapter 33.5 measured:

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

$ /bin/bash -c 'n=$(grep -c ERROR /no/such/file 2>/dev/null); [ "$n" -eq 0 ] && echo PASS'
/bin/bash: line 0: [: : integer expression expected

Three different wrong behaviours from one idiom, depending on how it is written: a false pass, a syntax error, or a silently skipped check. The fix is not better arithmetic — it is to stop asking whether something bad is absent.

2. Truncation Cuts Mid-Word

The 60-byte file is the interesting one. Here it is in full:

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

TB  test=smoke seed=1 cycles=200 verbosity=LOW
TB  TEST PASS

The run really did pass, and the log was cut in the middle of the word PASSED. Now match it:

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

  grep -c 'TEST PASSED'    -> 0
  grep -c 'TEST PASS'      -> 1  <<< MATCHES A TRUNCATED VERDICT
  grep -c 'PASS'           -> 1  <<< MATCHES A TRUNCATED VERDICT
  grep -c 'TEST PASSED$'   -> 0

A truncated verdict matches a loose pattern. grep 'PASS' is what people write, and here it reports a pass from a file that was cut off before the verdict was finished — which means it would report a pass from a run killed at that moment for any reason at all, including the reason the verdict was going to be FAILED.

Two defences, and both are needed:

Anchor the pattern. 'TEST PASSED$' returns 0 here, and '^TB TEST PASSED ' is better still — it requires the line's beginning and a trailing space, so no prefix of a longer word can satisfy it.

And check that the file ends properly, because anchoring alone cannot tell a complete log from one truncated after the verdict.

Figure 1 — the same check over four inputs. Asking whether an error line is absent gives the same answer for a clean run and for three kinds of nothing. Asking what a finished run leaves behind separates all four, because nothing-happened fails every presence test.

3. Positive Evidence

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

#!/bin/bash
# logcheck LOG -- decide a run from POSITIVE evidence in a log that must exist.
#   0 a complete, consistent pass        3 no such log
#   1 an explicit failure                4 the log exists but is empty
#   2 the log is present but incomplete  5 it contradicts itself
set -u
log=${1:-}
[ -n "$log" ] || { echo "logcheck: need a log path" >&2; exit 64; }
[ -e "$log" ] || { echo "logcheck: no log at '$log' -- the run produced nothing" >&2; exit 3; }
[ -s "$log" ] || { echo "logcheck: '$log' is empty -- the run produced a file and no output" >&2; exit 4; }

# A tool that finished writes a terminator. Without one the file is a fragment,
# whatever it appears to say -- a truncated "TEST PASSED" ends as "TEST PASS",
# which a loose pattern happily matches.
tail -c 1 "$log" | od -An -c | /usr/bin/grep -q '\\n' \
  || { echo "logcheck: '$log' does not end in a newline -- truncated mid-line" >&2; exit 2; }
/usr/bin/grep -q '\$finish called' "$log" \
  || { echo "logcheck: '$log' has no end-of-run marker -- the run did not finish" >&2; exit 2; }

p=$(/usr/bin/grep -c '^TB  TEST PASSED ' "$log")
f=$(/usr/bin/grep -c '^TB  TEST FAILED ' "$log")
[ $((p + f)) -gt 0 ] || { echo "logcheck: '$log' states no verdict" >&2; exit 2; }
[ $((p * f)) -eq 0 ] || { echo "logcheck: '$log' states both verdicts" >&2; exit 5; }
[ "$f" -eq 0 ] || { echo "logcheck: explicit failure" >&2; exit 1; }
e=$(/usr/bin/grep -c '[[:space:]]ERROR' "$log")
[ "$e" -eq 0 ] || { echo "logcheck: PASSED with $e error line(s)" >&2; exit 5; }
exit 0

Every branch, exercised:

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

  LOG              rc    MESSAGE
  smoke.log        0
  prio0.log        1     explicit failure
  inconsistent.log 5     PASSED with 1 error line(s)
  silent.log       2     states no verdict
  empty.log        4     is empty -- the run produced a file and no output
  truncated.log    2     does not end in a newline -- truncated mid-line
  noend.log        2     has no end-of-run marker -- the run did not finish
  absent.log       3     no log -- the run produced nothing

Four ideas in that script, and the first is the one the chapter exists for.

Ask what a complete run leaves, not what a broken one leaves

Every condition is of the form this must be present:

the file must exist
it must be non-empty
it must end in a newline
it must contain $finish called
it must state exactly one verdict
a PASSED must not sit beside an error line

A check built from absences answers the same way for "nothing went wrong" and "nothing happened". A check built from presences cannot: nothing happened fails every one of them. This is the fifth time this track has met the shape, and the previous four were Chapter 31.2's empty test list, Chapter 31.7's disk scan, Chapter 32.5's zero-row results file, and Chapter 32.7's arithmetic over an empty set.

Two different kinds of incomplete

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

tail -c 1 "$log" | od -An -c | /usr/bin/grep -q '\\n' || { … truncated mid-line …; exit 2; }
/usr/bin/grep -q '\$finish called' "$log" || { … no end-of-run marker …; exit 2; }

The first catches a file cut in the middle of a line — the 60-byte case. The second catches a file that happens to end on a line boundary but never reached the end of the run, which is what noend.log is: 100 bytes plus a newline, perfectly well-formed, and missing everything after it.

Neither check subsumes the other, and a writer who stops exactly at a newline is not unusual — a 4,096-byte buffer boundary falls on a newline roughly once in every few dozen lines.

tail -c 1 | od -An -c rather than reading the byte directly, because command substitution strips trailing newlines, so [ "$(tail -c1 "$log")" = "" ] is true for both a file ending in a newline and a file ending in nothing. That is Chapter 33.5's defect 5 arriving where it does real damage.

Exactly one verdict

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

[ $((p + f)) -gt 0 ] || { … states no verdict …; exit 2; }
[ $((p * f)) -eq 0 ] || { … states both verdicts …; exit 5; }

The sum catches none and the product catches both — two conditions in two cheap expressions. A log containing both is a multi-phase testbench whose phases disagreed, which is a different problem from either verdict alone.

And distinct statuses

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

  0 a complete, consistent pass        3 no such log
  1 an explicit failure                4 the log exists but is empty
  2 the log is present but incomplete  5 it contradicts itself

3 and 4 are separate because they are different failures of the flow: no file means the tool never wrote one; an empty file means it created one and wrote nothing, which usually means it died between open and the first flush. Chapter 32.3's classifier would merge them; here, where the subject is the artifact rather than the verdict, the distinction is the point.

4. The Artifact That Looks Fine

Logs are text and truncation is visible. A binary artifact is worse, because the parts a cheap check looks at are at the front.

A waveform written under a file-size cap, against a complete one:

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

  full   : rc=0   log=229B dump=18678B
  capped : rc=153 log=132B dump=8192B

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

  full     header=1  $enddefinitions=1  last line: 1"
  capped   header=1  $enddefinitions=1  last line: #

The truncated dump has a valid $version header and a $enddefinitions marker, because both live in the first few hundred bytes. Every structural check a flow is likely to make passes:

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

  full     dump present -> usable
  capped   dump present -> usable

The only difference is at the end, where capped finishes with a bare # — a timestamp marker with no value changes after it, written halfway.

So for an artifact the rules are different from a log:

Check the end, not the beginning. A format's header is written before any work happens and proves nothing about completion.

Prefer the producer's own status. rc=153 is 128 + 25, SIGXFSZ, which Chapter 33.8 measured — and for an artifact, unlike a verdict, the tool's status is the right signal, because a truncated write is exactly the kind of failure the tool does report.

And check the log and the artifact together. capped's log is 132 bytes against the full run's 229 — also truncated, by the same cap, at the same moment. Two artifacts cut off together is a stronger signal than either alone, and a flow that validates only the log would call this run incomplete without knowing the waveform was too.

What a size threshold can and cannot do

The tempting check is a minimum size:

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

[ "$(wc -c < "$d/dump.vcd")" -gt 100000 ] || { echo "dump looks truncated" >&2; exit 1; }

It would have caught this case — 8,192 against 18,678 — and it is worth having, with two honest limitations.

The threshold is a guess that ages. A test whose dump is legitimately small fails it; a test whose dump grows makes it meaningless. It is a smoke alarm, not a measurement.

And it cannot catch a truncation above the threshold. A 10 MB cap on a 50 MB dump leaves 10 MB, which passes any threshold anybody would set.

What it is good for is the case this chapter opened with: distinguishing nothing from something. -s (non-empty) is the version with no guess in it and it belongs on every artifact a flow produces:

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

[ -s "$d/dump.vcd" ] || { echo "dump is empty or absent" >&2; exit 4; }

The complete answer for a binary artifact is the producer's status plus an end-of-file structural check, with size as a cheap prior. For a VCD that is a final line beginning with # followed by at least one value change; for any format, it is whatever the format says "finished" looks like — and if the format does not say, that is worth knowing before you depend on it.

5. Where These Checks Go

Immediately after the tool, inside the wrapper that ran it, before anything downstream reads the artifact:

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

( cd "$d" && exec vvp "$root/logs/sim.vvp" … ) > "$d/run.log" 2>&1
rc=$?
printf '%s\n' "$rc" > "$d/tool.rc"
"$root/bin/logcheck" "$d/run.log"; lc=$?
printf '%s\n' "$lc" > "$d/logcheck.rc"

Three properties.

The check runs where the context is. The wrapper knows which run this is, where its log should be and what the tool returned. A central checker running later over a results directory has to reconstruct all of that, and Chapter 31.7 measured what a directory scan cannot know.

Its result is recorded, not acted on. logcheck.rc goes into the run directory beside tool.rc, and Chapter 32.4's collector picks both up as columns. The wrapper does not decide the regression's fate; it records evidence, which is Chapter 32.2's separation of dispatch from interpretation.

And it does not repair anything. A truncated log is not deleted, not re-run, not patched. It is the evidence that something truncated it, and Chapter 33.1 made the general argument: a tool that repairs its input destroys the reason it was needed.

Practice

Write the "no ERROR line" check and run it on a good log.
Run it on an empty file, on half a file, and on a path that does not exist.
Count how many of the four it gets wrong, and in which direction.
Look at grep's exit status for each of the four and say what it distinguishes.
Write the check as [ "$n" -eq 0 ] with n empty and see what happens.
Truncate a log mid-word and match it against four patterns of decreasing looseness.
Find the loosest pattern that still matches.
Anchor the pattern at both ends and re-run.
Write a checker made only of "must be present" conditions.
Give it a file that ends on a line boundary but stops early.
Explain why the trailing-newline check does not subsume the end-marker check.
Try [ "$(tail -c1 f)" = "" ] and work out why it cannot distinguish the two cases.
Detect "both verdicts" with a product and "no verdict" with a sum.
Give no-file and empty-file different statuses and justify it.
Produce a waveform under a file-size cap.
Check its header and its $enddefinitions marker.
Compare its last line against a complete one's.
Check the log and the artifact together and say what that adds.
Add a minimum-size threshold and name its two limitations.
Replace it with -s and say what you lose and gain.
Put the check in the wrapper and record its result rather than acting on it.
Resist repairing a truncated log, and say why.

Check Your Understanding

What assumption does Chapter 34.1's advice rest on?
What did the "no ERROR line" check say about the four files?
Which three were wrong, and in which direction?
What are grep's three exit statuses and what does each mean?
How was that information discarded?
Give the three different wrong behaviours of the -eq idiom.
What does the truncated log actually contain?
Which patterns matched it, and which did not?
Why is matching a truncated verdict especially dangerous?
Give the two defences, and why both are needed.
List the six "must be present" conditions.
Why can a presence-based check not confuse "nothing wrong" with "nothing happened"?
Name the four earlier chapters that met this shape.
What does the trailing-newline check catch that the end-marker check does not, and vice versa?
Why is a file ending exactly on a line boundary not unusual?
Why tail -c 1 | od rather than comparing a command substitution?
How do the sum and product catch the two verdict problems?
Why are statuses 3 and 4 separate?
What does a truncated waveform still have, and why?
What does a "dump present" check conclude about both?
What is the only observable difference, and where?
Give the three rules for validating a binary artifact.
Why is the tool's status the right signal for an artifact but not for a verdict?
What does checking the log and the artifact together add?
Give the two limitations of a size threshold.
What is -s good for?
Why does the check belong in the wrapper?
Why record its result rather than act on it?
Why must it not repair anything?

Answers

That there is a log, and that it is all there.
PASS, for all four.
The empty file, the truncated file and the absent file — all in the direction that reports a pass.
0 matched, 1 did not match, 2 something went wrong — a missing file, permissions, a directory.
$(grep -c …) keeps only the output. The status went nowhere, and the empty string that came back compared equal to zero.
A false pass when guarded; a syntax error — [: : integer expression expected — when written plainly; or a silently skipped check.
Two lines: the header, and TB TEST PASS — cut in the middle of PASSED.
'TEST PASS' and 'PASS' matched; 'TEST PASSED' and 'TEST PASSED$' did not.
Because it would report a pass from a run killed at that moment for any reason — including the reason the verdict was going to be FAILED.
Anchor the pattern, and check the file ends properly. Anchoring alone cannot tell a complete log from one truncated after the verdict.
The file exists; is non-empty; ends in a newline; contains $finish called; states exactly one verdict; and has no error line beside a PASSED.
Because nothing happened fails every one of them, while it satisfies every absence-based one.
Chapter 31.2's empty test list, 31.7's disk scan, 32.5's zero-row results file and 32.7's arithmetic over an empty set.
The newline check catches a file cut mid-line; the end-marker check catches one that ends cleanly but never reached the end of the run.
Because a buffer boundary falls on a newline roughly once in every few dozen lines.
Because command substitution strips trailing newlines, so the comparison is true for a file ending in a newline and one ending in nothing.
The sum being zero means no verdict; the product being non-zero means both.
Because no file means the tool never wrote one, while an empty file means it created one and died before the first flush — different failures of the flow.
A valid $version header and a $enddefinitions marker, because both are written in the first few hundred bytes before any work happens.
That both are usable.
The last line: the complete dump ends with a value change, the truncated one with a bare # — a timestamp with nothing after it.
Check the end rather than the beginning; prefer the producer's own status; and check the log and the artifact together.
Because a truncated write is exactly the kind of failure a tool does report, whereas a failing test is not a tool failure at all.
Both were cut off by the same cap at the same moment, so two truncated artifacts is a stronger signal than either alone — and a log-only check would miss that the waveform went too.
The threshold is a guess that ages with the design, and it cannot catch a truncation that leaves more than the threshold.
Distinguishing nothing from something, with no guess in it.
Because the wrapper knows which run it is, where the log should be and what the tool returned — context a later central checker has to reconstruct.
Because dispatch records evidence and the report interprets it; the wrapper does not decide the regression's fate.
Because a truncated log is the evidence that something truncated it, and a tool that repairs its input destroys the reason it was needed.

6. Remember

"No error line was found" answers the same way for a clean run, an empty file, half a file and no file. Three of four were wrong, all in the shipping direction.
grep returns 0, 1 and 2 — matched, no match, could not read — and $(grep -c …) throws the status away.
A truncated TEST PASSED ends as TEST PASS, which grep 'PASS' happily matches.
Anchor the pattern and check the file ends properly. Neither alone is enough.
Build checks from presences. Nothing-happened fails every presence check and satisfies every absence check.
Two kinds of incomplete: cut mid-line, and ending cleanly without reaching the end of the run. Neither check subsumes the other.
tail -c 1 | od, not a command substitution — substitution strips the newline you are testing for.
Sum catches "no verdict", product catches "both".
A truncated waveform keeps its header and its $enddefinitions. Check the end, trust the producer's status, and validate the log and the artifact together.
A size threshold is a guess that ages and cannot catch truncation above it. -s is the version with no guess.
Run the check in the wrapper, record its result as a column, and repair nothing.

7. What Is Next

Both chapters so far have treated a failure as a fact to be reported accurately. Chapter 34.3 takes on the class where that is not enough — failures worth retrying — and measures what happens when a retry is applied to a failure that is not.

Where this fits

Part of the Linux & Bash curriculum.