Add CI for WASI threads by eloparco · Pull Request #1819 · bytecodealliance/wasm-micro-runtime

eloparco · 2022-12-16T13:20:04Z

No description provided.

eloparco · 2022-12-16T14:16:15Z

Not sure why the compilation on macos-latest job is failing, it works properly when I try it directly from my forked repo https://github.com/eloparco/wasm-micro-runtime/actions/runs/3713650979/jobs/6296822730.

loganek · 2022-12-18T23:43:50Z

          ]
        os: [macos-latest]
-        wasi_sdk_release: ["https://github.com/WebAssembly/wasi-sdk/releases/download/wasi-sdk-12/wasi-sdk-12.0-macos.tar.gz"]
+        wasi_sdk_release: ["https://github.com/WebAssembly/wasi-sdk/releases/download/wasi-sdk-17/wasi-sdk-17.0-macos.tar.gz"]


Wonder if we want to continue building for 12 to ensure backward compatibility? Or do we want to drop 12 and ask users to migrate to >= 17 now?

I tried wasi-sdk version 12 and wasi-libc branch wasi-sdk-17 here but the build failed.
It was not immediate to find a compatible combination of wasi-sdk and wasi-libc for the different targets (on ubuntu I'm using wasi-sdk version 16 in this PR since version 17 was not working).

I am a little confused here. It seems the CI depends on the combination of wasi-sdk-X + a specific release of wasi-libc now. Is there a plan that a future wasi-sdk release include everything and make the local combination not necessary?

eloparco · 2022-12-19T15:51:38Z

It looks like all jobs are succeeding now, using wasi-sdk version 16 and wasi-libc with branch wasi-sdk-17 on all targets.

eloparco · 2022-12-19T16:02:07Z

Actually, looking at the output (and at some tests I was doing locally) I see a regression:

New thread ID: 1, starting parameter: 52
Updated value: 8
Thread completed, new value: 0, thread id: 0

The new value and thread id are wrong.

I'm adding

LINKER:--export=malloc
LINKER:--export=free

in samples/wasi-threads/wasm-apps/CMakeLists.txt, not sure if I need to change anything else.

wenyongh

LGTM

@eloparco Shall I merge the PR?

yamt · 2022-12-20T08:40:05Z

    LINKER:--shared-memory,--max-memory=1966080
    LINKER:--export=wasi_thread_start
+    LINKER:--export=malloc
+    LINKER:--export=free


Because I was getting this error without the additional exports:

[09:52:39:510 - 101150580]: Memory instantiate success. [09:52:39:614 - 101150580]: Error: app heap is corrupted, if the wasm file is compiled by wasi-sdk-12.0 or higher version, please add -Wl,--export=malloc -Wl,--export=free to export malloc and free functions. If it is compiled by asc, please add --exportRuntime to export the runtime helpers. [09:52:39:618 - 101150580]: thread manager error: failed to allocate aux stack space for new thread [09:52:39:620 - 101150580]: Failed to spawn a new thread [09:52:39:623 - 101150580]: /Users/eloparco/dev/forks/wasm-micro-runtime/core/iwasm/interpreter/wasm_interp_fast.c, line 3959, meet an exception Exception: app heap corrupted Exception: app heap corrupted

the aux stack allocation should be disabled for wasi-threads because it's libc's responsibility to allocate stack for new threads.

no_pthread.c seems broken. its wasi_thread_start should either update the stack pointer global or avoid using C stack.

the aux stack allocation should be disabled for wasi-threads because it's libc's responsibility to allocate stack for new threads.

https://github.com/bytecodealliance/wasm-micro-runtime/blob/dev/wasi_threads/core/config.h#L172

no_pthread.c seems broken. its wasi_thread_start should either update the stack pointer global or avoid using C stack.

How do I use the app heap? if I don't export the malloc and free functions I get Error: app heap is corrupted

According to this,

app heap and libc heap: the heap to allocate memory for wasm app, note that app heap is created only when the malloc/free functions (or __new/__release functions for AssemblyScript) are not exported and runtime can not detect the libc heap.

I've read that one already, but if I don't export malloc and free I'm getting the corruption error

the aux stack allocation should be disabled for wasi-threads because it's libc's responsibility to allocate stack for new threads.

https://github.com/bytecodealliance/wasm-micro-runtime/blob/dev/wasi_threads/core/config.h#L172

#1799 (comment)

no_pthread.c seems broken. its wasi_thread_start should either update the stack pointer global or avoid using C stack.

How do I use the app heap? if I don't export the malloc and free functions I get Error: app heap is corrupted

wamr doesn't need to (and shouldn't) use the heap (app heap or libc heap) at least for this purpose (stack allocation for wasi-threads) because the stack is managed inside the module itself. (usually by libc)

