Googling around I found #11689 and #15831, but both of those closed, I believe, without any resolution.

This is expected behavior.
The garbage collector looks for invalid pointers when it is scanning objects. The pointer you constructed is considered invalid by the runtime, because it is non-nil and points to a place that can never be mapped.
We could conceivably allow these kind of pointers. However, we like this check because it helps ensure that the compiler+runtime is never getting the decision about what is a pointer and what isn't wrong (a source of many bugs historically).

OK, thanks for taking a look.

For valid uses of unsafe.Pointer, see https://golang.org/pkg/unsafe.

The original crash we're investigating was on macOS, and involved CFTypeRef from CoreFoundation. Here's a code snippet which shows a similar crash:

package main

/*
#cgo LDFLAGS: -framework CoreFoundation

#include <CoreFoundation/CoreFoundation.h>
*/
import "C"

import (
	"fmt"
	"time"
)

func main() {
	x := C.CFTypeRef(uintptr(0x27))
	for i := 0; i < 1000000; i++ {
		fmt.Printf("%p\n", x)
		time.Sleep(1)
	}
}

But why is the Go GC treating C.CFTypeRef like unsafe.Pointer, i.e. scanning it for invalid pointers?

Or, I believe, this is equivalent:

/*

typedef const void *fooPtr;

*/
import "C"

import (
	"fmt"
	"time"
)

func main() {
	x := C.fooPtr(uintptr(0x27))
	for i := 0; i < 1000000; i++ {
		fmt.Printf("%p\n", x)
		time.Sleep(1)
	}
}

This comes up because some functions in the CoreFoundation library seems to be OK with these obviously non-pointer pointers, for instance CFGetTypeID.

Slightly more digging, as I'm picking up a library that someone else wrote to solve this crasher, so a lot of this is new to me. As far as CoreFoundation is concerned, 0x27 is a CFNumber whose value is 0, which I think is meant to be interpreted as a nil pointer in some contexts. I also noted that a nil pointer doesn't trigger the write barrier check in mbarrier.go (for good reason), so this might be a case in which the GC is being overly aggressive in calling this a bad pointer. It's not a huge deal, we can workaround it in a number of ways. Just thought I'd report it in case it's of interest to the Go authors or if someone else hits the same problem.

Also of note, we found this pointer in an array with other valid pointers. That's the contract of the CoreFoundation library call we are using.

Also of note, we're never dereferencing this pointer, we're just copying it around and assigning it to other values, or printing it via %p in our little tester above. So we were surprised that the runtime presumed it pointed to valid memory.

Yeah, it looks like Apple decided to pack non-pointer things into a pointer.

#include <CoreFoundation/CFNumber.h>
#include <stdio.h>

int main() {
	long long v[2] = {0x55555555555555, 0x555555555555555};
	for(int i = 0; i < 2; i++) {
		CFNumberRef n = CFNumberCreate(kCFAllocatorDefault, kCFNumberSInt64Type, &v[i]);
		printf("%p\n", (void*)n);
	}
}

Prints

> gcc -framework CoreFoundation main.c
> ./a.out
0x5555555555555537
0x7f8912c06230

It looks like a CFNumberRef isn't always a real pointer. If the integer is at most 56 bits, it is encoded directly in the pointer and the low bits (?) determine the encoding.

This is unfortunate. I'm not sure what we can do about it. It bleeds up to CFTypeRef, the void* of the apple world.

Maybe we teach cgo that it should use uintptr for all these CF*Ref types? We can't reasonably allocate them on the Go side, so that might work. If cgo could reliably detect them...

It isn't just the pointer-to-the-zero-page problem noted earlier. We could manufacture a pointer to just about anywhere the runtime considers invalid (goroutine stacks, padding at the end of spans) using CFNumberCreate and just the right (or wrong, depending on your perspective) integer.

Reopening. I'm not sure we can fix this, but we should probably consider if there's anything sensible to do.

Does that mean it's currently impossible to call e.g. C.CFNumberCreate from go safely, since it returns a C.CNumberRef? Or does immediately casting a C.C*Ref to a uintptr suffice?

Casting to uintptr immediately should suffice.

OpenGL has a similar issue in glFenceSync, which returns a GLsync, which is an opaque struct pointer type (typedef struct __GLsync *GLsync;) that doesn't always represent actual pointers. See go-gl/gl#71 for discussions on that.

@dominikh, you mention in go-gl/gl#71 (comment) that doing e.g. C.SomeTaggedPointerType(unsafe.Pointer(x)) isn't safe in the context of a function call.

Isn't that pretty bad? In this context, I can call functions that return a C.CFTypeRef and immediately cast it to unsafe.Pointer and uintptr, but if I wanted to call a function that took a C.CFTypeRef, e.g. CFRelease to free the memory, then I'd have to cast it back to unsafe.Pointer, which then the GC can pick up and panic on.

Does that mean I need to write C shims to take uintptr_t for every function that currently takes a C.CFTypeRef that I want to call?

That is the conclusion I have reached, yes. I'd love to be proven wrong, though.

@randall77 @ianlancetaylor can either of you guys comment on whether casting a non-pointer value to unsafe.Pointer to pass to a C function taking void * is safe or unsafe? I'm hoping it's safe, since surely there are lots of C APIs that use void * as a generic pointer-sized type for parameters.

@akalin-keybase That is unsafe at the moment.
There are two reasons:

1. Garbage collection can happen at the start of the cgo wrapper for the C function.
2. The go<->c pointer checker runs in this wrapper and would also see (and barf on? I'm not sure) this bad pointer.

The first we might be able to fix with the right sprinkling of nosplit directives in cgo generated code.
The second seems harder, as the test should fail on some pointers, and from C we can manufacture almost any pointer. Unless we turn this check off altogether.

Neither can happen on returns, so there immediately casting to uintptr is ok.

The only workaround I can see at the moment is to do the cast on the C side and pass uintptr across the c/go boundary.

@akalin-keybase Go is not C, and Go has a simple rule: a variable of pointer type must hold a pointer value. Tricks like converting an integer to a pointer type, while valid in C, are not valid in Go.

Change https://golang.org/cl/66332 mentions this issue: cmd/cgo: special case C ptr types to use uintptr

Tricks like converting an integer to a pointer type, while valid in C, are not valid in Go.

Note that even in C, “the result is implementation-defined, might not be correctly aligned, might not point to an entity of the referenced type, and might be a trap representation”, and in general, “[i]f the
resulting pointer is not correctly aligned for the referenced type, the behavior is undefined.”

So this isn't a portable idiom in C, either: it's only valid if you make non-standard assumptions about the C implementation.

Thank you very much for this!

Change https://golang.org/cl/81876 mentions this issue: cmd/cgo: make JNI's jobject type map to uintptr in Go

Change https://golang.org/cl/82917 mentions this issue: doc: add doc about C types that we map to uintptr instead of ptr