crash on Xcode 6.3.2
HongliYu opened this issue · 8 comments
Its happening with me too. Any fix coming soon ?
If you have a close look at the crash, it says "launch path not accessible". Can you tell me whether you've set ClangFormat-Xcode to use the bundled version of clang-format, or the system-provided one and then check that whichever one you're trying to use exists?
I can stop this from crashing, but if the binary can't be launched the plugin is not going to format your code.
Run the project, the plugin automatically installed in /Users/baidu/Library/Application\ Support/Developer/Shared/Xcode/Plug-ins.Open Xcode load bundle, use the plugin then format and crash. which path is not accessible? @tonyarnold
@tonyarnold thanks. Worked for me.
I'm having the same issue, but only on my MacBook Pro. @nijindal what was your resolution?
I've tried examining the location of the plug-in and the clang-format executable. They all seem accessible and the same as on my desktop. Any help would be appreciated.
Found the problem: I was bitten by two issues, simultaneously.
- If the plugin doesn't find a "system" one, which is what I had selected, it then falls back to the bundled one. However, the clang-format in my Xcode-plugin, did not have execute permission. Giving it +x permission got me around the crashes.
(Why did it not have +x permission? I don't know.) - Why was the system clang-format (the newer clang I installed) not used? Because of a very strange thing that I am doing. The plugin, tries to find the system clang-format by doing a "which clang-format". It does so via bash. The exact command is bash -l -c "which clang-format". The -l forces a login shell. Here's the relevant code:
NSString *shellString =
[environmentDict objectForKey:@"SHELL"] ?: @"/bin/bash";
NSPipe *outputPipe = [NSPipe pipe];
NSPipe *errorPipe = [NSPipe pipe];
NSTask *task = [[NSTask alloc] init];
task.standardOutput = outputPipe;
task.standardError = errorPipe;
task.launchPath = shellString;
task.arguments = @[ @"-l", @"-c", @"which clang-format" ];
I have a long forgotten
`echo "BASH PROFILE" `
in my .bash_profile that gets echoed when I login or create a new bash shell. The plugin would mistake the "BASH PROFILE" string for the output of which. And it would then check to see if that command exists and is executable. If not, then it falls back to the internal clang-format. The fix is to skip the -l, but I am not sure why it is there in the first place.
Also, keep in mind that bash-profiles can sometimes contain date and other commands that write to the screen, plus configuration text or scripts that can take a bit of time to execute. I am not sure that it is a good idea to always follow this path for each reformat of a file or block of text. For one, this path to the system clang-format should be cached. For another, it may be best not to use bash with the -l option.
Just merged #120 anyone wanna confirm that it fixes this issue for them?
Gonna close this issue, just reopen it here if that change didn't fix it for you.