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.

Sign up for GitHub

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

Jump to bottom

Memory incoherence when using --path #2888

Open
amoffat opened this issue Nov 23, 2024 · 7 comments
Open

Memory incoherence when using --path #2888

amoffat opened this issue Nov 23, 2024 · 7 comments
Labels
bug

Comments

@amoffat
Copy link

amoffat commented Nov 23, 2024 •
edited
Loading

Bug description

If asc is used to compile multiple files, and one of those files is resolved via --path, then memory set in that file is not persisted. If --path is not used, the memory persists.

Steps to reproduce

index.html

<!DOCTYPE html>
<html>
  <body>
    <script type="module">
      import { printThing, adjustThing } from "./main.js";
      printThing();
      adjustThing();
      printThing();
    </script>
  </body>
</html>

main.ts

import { thing } from "utils/module";

export function printThing(): void {
  console.log(`Thing value is ${thing.value}`);
}

lib/utils/types.ts

export class Thing {
  value: i32 = 0;
}

lib/utils/module.ts

import { Thing } from "./types";

export const thing = new Thing();
thing.value = 123;

export function adjustThing(): void {
  thing.value = 456;
}

Compile with
asc main.ts lib/utils/module.ts -o main.wasm --bindings esm --path lib

Run npx http-server

Open http://localhost:8080 and open the debug console.

The output should be:

Thing value is 123
Thing value is 123

This shows that the memory is not being set correctly.

Now to prove it is a --path issue, we will use relative imports, instead of path imports. Change main.ts to:

import { thing } from "./lib/utils/module";

export function printThing(): void {
  console.log(`Thing value is ${thing.value}`);
}

Compile with
asc main.ts lib/utils/module.ts -o main.wasm --bindings esm

Visit in the browser (you may need to hard refresh). The output will be

Thing value is 123
Thing value is 456

This shows that the memory is being set correctly.

AssemblyScript version

0.27.31
@amoffat amoffat added the bug label Nov 23, 2024
@amoffat
Copy link
Author

amoffat commented Nov 23, 2024

Some more context:

I am trying to build a library that exposes some standard functions to the javascript host. However, because the functions exported in the library cannot manipulate any state that the main program has access to, they aren't useful.

@CountBleck
Copy link
Member

My initial suspicion is that the same file is read and parsed twice, with different internal names...

@amoffat
Copy link
Author

amoffat commented Nov 23, 2024 •
edited
Loading

My initial suspicion is that the same file is read and parsed twice, with different internal names...

Could it also be related to multiple entrypoints? In the first example (the broken one), I'm compiling two files with asc, and wouldn't those be considered separate entrypoints? In the second example, the first entrypoint is including the second entrypoint, so there's only one entrypoint. Are entrypoints separated in memory?

@CountBleck
Copy link
Member

Entrypoints are compiled together...I don't think they affect whether this bug occurs.

@CountBleck
Copy link
Member

On second thought, it looks like the cause is the second entry point, because you specify lib/utils/module.ts, which will resolve to a different internal name than that of the utils/module import.

@amoffat
Copy link
Author

amoffat commented Dec 17, 2024

Is there a way to use --path (so I can use non-relative imports) and compile the lib/utils/module.ts without including it as an entrypoint?

@CountBleck
Copy link
Member

Have you tried playing around with --lib?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@amoffat @CountBleck