Threads implementation in WAMR is not fully completed yet. One of the things is to always (regardless of compilation flags) use on-heap aux stack allocation. I have change for that already but didn't test it yet; I'll make the change public beginning of next month when I'm back from holidays, until then I'd suggest waiting with merging this PR.

eloparco · 2022-12-20T09:08:06Z

@wenyongh let's wait for @loganek's feedback before merging

lum1n0us · 2022-12-21T03:55:33Z

BTW, is there an issue to track the compilation error in https://github.com/eloparco/wasm-micro-runtime/actions/runs/3730554354/jobs/6327794669?

wenyongh · 2022-12-21T09:33:48Z

@eloparco Wondering why you use wasi-sdk-16.0 for the CI and use wasi-sdk-17.0 for wasi-thread sample? Why not use wasi-sdk-17.0 for all?
We are upgrading the toolkits (llvm, wasi-sdk, emsdk, binaryen and so on), and are considering upgrade wasi-sdk to 17.0 directly.

eloparco · 2022-12-21T22:46:43Z

@eloparco Wondering why you use wasi-sdk-16.0 for the CI and use wasi-sdk-17.0 for wasi-thread sample? Why not use wasi-sdk-17.0 for all?

@wenyongh That's what I tried first, but it was failing on ubuntu/android: https://github.com/eloparco/wasm-micro-runtime/actions/runs/3703249930/jobs/6274621343

BTW, is there an issue to track the compilation error in https://github.com/eloparco/wasm-micro-runtime/actions/runs/3730554354/jobs/6327794669?

@lum1n0us Not yet, should I create one in this repo?

loganek · 2022-12-21T23:37:01Z

@eloparco Wondering why you use wasi-sdk-16.0 for the CI and use wasi-sdk-17.0 for wasi-thread sample? Why not use wasi-sdk-17.0 for all?

@wenyongh That's what I tried first, but it was failing on ubuntu/android: https://github.com/eloparco/wasm-micro-runtime/actions/runs/3703249930/jobs/6274621343

@eloparco are you going to fix the issue? Or should we at least have an issue to upgrade to v17?

eloparco · 2022-12-21T23:43:04Z

@loganek @lum1n0us I'll create an issue to track the upgrade to v17, putting links to the failing jobs

wenyongh · 2022-12-22T01:18:01Z

@eloparco Wondering why you use wasi-sdk-16.0 for the CI and use wasi-sdk-17.0 for wasi-thread sample? Why not use wasi-sdk-17.0 for all?

@wenyongh That's what I tried first, but it was failing on ubuntu/android: https://github.com/eloparco/wasm-micro-runtime/actions/runs/3703249930/jobs/6274621343

Got it, I tested building wasi-libc and other wasm app with wasi-sdk-17 on Ubuntu-20.04, and got the same errors:

/opt/wasi-sdk/bin/clang: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by /opt/wasi-sdk/bin/clang)
/opt/wasi-sdk/bin/clang: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by /opt/wasi-sdk/bin/clang)
/opt/wasi-sdk/bin/clang: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by /opt/wasi-sdk/bin/clang)

It seems that wasi-sdk-17 requires that libc-2.32 or newer version is installed, while by default in Ubuntu-20.04 libc-2.31 is installed. It may work in Ubuntu-22.04. But it seems that we had better just upgrade scripts to support wasi-sdk-16 now.

wenyongh · 2022-12-22T01:06:21Z


+      - name: build wasi-libc (needed for wasi-threads)
+        run: |
+          git clone --branch wasi-sdk-17 https://github.com/WebAssembly/wasi-libc


Branch wasi-sdk-17 isn't found in the wasi-libc repo, seems that main branch is OK.

It's a tag https://github.com/WebAssembly/wasi-libc/tree/wasi-sdk-17.

I'd prefer to pin the version/tag rather than using main. Unless we want to use the current latest commit from main and we checkout that specific one.

I remember that the combination wasi-sdk-16 + main from wasi-libc was failing on Ubuntu.

OK. So shall we merge the PR now? @loganek, are there any comments from you? Thanks.

I think so, to recap:

we're using wasi-sdk-16 because wasi-sdk-17 would require a newer version of libc wrt the one on Ubuntu-20.04 used in the pipeline (the alternative would be to update the Ubuntu image)

--export=malloc and --export=free are used here otherwise the pipeline would fail when executing the wasi-threads samples (the alternative would be to comment the assert in samples/wasi-threads/wasm-apps/no_pthread.c); the behavior will be fixed in a new PR

wenyongh · 2022-12-22T01:09:27Z


+      - name: build wasi-libc (needed for wasi-threads)
+        run: |
+          git clone --branch wasi-sdk-17 https://github.com/WebAssembly/wasi-libc


Same as above

wenyongh · 2022-12-22T01:10:33Z


+      - name: build wasi-libc (needed for wasi-threads)
+        run: |
+          git clone --branch wasi-sdk-17 https://github.com/WebAssembly/wasi-libc


Same as above

Update wasi-sdk from 12.0 to 16.0 in CI Build wasi-libc and build wai-threads sample in CI

loganek reviewed Dec 18, 2022

View reviewed changes

eloparco force-pushed the eloparco/wasi-threads-ci branch 2 times, most recently from 2d39fc4 to abe0053 Compare December 19, 2022 14:24

wenyongh reviewed Dec 20, 2022

View reviewed changes

yamt reviewed Dec 20, 2022

View reviewed changes

wenyongh reviewed Dec 22, 2022

View reviewed changes

eloparco force-pushed the eloparco/wasi-threads-ci branch from abe0053 to 1a74215 Compare December 22, 2022 01:40

feat(wasi-threads): add ci

de0fc1a

eloparco force-pushed the eloparco/wasi-threads-ci branch from 1a74215 to de0fc1a Compare December 22, 2022 02:17

wenyongh merged commit 7d19b22 into bytecodealliance:dev/wasi_threads Dec 22, 2022

eloparco mentioned this pull request Jan 5, 2023

Fix on-heap aux stack allocation #1865

Merged

loganek mentioned this pull request Jan 6, 2023

WASI threads support #1790

Closed

19 tasks

vickiegpt pushed a commit to vickiegpt/wamr-aot-gc-checkpoint-restore that referenced this pull request May 27, 2024

feat(wasi-threads): Add CI for WASI threads (bytecodealliance#1819)

6264d54

Update wasi-sdk from 12.0 to 16.0 in CI Build wasi-libc and build wai-threads sample in CI

Conversation

eloparco commented Dec 16, 2022

Uh oh!

eloparco commented Dec 16, 2022

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

eloparco commented Dec 19, 2022

Uh oh!

eloparco commented Dec 19, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

wenyongh left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

eloparco Dec 20, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

eloparco commented Dec 20, 2022

Uh oh!

lum1n0us commented Dec 21, 2022

Uh oh!

wenyongh commented Dec 21, 2022

Uh oh!

eloparco commented Dec 21, 2022

Uh oh!

loganek commented Dec 21, 2022

Uh oh!

eloparco commented Dec 21, 2022

Uh oh!

wenyongh commented Dec 22, 2022

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

eloparco Dec 22, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

eloparco commented Dec 19, 2022 •

edited

Loading

eloparco Dec 20, 2022 •

edited

Loading

eloparco Dec 22, 2022 •

edited

Loading