Skip to content
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

unexpected unreal object when assigning a local variable to a global variable (pointer) #1326

Closed
thehowl opened this issue Nov 1, 2023 · 0 comments · Fixed by #2255 · May be fixed by #1501
Closed

unexpected unreal object when assigning a local variable to a global variable (pointer) #1326

thehowl opened this issue Nov 1, 2023 · 0 comments · Fixed by #2255 · May be fixed by #1501
Assignees
Labels
🐞 bug Something isn't working 📦 🤖 gnovm Issues or PRs gnovm related

Comments

@thehowl
Copy link
Member

thehowl commented Nov 1, 2023

https://gist.github.com/thehowl/e36b0f0d652a2a348a2fcd331a310417

(added as a txtar test gnoland/cmd/gnoland/testdata)

Changing *el = n to el = &n fixed the issue. Found while trying to reproduce #1167

@thehowl thehowl added 🐞 bug Something isn't working 📦 🤖 gnovm Issues or PRs gnovm related labels Nov 1, 2023
@thehowl thehowl added this to the 🚀 main.gno.land (required) milestone Nov 1, 2023
@deelawn deelawn self-assigned this Nov 20, 2023
@deelawn deelawn linked a pull request Nov 29, 2023 that will close this issue
7 tasks
gfanton pushed a commit to gfanton/gno that referenced this issue Jul 23, 2024
This is a complete solution, alternative to gnolang#1919, and (I think) closes
gnolang#1326.
It creates a new container for "baseless" (floating) values constructed
via `new(xxx)` or `&struct{}`, which currently do not have a base
containing object for that value, and are currently represented as
PointerValues with .Base set to nil.

The containing object is like a Block but minimal -- it only contains
one Value, and has no Source or Parent. The modifications to realm.go
allow for proper ref-counting so that even when there are multiple
references to the baseless value, and even when the value is primitive,
gc and ref-counting works (since the containing HeapItemValue is
ref-counted). PointerValue.Base should now never be nil.

See also
gnolang#1919 (comment) for why
the previous solution doesn't work.

A better optimization than the one mentioned in the comment above, is to
always store the HeapItemValue along with the Value, since the Value's
refcount should always be 1. This is left for the future, after first
checking that this invariant is true.

---------

Co-authored-by: deelawn <dboltz03@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment