transform (gc): GEP not pinned

[lei-april]

The following code produces different results between the official Go compiler and Tinygo.

package main

const DataLen = 32

type Foo struct {
	data [DataLen]byte
}

func MakeFoo(from []byte) *Foo {
	foo := new(Foo)
	copy(foo.data[:], from)
	return foo
}

func main() {
	foo := MakeFoo([]byte("aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"))
	println(string(foo.data[:]))

	bar := MakeFoo([]byte("bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb"))
	println(string(bar.data[:]))
}

With official Go:

$ go run t.go
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb

With TinyGo:

$ tinygo build -o t t.go && ./t
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

If I change the field type of Foo from array to slice, then TinyGo produces the same result as official Go.

@@ -3,11 +3,12 @@ package main
 const DataLen = 32

 type Foo struct {
-   data [DataLen]byte
+   data []byte
 }

 func MakeFoo(from []byte) *Foo {
    foo := new(Foo)
+   foo.data = make([]byte, DataLen)
    copy(foo.data[:], from)
    return foo
 }

I'm not sure if there's something wrong with the code I posted, or it's a bug in TinyGo. Any idea?

[niaow]

This appears to somehow be an issue with the extalloc GC that we use on *nix systems. It seems to work with our other GC, although I am not entirely sure what is going on yet.

[niaow]

Okay, so it looks like the return value of MakeFoo (in main) is being compiled incorrectly, and is not being added as a pointer pinned by the GC. Then when you convert it to a string string([]byte(foo.data[:])) it does another allocation. On the second time, you appear to be hitting the first GC high water mark, triggering the GC to run and freeing foo and bar.

[niaow]

Okay I think I finally see what is going on here. In order to invoke the trackPointer intrinsic, we are creatring a bitcast to unsafe.Pointer. LLVM is rewriting this to a 0-index get-element-pointer operation. We ignore the trackPointer then, since GEPs generally do not correspond to new memory.

[lei-april]

This appears to somehow be an issue with the extalloc GC that we use on *nix systems. It seems to work with our other GC, although I am not entirely sure what is going on yet.

Switching to "conservative" GC seems to solve this problem.

So, is this bug specific to "extalloc" GC, or it just happens to work with "conservative" GC in my case?

[niaow]

I initially thought this was a bug in the extalloc GC, but it is not. Happens to work; I am currently trying to fix it. The issue does not apply to baremetal targets, which use an entirely different mechanism for tracking pointers on the stack.

[aykevl]

This bug should now be fixed.

[deadprogram]

This was released with v0.14.0 so now closing. Please reopen if needed. Thanks!