brew doctor not terminating

[meteorpaul]

'brew doctor' on my mac osx 10.8.2 appears unable to terminate, perhaps caught in infinite loop. It has been running for several hours now with 'xcrun' and 'ruby', the only obvious clues to what is going on, flashing up on the shell window title bar. The last time I ran 'brew doctor', maybe a couple of weeks ago, it successfully terminated after a few seconds.

The only recent changes I've made were to issue: 'brew tap homebrew/dupes' and 'brew install gcc'. I then deleted the sym link to llvm-gcc-4.2 in /usr/bin before deciding it was a bad idea and changing it back to llvm-gcc-4.2.

Any ideas as to what is going on and what I should do?

[meteorpaul]

I decided to terminate 'brew doctor' after waiting several hours for it to terminate. Here is the output:

^C/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/set.rb:432: Interrupt
from /usr/local/Library/ENV/4.3/gcc-4.2:9:in `require'
from /usr/local/Library/ENV/4.3/gcc-4.2:9

[meteorpaul]

To follow up: I rebooted my mac and tried 'brew doctor' again. This time it terminated successfully.

[samueljohn]

This is a 👻 in the machine.

It is funny because I had this very issue myself just recently after brew install apple-gcc42. brew doctor and brew --config hangs, too. Rebooting solved this. But then I was not able to reproduce (even removing and re-brewing apple-gcc42 worked then flawless).

I noticed that when the problem occurred, my the xcrun behaved ABSOLUTELY strangely and which xcrun pointed to $(brew --prefix)/Library/ENV/4.3/xcrun but my PATH did not even include the ENV/4.3 dir at all! How could this be? How can my shell even find an executable not in the PATH. Some strange caching?

Heisen - 🪲

@ping mxcl

However, I just suggest that superenv should hard code xcrun and change
exec "xcrun", cmd.tool, *cmd.args
to
exec "/usr/bin/xcrun", cmd.tool, *cmd.args

[MikeMcQuaid]

I've seen this before too. I think it's something Spotlight related.

[samueljohn]

Hardcoding /usr/bin/xcrun should avoid this (hopefully).

[MikeMcQuaid]

@samueljohn Happy to do that. Does that still exist with Xcode-only?

[samueljohn]

Does that still exist with Xcode-only?

Yes, I have /usr/bin/xcrun on my Xcode-only Mac, too!

[MikeMcQuaid]

Actually, looking at the files, we can't/shouldn't do this because that defaulst the point of the xcrun wrapper. Perhaps we could make the xcrun call /usr/bin/xcrun if superenv isn't in the path or something.

[MikeMcQuaid]

Doesn't seem to fix it. If you run brew doctor -d you can see this is breaking on the fails_with :gcc in libkate. If you change that to clang or remove it doctor runs fine. @adamv this will be the same problem as brew uses I bet.

As this is shelling out rather than calling Ruby code it's tricky to find this infinite loop. Trying some more to work this out.

[MikeMcQuaid]

It seems the problem is the new xcrun in the latest Xcode uses Spotlight and finds Homebrew's superenv if you tell it to look for a missing tool e.g. gcc-4.2. In this case I've just discarded the xcrun result if it finds something in superenv.

[jacknagel]

Good call, now that you point it out I remember Max saying something about how xcrun can end up caching the superenv bin.

[samueljohn]

Good work, Mike!

[samueljohn]

Don't believe it.
Wow this Heisenbug "xcrun <-> ruby"-loopy thing just occurred to me again when I did brew uses <formula>.

Pressing ctrl+c reveals a litte bit for us to debug this further. I am just pasting this here.

VERBOSE=1 brew uses libsequence
^C/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/pathname.rb:287:in `chop_basename': Interrupt
    from /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/pathname.rb:298:in `split_names'
    from /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/pathname.rb:469:in `realpath'
    from /usr/_local/Library/ENV/4.3/../libsuperenv.rb:11:in `cleanpath'
    from /usr/_local/Library/ENV/4.3/../libsuperenv.rb:28
    from /usr/_local/Library/ENV/4.3/gcc-4.2:8:in `require'
    from /usr/_local/Library/ENV/4.3/gcc-4.2:8

~/Dropbox/homebrew-science ❯ brew uses python
^C/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/pathname.rb:1083: Interrupt
    from /usr/_local/Library/ENV/4.3/../libsuperenv.rb:11:in `require'
    from /usr/_local/Library/ENV/4.3/../libsuperenv.rb:11:in `cleanpath'
    from /usr/_local/Library/ENV/4.3/../libsuperenv.rb:28
    from /usr/_local/Library/ENV/4.3/gcc-4.2:8:in `require'
    from /usr/_local/Library/ENV/4.3/gcc-4.2:8

Now the strange thing is, I have two separated homebrew installs and I was in the one with brew --prefix==/homebrew but somehow the one from /usr/_local shows up in the trace ...

Continue to debug (because if I reboot, this will be gone)

[samueljohn]

If I change

path = `/usr/bin/xcrun -find #{tool} 2>/dev/null`.chomp

to

path = `/usr/bin/xcrun -n -find #{tool} 2>/dev/null`.chomp

This error is gone as -n disables the caching of xcrun. Performance-wise, this should not hurt as, because the `MacOS.locate caches it's results, too.

[samueljohn]

Here is the test:

$ xcrun -find gcc-4.2
/usr/_local/Library/ENV/4.3/gcc-4.2
$ xcrun -n -find gcc-4.2
xcrun: error: unable to find utility "gcc-4.2", not a developer tool or in PATH

The latter is the thing we want, because /usr/_local/Library/ENV/4.3/gcc-4.2 was indeed not in my PATH and should not be as it is a different homebrew installation.

All the necessary tools are found with the -n option:

xcrun -n -find clang++
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++
xcrun -n -find ar
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ar
$xcrun -n -find gcc
/Applications/Xcode.app/Contents/Developer/usr/bin/gcc

This is an excellent opportunity to test and fix this ...

[samueljohn]

brew --config takes one second longer. But compared to infinity this is pretty short.

[samueljohn]

The commit of e26b70b from @MikeMcQuaid kind of fixed the loop by explicitly rejecting tools that are located in any "Library/ENV".

After some further testing, I am convinced that xcrun does _not_ use fancy spotlight. Is uses what is stored in /usr/share/xcode-select/ (a symlink and a text file) to know where Xcode is and looks in the current PATH. Additionally is has a cache. -verbose reveals this:

xcrun -verbose -find  gcc-4.2
xcrun: note: SDKROOT = '/'
xcrun: note: TOOLCHAINS = ''
xcrun: note: DEVELOPER_DIR = '/Applications/Xcode.app/Contents/Developer'
xcrun: note: xcrun via gcc-4.2 (xcrun)
xcrun: note: database key is: gcc-4.2|/||/Applications/Xcode.app/Contents/Developer|
xcrun: note: lookup resolved in '/var/folders/96/s7fk5nzj5sn9_xkzv1_g9_p00000gn/T/xcrun_db' : '/homebrew/bin/gcc-4.2'
/homebrew/bin/gcc-4.2

[tomapp]

Hello !

I reopen this issue cause i have the same problem with my homebrew install. I run under Mac Osx 10.9.8. And since some weeks i have the same trouble. When i launch brew doctor or brew update it's seem to be stuck in an infinite loop.

Someone have an idea please ?

[MikeMcQuaid]

@tomapp Do you have Spotlight disabled?

[tomapp]

No it wasn't but, finally i just remove totally Homebrew and reinstall it and now it works. Thank you!