-
Notifications
You must be signed in to change notification settings - Fork 386
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Instruction to reproduce weird bug on append #1170
Closed
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
github-actions
bot
added
the
🧾 package/realm
Tag used for new Realms or Packages.
label
Sep 25, 2023
Codecov ReportPatch and project coverage have no change.
Additional details and impacted files@@ Coverage Diff @@
## master #1170 +/- ##
=======================================
Coverage 47.00% 47.00%
=======================================
Files 365 365
Lines 61156 61156
=======================================
+ Hits 28744 28746 +2
+ Misses 30058 30056 -2
Partials 2354 2354
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
This was referenced Oct 4, 2023
Closing in favor of #1305 |
tbruyelle
added a commit
to tbruyelle/gno
that referenced
this pull request
Nov 1, 2023
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).
jaekwon
added a commit
that referenced
this pull request
Jan 4, 2024
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 <[email protected]>
gfanton
pushed a commit
to moul/gno
that referenced
this pull request
Jan 18, 2024
…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 <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
start a node, then execute
append_bug.sh <YOURKEY>
or copy paste the commands one by one.The realm that has been added to reproduce exposes 2 functions,
Append
andPop
, and the script does the following: