bisect ends with a commit marked good and bad

bisect ends with a commit marked good and bad

[Sanjoy Mahajan]

In doing a huge bisect (from 1875 or so revisions but fortunately
log(anything) is not too big) to chase a S3 sleep bug (bugme #5989), I
also noticed another problem.  In several 'good' kernels, where S3
sleep-wake worked twice, the fan would not turn on despite the
temperature getting high, after the system went through two sleep-wake
cycles.  [In the 'bad' kernels the system hangs on the second sleep, so
I couldn't collect any data about the fan.]

The result is that, for several kernels, I got free bisect data about
this second bug.  I tried feeding this data to a fresh bisect, but
bisect says that one particular commit is good and bad.  Here's the
script to run bisect:

  #!/bin/bash -x
  bad="a2d823bf ee408c79 d1138cf0"
  good="0f442aa2 49799291 4a90c7e8"
  git bisect start
  for r in $bad  ; do git-bisect bad  $r ; done
  for r in $good ; do git-bisect good $r ; done

The output:

  + bad='a2d823bf ee408c79 d1138cf0'
  + good='0f442aa2 49799291 4a90c7e8'
  + git bisect start
  + for r in '$bad'
  + git-bisect bad a2d823bf
  + for r in '$bad'
  + git-bisect bad ee408c79
  + for r in '$bad'
  + git-bisect bad d1138cf0
  + for r in '$good'
  + git-bisect good 0f442aa2
  d1138cf035ad5a8dc0796b213bd078a2fb92eb7c was both good and bad
  + for r in '$good'
  + git-bisect good 49799291
  d1138cf035ad5a8dc0796b213bd078a2fb92eb7c was both good and bad
  + for r in '$good'
  + git-bisect good 4a90c7e8
  d1138cf035ad5a8dc0796b213bd078a2fb92eb7c was both good and bad

At first I thought it was impossible for a bug to behave this way, and
concluded that my data must be corrupt, since d1138cf0 is marked bad.
But on further thought, I'm not sure.  Maybe there are quadratic
interactions between patches.  For example, if a particular bug happens
only when two patches occur together?  No, that would result in the
merge of their branches being the problematic commit.  So I'm stuck.
Before I conclude that the data is corrupt and spend several hours
retesting several kernels, I thought I'd ask for advice from the
entomologists and bisectors.

How would I use gitk to show the those three good and three bad commits,
and their spanning tree?  Neither the man entry nor the examples of its
use in git-bisect taught me enough to use it properly.

-Sanjoy

Re: bisect ends with a commit marked good and bad

[Junio C Hamano]

Sanjoy Mahajan <sanjoy@mrao.cam.ac.uk> writes:

> How would I use gitk to show the those three good and three bad commits,
> and their spanning tree?  Neither the man entry nor the examples of its
> use in git-bisect taught me enough to use it properly.

The way bisect narrows down bug hunting is to find a single
regression.  IOW, the only question you can ask bisect is "this
older one was known to be good, but somehow this new one is bad.
If it was caused by one bug introduced somewhere during the
course of changes between the two, which one is it?"

So you always start by giving one good and one bad (or one bad
and one good, the order does not matter).  That leaves * as
suspects.

    o---o---O---*---*---*---*---X---o
         \             /
          *---*---*---*

        O (good) X (bad)

Since it is finding a single regression, o commits are
irrelevant.  commits after bad one X may have fixed the bug but
you are not interested in it.  Commits before good one O might
have been broken in some other way, but we are looking for a
single regression, so they do not really matter either.

Then bisect suggests you one of (*) commits.  Not at random, but
somewhere midway.

    o---o---O---*---*---*---*---X---o
         \             /
          *---*---*---?

        O (good) X (bad)

If ? is good, then three * suspects are good so you then have to
worry about remaining four * between the first O and X.  That's
how you narrow things down.

You say a2d823bf is bad and 0f442aa2 is good.  However, the
a2d823bf is a proper ancestor of 0f442aa2.  That is, earlier it
was good but now it is good.  As if you are trying to locate the
commit that fixed the bug.  This is an impossible situation for
the bisect.

So your initial input may be truly good and bad commits, but
there might be more than one regression involved.

To look at the graph, you could do something like this:

for r in $good; do git tag good-$r $(git-rev-parse --verify $r); done
for r in $bad; do git tag bad-$r $(git-rev-parse --verify $r); done
gitk $(git-rev-parse $good) $(git-rev-parse --not $bad)

You will notice there is only one bad-* way below all the good-*
ones.  Another possibility is maybe you have your good and bad
swapped?