CC @hyangah @eliasnaur @steeve

My guess (but it's just a guess) would be that the gomobile bindings are passing in a slice that aliases Swift-owned memory, and (because objects in Go's heap are not visible to the Swift reference counters) that memory is getting freed upon return.

In other words: I suspect a classic use-after-free bug, obscured by the use of two garbage collectors.

The usual fix for such a bug is to extend the aliased object for the lifetime of the alias. (In a reference-counted language, that would imply pinning the Data reference for the lifetime of the returned Bytes object.)

Or, you can copy passed-in slices rather than retaining references.

Indeed, a NSData is copied before being passed to Go, and then freed, according to https://github.com/golang/mobile/blob/e8b3e6111d02c5a0a25ea00257319a0c01c12806/bind/objc/seq_darwin.m.support#L191

Strangely enough, the following code prints the correct results in all 5 cases:

var data = Data(repeating: 0, count: 8)
let mutableData = NSMutableData(bytes: &data, length: 8)
print("Data: \(Array(UnsafeBufferPointer(start: mutableData.bytes.assumingMemoryBound(to: UInt8.self), count: 8)))")
let bytes = GocodeNewBytes(mutableData as Data)!
print("Elements: \([UInt8](bytes.getElements()!))")
print("Data: \([UInt8](data))")

This is interesting since now NSMutableData is used which executes the branch where the data is actually not copied.

After some more investigation I am now pretty sure what the actual problematic behavior is. These are the steps happening in my small example from the issue description:

1. The data object passed into GocodeNewBytes is copied here because it is not of type NSMutableData. A pointer to the copied array is assigned to a nbyteslice struct.
2. The nbyteslice structs lands subsequently in the toSlice function, which does not copy the underlying data of the nbyteslice struct. A pointer to the array forms the data source of a newly created []byte object.
3. This []byte object is actually passed to the GocodeNewBytes function and stored in the constructed object as a field.
4. Eventually, in some code generated here the array created in step 1 by copying the data object is freed. That means, the data source of the []byte object stored in the GocodeNewBytes object is simply removed.

It is the same like doing the following in Go:

p := C.malloc(4)
arr := (*[1 << 30]byte)(p)[:4:4]
// Put some values into 'arr'.
b := NewBytes(arr)
// Values of 'b.elements' are okay.
C.free(p)
// Now 'b.elements' could be anything.

In the cgo wiki it is explicitly stated that ...

... [i]t is important to keep in mind that the Go garbage collector will not interact with this data, and that if it is freed from the C side of things, the behavior of any Go code using the slice is nondeterministic.

So from my understanding, this nondeterminism is exactly the root cause of this issue.

The following solutions come into my mind:

• Always copy sequences before passing them to functions, because it cannot be known whether a Go function just uses its arguments or stores them somewhere.
• Go libraries need to take care that only copies of arguments are stored.
• NSMutableData should always be used instead of Data/NSData as the correspondence to Go's []byte because NSMutableData is passed thought the Go code as it is without creating and freeing copies, making the Swift/Objective-C side responsible for garbage collection.
• Document this behavior very well in gomobile to make users aware of it.

Good one !

From what I'm reading online:

let d = Data() // should be NSData
var d2 = Data() // should be NSMutableData

I'm not able to confirm this yet, however....

It makes me wonder, though, wether it's gomobile's job to ensure one does not mutable a []byte passed from ObjC/Swift code. Since the underlying data structure is never backed by Go, either it is copied into Go's memory, or not copied/freed at all. @eliasnaur, is there a reason not to do that ?

@eliasnaur it does!

Actually I was wondering why gobind would copy at all.
I'm actually thinking []byte passed to Go functions should never be copied, and it's the responsibility of the callee to copy if they want to retain that data.
Or perhaps do what JNI does with GetByteArrayElements, saying wether the buffer was modified or not. But it's getting complex...

Is it possible to read and write to a []byte between go and swift in order to handle data streams? Did you face this problem @steeve?

The intention behind not copying []byte is to enable io.Reader-like interfaces

This is exactly the thing I'm failing completely to do with gomobile and Swift. I can define a function like this in Go:

func Foo(b []byte) {
  b[0] = 1
}

... and then call it from Swift:

var b = Data(count: 1)
MobileFoo(b)

... and the data change in Go is never reflected back in Swift.

It doesn't matter if I explicitly create an NSMutableData either — same result.

What am I missing? This works fine with Java.