Description of problem: While trying to bisect an issue in the linux-next kernel tree, a first attempt ended up off in the weeds due to the way the kvm tree was merged. Since the test kernel didn't have KVM configured, I decided to use 'git bisect skip' to lop out the kvm patches. So I did: % git clone git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git % git bisect good v2.6.31-rc7 You need to start by "git bisect start" Do you want me to do it for you [Y/n]? y % git bisect bad HEAD Bisecting: 4851 revisions left to test after this (roughly 12 steps) [05470ac50bc1c4705153da17dec80760f3d314ce] Merge commit 'dlm/next' % git bisect skip 2959cd13ecc1fbe1b2339937481844ff963f1e7f..95a6e61f2c6f48af1e83461e8a70ce3374826fe ^C The 'skip' went off and was doing 20-30 forks/second. ps reported: % ps axw | grep git 33035 pts/2 S+ 0:00 git bisect skip 2959cd13ecc1fbe1b2339937481844ff963f1e7f..95a6e61f2c6f48af1e83461e8a70ce3374826fe 33036 pts/2 S+ 9:08 /bin/sh /usr/libexec/git-core/git-bisect skip 2959cd13ecc1fbe1b2339937481844ff963f1e7f..95a6e61f2c6f48af1e83461e8a70ce3374826fe 50230 pts/2 S+ 0:00 /bin/sh /usr/libexec/git-core/git-bisect skip 2959cd13ecc1fbe1b2339937481844ff963f1e7f..95a6e61f2c6f48af1e83461e8a70ce3374826fe 50231 pts/2 R+ 0:00 git rev-parse --verify 5c5129b54f2f346c86cd23fea67e71b45f7f84ff^{commit} 50233 pts/0 S+ 0:00 grep git I left that running last night, came back in and it was in a 100% usermode CPU loop, no forking. Looking at the process accounting, a total of 85,069 git-bisect processes got forked, and when I finally control-C'ed it, it had used a total of 83948.00 seconds of CPU. I did another 'git clone' into an empty directory and re-did the above commands, and it's doing it again - been running for 2 hours and has burned 91 mins of CPU already. Version-Release number of selected component (if applicable): git-1.6.4-1.fc12.x86_64 How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Ouch. Thanks for the clear steps to reproduce. I can confirm it still exists on 1.6.4.2, and nothing in the commits up through 1.6.4.4 make me think it's fixed yet. Do you think you can bring this to the git list (git.org, copying Christian Couder <chriscool> would probably be good)? If not, I can do so. But it's probably quicker if you can, as the folks there can ask you follow up questions directly if they need.
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '12'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
I haven't seen this recur in a long time, must be fixed in git 1.7.3, so I'll stick it with 'CLOSED CURRENTRELEASE'