Any sort of repro would be helpful.

Out of curiosity, what happens when you add runtime.KeepAlive(texture) after the call to fmt.Println in your first code snippet?

Also, fyi: fmt.Println doesn't accept format specifiers.

Also, fyi: fmt.Println doesn't accept format specifiers.

oh, sorry, its a typo ofc. I meant Printf, but it doesn't matter in fact. The problem is with the value returned by texture.ID() which returns unsafe.Pointer representing C void* pointer

Out of curiosity, what happens when you add runtime.KeepAlive(texture) after the call to fmt.Println in your first code snippet?

nothing changes

Any sort of repro would be helpful.

I know, I tried to write some code but with no result.

Also, I tried to use go-delve to debug this but with no result - when using debugger it worked fine...

in fact, reproducable code is here: https://github.com/gucio321/cimgui-go/tree/callbacks
I tried to write something myself but it didn't work as expected
Generally speaking the idea looks as follows:

• C creates a void* pointer
• go takes it as an unsafe.pointer
  here are some code pieces:

type Texture struct {
        id     TextureID
        Width  int
        Height int
}

func NewTextureFromRgba(rgba *image.RGBA) *Texture {
        texID := textureManager.CreateTextureRgba(rgba, rgba.Bounds().Dx(), rgba.Bounds().Dy())

        if texID.Data == nil {
                return nil
        }

        texture := Texture{
                id:     texID,
                Width:  rgba.Bounds().Dx(),
                Height: rgba.Bounds().Dy(),
        }

        // Set finalizer
        runtime.SetFinalizer(&texture, (*Texture).release)

        return &texture
}

func (t *Texture) release() {
        textureManager.DeleteTexture(t.id)
}

func (t *Texture) ID() TextureID {
        return t.id
}

type TextureID struct {
        Data unsafe.Pointer
}

func (self *TextureID) handle() (*C.ImTextureID, func()) {
        result, fn := self.c()
        return &result, fn
}

func (selfStruct *TextureID) c() (result C.ImTextureID, fin func()) {
        self := selfStruct.Data
        selfArg, selfFin := WrapVoidPtr(self)
        return (C.ImTextureID)(selfArg), func() { selfFin() }
}

func newTextureIDFromC(cvalue *C.ImTextureID) *TextureID {
        v := (unsafe.Pointer)(*cvalue)
        return &TextureID{Data: unsafe.Pointer(v)}
}

0x1 is almost certainly not a valid pointer. Per the C11 spec, “the result [of converting an integer to a pointer type] is implementation-defined, might not be correctly aligned, might not point to an entity of the referenced type, and might be a trap representation.” It just so happens that 0x1 acts as a trap representation for the Go runtime.

If you have a C type that may represent a mix of pointers and integers, you should generally pass it to Go as a uintptr rather than a void*.

@gucio321 Is there anything to follow-up with here? Closing optimistically, but please comment if you disagree. Thanks!

@mknyszek After reading @bcmills's statement I still think that fmt shouldn't care what exactly is the pointer as it (in theory) could be whatever the programmer wants - even 0x1 (because why not? - its the idea of the unsafe package). So in my opinion using uintptr is a good workaround here but I think that this panic is a bug in go that should be fixed, shouldn't it?

CC @mknyszek

Also, using uintptr is in fact not a good solution at all since it violates race detector rules.