Closed a-nogikh closed 1 year ago
Some random ideas:
bisect skip
(or, rather, bisect good
?) those revisions, from which the guilty commit is not reachable. This won't always help though -- we don't really have many successful cause bisections.--first-parent
.test()
runs.
Linux source tree history is convoluted: tons of merges in and out of dozens of trees. There are also cases when history branches off at an older revision, some changes are made, and then they are only merged months later.
We seem to have trouble handling the case when
git bisect
visits those branches of history, which, though merged into the mainline after the bug was already there, did not have the bug at the moment of their branch-off. We correctly conclude that the revision has no bug and the bisection process goes off the rails.Example:
Bug: https://syzkaller.appspot.com/bug?extid=70b97abe3e253d1c3f8e, bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=11aeb085a80000
We determine that the bug was indeed present at the faulty revision:
The bug is not present on HEAD:
And then all following bisection steps finish with
all runs: OK
, which lands us atWhich is based on 6.1:
We began to actively trigger this bug ~ month ago, when the mainline was already at
v6.5
.