diff options
| author | Dmitry Vyukov <dvyukov@google.com> | 2020-09-12 11:03:52 +0200 |
|---|---|---|
| committer | Dmitry Vyukov <dvyukov@google.com> | 2020-09-12 13:03:27 +0200 |
| commit | c38fcca50dbf789b6524280b8cf32c65d4b4e5e4 (patch) | |
| tree | 25036b78e9d5404eabf87b53ba8baff35c307f21 /sys/linux/dev_video4linux_vim2m.txt.const | |
| parent | 306464056c8af8d00798b5ef9195950bd6502314 (diff) | |
pkg/repro: fix execution of non-repeatig C programs
If we have a non-repeating C reproducer with timeout > vm.NoOutputTimeout and it hangs
(the reproducer itself does not terminate on its own, note: it does not have builtin timeout),
then we will falsely detect "not output from test machine" kernel bug.
We could fix it by adding a builtin timeout to such reproducers (like we have in all other cases).
However, then it will exit within few seconds and we will finish the test without actually waiting
for full vm.NoOutputTimeout, which breaks the whole reason of using vm.NoOutputTimeout in the first
place. So we would need something more elaborate: let the program exist after few seconds, but
continue waiting for kernel hang errors for minutes, but at the same time somehow ignore "no output"
error because it will be false in this case.
Instead we simply prohibit !Repeat with long timeouts.
It makes sense on its own to some degree: if we are chasing an elusive bug, repeating the test
will increase chances of reproducing it and can make the reproducer less flaky.
Syz repros does not have this problem because they always have internal timeout, however
(1) it makes sense on its own, (2) we will either not use the whole timeout or waste the remaining
time as mentioned above, (3) if we remove repeat for syz repro, we won't be able to handle it
when/if we switch to C repro (we can simplify options, but we can't "complicate" them back).
Diffstat (limited to 'sys/linux/dev_video4linux_vim2m.txt.const')
0 files changed, 0 insertions, 0 deletions
