Skip to content

interp: keep memcpy results out of the global state when an initializer is reverted - #5904

Merged
davecheney merged 1 commit into
tinygo-org:devfrom
davecheney:dfc/interp-getwritable-rollback
Oct 19, 2026
Merged

davecheney merged 1 commit into
tinygo-org:devfrom
davecheney:dfc/interp-getwritable-rollback

Conversation

@davecheney

Copy link
Copy Markdown
Contributor

When interp reverts a package initializer and runs it at run time, a memcpy or memmove that interp already evaluated must not change the initial value of the destination. getWritable put its clone in the runner's global object table instead of in the current memory view, so the copy stayed in the initial value after the revert, and the initializer then did the copy again at run time. For example, an initializer that does copy(data[1:], data[:3]) on "ABCD" and then calls println in a function with a defer gives "AAAB" instead of "AABC". The same program gives the correct result when it runs from main, and the 0.43.0 release has the same problem. getWritable has done this since the interp rewrite in 30df912.

The problem was found during review of #5903, which lets interp evaluate functions with defer. This change does not depend on #5903.

@deadprogram

Copy link
Copy Markdown
Member

Please rebase and resolve merge conflicts @davecheney thank you.

…er is reverted

When interp reverts a package initializer and runs it at run time, a memcpy or memmove that interp already evaluated must not change the initial value of the destination. getWritable put its clone in the runner's global object table instead of in the current memory view, so the copy stayed in the initial value after the revert, and the initializer then did the copy again at run time. For example, an initializer that does copy(data[1:], data[:3]) on "ABCD" and then calls println in a function with a defer gives "AAAB" instead of "AABC". The same program gives the correct result when it runs from main, and the 0.43.0 release has the same problem. getWritable has done this since the interp rewrite in 30df912.

The problem was found during review of tinygo-org#5903, which lets interp evaluate functions with defer. This change does not depend on tinygo-org#5903.
@davecheney
davecheney force-pushed the dfc/interp-getwritable-rollback branch from bd73585 to 08cdc5e Compare October 17, 2026 22:41
@davecheney

Copy link
Copy Markdown
Contributor Author

@deadprogram rebased, PTAL

@davecheney davecheney added this to the 0.44 milestone Oct 18, 2026

@deadprogram deadprogram left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @davecheney for tracking this one down. I ran the tests on my local machine. Working as expected, thank you very much!

@davecheney
davecheney merged commit 7b49970 into tinygo-org:dev Oct 19, 2026
34 checks passed
@davecheney
davecheney deleted the dfc/interp-getwritable-rollback branch October 19, 2026 09:35
mklocdev pushed a commit to mklocdev/tinygo that referenced this pull request Oct 21, 2026
…er is reverted (tinygo-org#5904)

When interp reverts a package initializer and runs it at run time, a memcpy or memmove that interp already evaluated must not change the initial value of the destination. getWritable put its clone in the runner's global object table instead of in the current memory view, so the copy stayed in the initial value after the revert, and the initializer then did the copy again at run time. For example, an initializer that does copy(data[1:], data[:3]) on "ABCD" and then calls println in a function with a defer gives "AAAB" instead of "AABC". The same program gives the correct result when it runs from main, and the 0.43.0 release has the same problem. getWritable has done this since the interp rewrite in 30df912.

The problem was found during review of tinygo-org#5903, which lets interp evaluate functions with defer. This change does not depend on tinygo-org#5903.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants