git/list[1] front-page[2] threads[3] people[4] search[5] about
 

bisect ends with a commit marked good and bad

From
SMSanjoy Mahajan <sanjoy@mrao.cam.ac.uk>
Date
Feb 15, 2006, 07:19 UTC
Message-ID
<E1F9Gwm-0001Dy-3b@approximate.corpus.cam.ac.uk>

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
Next: Junio C Hamano
Message 1 of 2 in “bisect ends with a commit marked good and bad”
  1. Sanjoy MahajanFeb 15, 2006
  2. Junio C HamanoFeb 15, 2006

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.