slice appends sometimes have some of their content zeroed out in between tx calls #1167
Comments
thehowl
added
🐞 bug
|
Possibly related: #1170 something-something-slice-allocation |
So I think we can state that the bugs we have in gnolang#960, gnolang#1167 and gnolang#1170, are all related to slice storage when its capacity is different than its length. @deelawn found a great way to overcome that bug, but the bug is still there, somewhere in the VM code I think. I spent the last couple of days trying to find it, unfortunately without success. That said, I found a workaround, that could be also applied: when a slice is stored, ignore any capacity different than the slice's length. I think this is a good workaround because its one-line and because we don't really care about storing slice with capacity higher than their length (unless I'm missing something).
thehowl
changed the title
|
cc/ @deelawn |
|
I've done an analysis on this and was able to identify the root cause. I'll start from the call to Inside
|
|
looking at this now. |
Addresses #1167, #960, and #1170 Consider the following situation: - A slice of structs exists with a length of zero and a capacity of one - A new struct literal is appended to the slice - The code panics because the newly allocated struct literal was never marked as "new" ``` go package append import ( "gno.land/p/demo/ufmt" ) type T struct{ i int } var a []T func init() { a = make([]T, 0, 1) } func Append(i int) { a = append(a, T{i: i}) } ``` Invoking the `Append` function will cause a panic. The solution is to traverse each of the array elements after slice append assignment to make sure any new or updated elements are marked as such. This PR also includes a change to ensure that marking an object as dirty and managing references to the object are mutually exclusive. I think this is correct but am not sure. The changes include txtar test cases that incorporate the issue described by @tbruyelle in #1170 --------- Co-authored-by: jaekwon <jae@tendermint.com>
|
Fixed by #1305 |
…lang#1305) Addresses gnolang#1167, gnolang#960, and gnolang#1170 Consider the following situation: - A slice of structs exists with a length of zero and a capacity of one - A new struct literal is appended to the slice - The code panics because the newly allocated struct literal was never marked as "new" ``` go package append import ( "gno.land/p/demo/ufmt" ) type T struct{ i int } var a []T func init() { a = make([]T, 0, 1) } func Append(i int) { a = append(a, T{i: i}) } ``` Invoking the `Append` function will cause a panic. The solution is to traverse each of the array elements after slice append assignment to make sure any new or updated elements are marked as such. This PR also includes a change to ensure that marking an object as dirty and managing references to the object are mutually exclusive. I think this is correct but am not sure. The changes include txtar test cases that incorporate the issue described by @tbruyelle in gnolang#1170 --------- Co-authored-by: jaekwon <jae@tendermint.com>
Reproducible test: 0e44fca
Without the workaround, test output:
This was originally found in GnoChess: one of the head-banging-against-the-wall issues we had with GnoChess was that the realm was returning
a1a1as the first move being made (a1a1is a representation of a Move struct, where if all of its three values are 0 then the String() method will returna1a1). This could not be replicated using Gno tests, where the behaviour didn't happen, but only with the live chain.Introducing this change fixed the problem. The underlying idea is that of re-creating and reallocating the moves slice, instead of copying it from the previous instance of
Position.The text was updated successfully, but these errors were encountered: