EXC_BAD_ACCESS when connect to unix domain socket

[wspl]

I have a unix domain socket created by tokio-uds, and I can make connection with it normally by net.socket of node.js.

But when I connect to this socket via BlueSocket:

let socket = try! Socket.create(family: .unix)
try! socket.connect(to: "/Users/Plutonist/Downloads/hello.socket")

would cause crash at Socket.swift:1927:

1926    // Create the signature...
1927*   self.signature = try Signature(socketType: .stream, proto: .unix, path: path)
1928    guard let signature = self.signature else {

If I use it this way:

let socket = try! Socket.create()
try! socket.connect(to: "/Users/Plutonist/Downloads/hello.socket")

Will throw an exception:

Thread 1: Fatal error: 'try!' expression unexpectedly raised an error:
Error code: -9973(0x-26F5), Socket has the wrong protocol, it must be UNIX socket

This problem is very weird, and I have confirmed that the cocoa's sandbox mechanism is turned off and that FileManager can also obtain socket file stats.

[billabt]

Can you give me a more complete example? So far, I've been unable to reproduce the problem.
Note: I'll be on vacation until July 20th just in case you don't hear from me before then.

[qvacua]

I'm also getting an EXC_BAD_ACCESS. To reproduce with release 1.0.14 on macOS 10.13.6:

do {
  let okPath = "111111111111111111111111111111111"
  assert(okPath.utf8.count == 33)
  _ = try Socket.Signature(socketType: .stream, proto: .unix, path: okPath) // ok

  let problematicPath = okPath + "1"
  assert(problematicPath.utf8.count > 33)
  _ = try Socket.Signature(socketType: .stream, proto: .unix, path: problematicPath) // EXC_BAD_ACCESS
} catch {
  print(error)
}

[billabt]

Thanks for the example. I'll have a look at it. Seems like it should be relatively easy to fix. Thanks again.

[billabt]

I've added a test that basically mimics what you provided above and it passes without any problem on the same version of macOS, 10.13.6. So, at this point, I still can't reproduce.

[billabt]

I've issued a new release that contains the new test. That version, 1.0.15, is available.

[qvacua]

@billabt Hm, that's odd. Here's what I did:

• Create a new Xcode Cocoa App project with unit tests
• Use Carthage to build BlueSocket and link, copy etc. the framework into the app and test targets
• Paste the above code to the testExample() and add import Socket
• Run the tests => EXC_BAD_ACCESS

But yes, if I clone BlueSocket and do swift test, everthing's fine... 🤨

[billabt]

Can you zip up the project and send it to me? Thanks.

[qvacua]

Here it is: SocketTest.zip

[billabt]

I was able to run your project without issue... Are you still having the problem?

[qvacua]

@billabt I was able to reproduce it more easily:

• Checkout my fork: https://github.com/qvacua/BlueSocket.git
• Open the Xcode project and run the tests

I changed the following in my fork:

• Use the Release configuration for the test target (on macOS)
• Remove @testable from the import statement (not possible due to the Release configuration)

When I run all tests I get the following at some point:

When I run only testDomainSocketPath(), then I get:

(I'm on macOS 10.13.6 and using Xcode 9.4.1.)

[qvacua]

I'm having the same issues with Xcode 10.0

[billabt]

It took awhile to find it... It turns out this is an optimization bug. In the first case, when built optimized, the path variable passed is for some unknown reason set to an empty string while in the listen function. In the second case, the function succeeds but fails to return properly. Not sure why either is happening but I plan to file a bug report with Apple. In the meantime, you can change project to turn off optimization.

[billabt]

I decided to look a bit deeper into this. Turns out there was a buffer overflow happening in the initializer for Signature but only when the optimizer was turned on. This'll be fixed in the next release which should come out very shortly... Thanks.

[billabt]

Fixed in version 1.0.19. Let me know if you have any more problems. Thanks.

[qvacua]

Thanks! The issue is gone.