cc @akyrtzi

This is an SKS bug–result isn't a dictionary (??)

Can we reproduce on swift-DEVELOPMENT-SNAPSHOT-2016-04-12-a?

If so, post the output of reproducing when launching xcode from https://github.com/AnarchyTools/SublimeAnarchy/blob/master/package/sk2p/instrumentXcode.sh that generates a lot of output, so you may want to redirect to a file.

Comment by Matt Whiteside (JIRA)

Yes, this is still happening with the April 12th toolchain, with the Xcode project mentioned in the before. I launched with the source kit logging flag as you suggested. Here is the last line of the output:

Assertion failed: (GlobalConn), function getGlobalConnection, file /Users/buildnode/jenkins/workspace/oss-swift-package-osx/swift/tools/SourceKit/tools/sourcekitd/bin/XPC/Client/sourcekitd.cpp, line 336.

The full stack trace is attached. stack-trace-2.txt

Hi Matt, thanks for following up!

I'm actually not able to reproduce this, here is a working log from snapshot swift-DEVELOPMENT-SNAPSHOT-2016-04-12-a for comparison

xcode.log

Your log was actually a little different than I expected from the original stacktrace (behavior may have changed in swift-DEVELOPMENT-SNAPSHOT-2016-04-12-a). Comparing your log against mine, the key difference seems to be

sourcekit: [2:sourcekitd_initialize:12299: 0.0002] initializing
sourcekit: [2:connection-event-handler:34315: 0.0005] connection invalid error (shutdown)

Consulting source suggests we are here:

 } else if (event == XPC_ERROR_CONNECTION_INVALID) {
        // Client initiated shutdown.
        LOG_INFO("connection-event-handler", High,
                 "connection invalid error (shutdown)");
        xpc_release(GlobalConn);
        GlobalConn = nullptr;

      }

I'm not sure I believe that comment–from this log we can rule out that Xcode asked for a shutdown. Looking at OS documentation:

> XPC_ERROR_CONNECTION_INVALID will be delivered to the connection's event handler if the named service provided to xpc_connection_create() could not be found in the XPC service namespace. The connection is useless and should be disposed of.

My suspicion is that the service is actually never spinning up, but I don't know why that would happen only on your system. Did you download the binary from swift.org? That rules out a lot of explanations...

Comment by Matt Whiteside (JIRA)

Hi Drew, thanks for looking at this.

Yes it's strange that you aren't seeing this. Yes, I redownloaded the swift-DEVELOPMENT-SNAPSHOT-2016-04-12-a toolchain from swift.org this morning to check that it was still happening. I tried deleting all of my Xcode plugins thinking one of them was causing it, but it's still happening. If I have any other ideas, I will update here.

-Matt

Comment by Matt Whiteside (JIRA)

One other thing I noticed: it doesn't seem to be specific to that Xcode project that I posted. Whenever I open a swift-based Xcode project, I'm seeing the crash, but it doesn't crash when I open a C++ only project.

-Matt

> but it doesn't crash when I open a C++ only project.

This is because it's an SK-related bug, and SK (to the best of my knowledge) only deals with Swift.

Does this happen with the default Xcode toolchain?

Comment by Matt Whiteside (JIRA)

No, it doesn't crash with the default toolchain.

-Matt

I'm taking shots in the dark here. If you run /Library/Developer/Toolchains/swift-DEVELOPMENT-SNAPSHOT-2016-04-12-a.xctoolchain/usr/lib/sourcekitd.framework/Versions/A/XPCServices/SourceKitService.xpc/Contents/MacOS/SourceKitService before launching Xcode, does it make a difference? That program should hang eternally.

Comment by Matt Whiteside (JIRA)

Well that turned out to be a good shot, because when I run that command, I get this:

[1] 30869 illegal hardware instruction

and it never starts.

-Matt

weird. Well, we're onto something. Did that generate a crash report?

Comment by Matt Whiteside (JIRA)

Yes:

This looks like a libxpc assertion failure. Unfortunately, that is an OS library and isn't open source. So we are rapidly going outside what I understand.

I assume the equivalent program in the XcodeDefault.toolchain would hang as expected. If so, the next step would probably require trying to figure out what is different about those two programs, that libxpc doesn't like one of them. Realistically, that probably involves building from source on an affected system.

One thing to try short of that would be to replace /Library/Developer/Toolchains/swift-DEVELOPMENT-SNAPSHOT-2016-04-12-a.xctoolchain/usr/lib/sourcekitd.framework/Versions/A/XPCServices/SourceKitService.xpc/Contents/Info.plist with the one from the xcode toolchain. This won't actually work at all from Xcode's POV (sourcekitd.framework uses a softcoded value for the XPC service name that must match the plist) but it might cause a change in behavior when running the crashing daemon from the CLI. If so, we could isolate it down to some particular plist key.

Another thing short of source-level debugging is to the opposite–place the xcode binary inside the open toolchain daemon. That is not really a great solution either (for starters, you'd be using Swift 2.2 sourcekit with Swift 3 toolchain) but there may be a clue there to someone who has access to the libxpc internals.

Comment by Matt Whiteside (JIRA)

Drew, Many thanks for looking into this, and nice work.

When I have a moment I will try the things you've suggested.

-Matt

Comment by Matt Whiteside (JIRA)

I'm happy to report that this is no longer happening with the May 3rd toolchain.

-Matt

I'm seeing a crash in the latest toolchain, which looks similar (in sourcekitd_send_request_sync), but I'm not sure it is is identical. Written up as SR-1406 with an example (should maybe be merged into this bug though if they really are the same issue).

That's a pretty generic entry point, so a new bug is probably the right thing to do.