nodejs / uvwasi Goto Github PK

uvwasi_fd_close() locks the fd mutex, closes the file, releases the mutex, then calls uvwasi_fd_table_remove() to free the fd table entry and destroy the entry's mutex.

Another thread could acquire the mutex once it is unlocked, and uvwasi_fd_table_remove() would destroy it.

Aside from libuv/libuv#2857

/__w/uvwasi/uvwasi/src/uvwasi.c:1214:5: warning: implicit declaration of function 'seekdir' [-Wimplicit-function-declaration]
    seekdir(dir->dir, cookie);
    ^
/__w/uvwasi/uvwasi/src/uvwasi.c:1214:5: warning: this function declaration is not a prototype [-Wstrict-prototypes]
/__w/uvwasi/uvwasi/src/uvwasi.c:1233:14: warning: implicit declaration of function 'telldir' [-Wimplicit-function-declaration]
      tell = telldir(dir->dir);
             ^
/__w/uvwasi/uvwasi/src/uvwasi.c:1233:14: warning: this function declaration is not a prototype [-Wstrict-prototypes]

Now Github action on windows it's false positive (need to make buildscript compatible).

On my win10, visual studio 2019

Build fails with

winnt.h(154): fatal error c1189: #error: "no target architecture"

Time

UTC Wed 12-Apr-2023 18:00 (06:00 PM):

Or in your local time:

• https://www.timeanddate.com/worldclock/fixedtime.html?msg=Node.js+Foundation+uvwasi%20team+Meeting+2023-04-12&iso=20230412T1800
• or https://www.wolframalpha.com/input/?i=06PM+UTC%2C+Apr+12%2C+2023+in+local+time

Links

• Minutes Google Doc: https://docs.google.com/document/d/15Usw0sng0NuEcrPmVSqdAHLy3W_Kt9R39Z0CjmckMDg/edit

Agenda

Extracted from uvwasi-agenda labelled issues and pull requests from the nodejs org prior to the meeting.

nodejs/node

• WASI preview 1: fd_readdir ignores cookie argument #47193

nodejs/uvwasi

• uvwasi team working tasks #187

Invited

• uvwasi team: @nodejs/wasi

Observers/Guests

Notes

The agenda comes from issues labelled with uvwasi-agenda across all of the repositories in the nodejs org. Please label any additional issues that should be on the agenda before the meeting starts.

Joining the meeting

• link for participants: https://zoom.us/j/91612484369
• For those who just want to watch:
• youtube admin page: https://www.youtube.com/my_live_events?filter=scheduled

Test coverage is worth at least investigating.

I find the problem. Will send a pr after #30.

👋

I'm trying to use uvwasi in txiki.js through wasm3. I'm already using libuv, in my project and thus embedding it again with uvwasi is being problematic.

What would be the way to accomplish this? Perhaps have a CMake option to skip pulling libuv, so the one already provided is used?

Thanks!

Utilize uv_mutex_ts throughout the codebase to make the various calls thread safe.

Steps o reproduce

This is related to bytecodealliance/wasmtime#2493

Example: ls-test.zip

I'm using https://github.com/wasm3/node-wasm-run to reproduce this:

wasm-run ls.wasm testfolder | wc -l

Expected result

303

Actual result

147

Log

# nvm install v18.8.0
# npm install wasm-run -g
# node --version                     
v18.8.0
# wasm-run ls.wasm testfolder | wc -l
147
# wasmtime --dir=. ls.wasm -- testfolder | wc -l
303

This was reported here: wasm3/wasm3#357

Reading package lists...
W: GPG error: https://dl.yarnpkg.com/debian stable InRelease: The following signatures were invalid: EXPKEYSIG 23E7166788B63E1E Yarn Packaging <[email protected]>
E: The repository 'https://dl.yarnpkg.com/debian stable InRelease' is not signed.
/__w/_temp/eccfe662-62d7-44c6-9642-0e4aa09220d4.sh: 3: cmake: not found
Error: Process completed with exit code 127.

Seen in https://github.com/nodejs/uvwasi/actions/runs/4058367972/jobs/7310459457. First appeared in #185, but does not appear related to the changes in that PR.

Reproducible with any call to readdir or scandir from wasi-libc.

I believe the issue is this line: https://github.com/cjihrig/uvwasi/blob/d3fe61d/src/uvwasi.c#L1392

      /* Write the entry name to the buffer. */
      available = buf_len - *bufused;
      size_to_cp = name_len > available ? available : name_len;
      memcpy((char*)buf + *bufused, &dirents[i].name, size_to_cp); // bad memcpy
      *bufused += size_to_cp;

It appears uvwasi is calling memcpy on a pointer to the name string, not the string itself.

Refs: nodejs/node#31432 (comment)

uvwasi_fd_table_renumber() locks the file descriptor table, acquires the source and destination mutexes, performs the renumber operation, releases the mutexes, and unlocks the file descriptor table.

An operation that takes two file descriptors (such as uvwasi_path_rename()) could have acquired one of its fd mutex locks, but not the other. If uvwasi_fd_table_renumber() is called during this window of time, deadlock can occur (uvwasi_fd_table_renumber() waits for the mutex that uvwasi_path_rename() has, and uvwasi_path_rename() waits for the file descriptor table lock that uvwasi_fd_table_renumber() has).

The file descriptor table API could add lock and unlock APIs so that calls like uvwasi_path_rename() can acquire everything at once.

Right now, all of the "tests" are in app.c, which was originally supposed to be an example application using uvwasi. It would be great to split this up into proper tests.

Time

UTC Wed 29-Mar-2023 18:00 (06:00 PM):

Or in your local time:

• https://www.timeanddate.com/worldclock/fixedtime.html?msg=Node.js+Foundation+uvwasi%20team+Meeting+2023-03-29&iso=20230329T1800
• or https://www.wolframalpha.com/input/?i=06PM+UTC%2C+Mar+29%2C+2023+in+local+time

Links

• Minutes Google Doc: https://docs.google.com/document/d/1_TtY5ueaim1QXWCmXejcA_hXH65YURQGduknICtcnK0/edit

Agenda

Extracted from uvwasi-agenda labelled issues and pull requests from the nodejs org prior to the meeting.

nodejs/node

• WASI preview 1: fd_readdir ignores cookie argument #47193

nodejs/uvwasi

• uvwasi team working tasks #187

Invited

• uvwasi team: @nodejs/wasi

Observers/Guests

Notes

The agenda comes from issues labelled with uvwasi-agenda across all of the repositories in the nodejs org. Please label any additional issues that should be on the agenda before the meeting starts.

Joining the meeting

• link for participants: https://zoom.us/j/91612484369
• For those who just want to watch:
• youtube admin page: https://www.youtube.com/my_live_events?filter=scheduled

I tried to build this project with FetchContent in cmake

cmake_minimum_required(VERSION 3.11)

project (uvwasi)

include(FetchContent)

if (APPLE)
   set(CMAKE_MACOSX_RPATH ON)
endif (APPLE)

## https://libuv.org
FetchContent_Declare(
        libuv
        GIT_REPOSITORY https://github.com/libuv/libuv.git
        GIT_TAG v1.32.0)

FetchContent_GetProperties(libuv)
if(NOT libuv_POPULATED)
    FetchContent_Populate(libuv)
    include_directories(
            "${libuv_SOURCE_DIR}/include"
    )
    add_subdirectory(
            ${libuv_SOURCE_DIR}
            ${libuv_BINARY_DIR}
            EXCLUDE_FROM_ALL)
endif()

set(SOURCES
    app.c
    src/fd_table.c
    src/uv_mapping.c
    src/uvwasi.c
)

add_executable(uvwasi ${SOURCES})

target_include_directories(${PROJECT_NAME}
    PRIVATE
    ${PROJECT_SOURCE_DIR}/include
)

#target_link_libraries(${PROJECT_NAME}
#    PRIVATE
#    libuv
#)

failed with

Scanning dependencies of target uvwasi
[ 50%] Building C object CMakeFiles/uvwasi.dir/app.c.o
[ 50%] Building C object CMakeFiles/uvwasi.dir/src/uvwasi.c.o
[ 50%] Building C object CMakeFiles/uvwasi.dir/src/uv_mapping.c.o
[ 50%] Building C object CMakeFiles/uvwasi.dir/src/fd_table.c.o
[100%] Linking C executable uvwasi
Undefined symbols for architecture x86_64:
  "_uv_buf_init", referenced from:

cc @danbev @saghul

currently, I tried to run tests on Windows machine, and I found two tests cannot pass.
do you know the root cause or do you have plan to fix it?
Environment: windows 10.0.19044. x64 Enterprise
Log:

10/19 Test #10: test-filestat-set-times .............***Failed    1.36 sec
uvwasi_path_open(uvwasi=000000559CFCF4F0, dirfd=3, dirflags=1, path='./test-filestat-set-times.txt', path_len=30, o_flags=1, fs_rights_base=11534400, fs_rights_inheriting=0, fs_flags=0, fd=000000559CFCF4C4)
uvwasi_path_symlink(uvwasi=000000559CFCF4F0, old_path='./test-filestat-set-times.txt', old_path_len=30, fd=3, new_path='./symlink.txt', new_path_len=14)
Assertion failed: err == 0, file C:\workspace\wasm-generic-runtime\thirdparty\uvwasi\test\test-filestat-set-times.c, line 71

As brought up by @guybedford in nodejs/wasi#24 (comment). uvwasi_init() should take an option for mapping file descriptors (like it currently supports mapping preopen directories). This will more effectively sandbox WASI applications from each other and their host environment.

Can we take uvwasi and hooks it up the wasm runtime with the C API?

Then we could have a common WASI runtime that would work with any wasm engine that exposes the C-API.

For example we could take uivwasi and wee8 (https://docs.google.com/document/d/1oFPHyNb_eXg6NzrE6xJDNPdJrHMZvx0LqsD6wpbd9vY/edit#heading=h.4tfb7x3beh2l) and create something like node but without any JS.

Ideally the uvwasi executable would dynamically link to libwasm.so (providing the C API) so that any wasm engine would be dropped in without even re-compiling.

This and the sockets calls (which might be going away from WASI anyway) are the only completely unimplemented calls.

I'm still trying to figure out the best way forward here. From what I can tell, this is a synchronous call, so I'm not sure that uv_poll_t can be used.

Also, as @saghul pointed out in nodejs/wasi#21 (comment), polling non-sockets on Windows could be an issue.

Log the system call name and other useful debugging information.

As discussed in the recent meeting with @cjihrig, @phated, @ospencer, @guybedford and myself

1. Refactor build so that uvwasi can be used as shared library

   • Oscar and Blain will work on PRs for this, Colin indicated its something that uvwasi should accept.

2. Stabilization

• Land the 2 PRs Michael has submitted
  • nodejs/node#46469
  • nodejs/node#46434
• Wait a bit until we see we have momentum on maintenance
• Target to have be stable in Node.js 20 which goes out in April
• Will remove need for command line option.

3. Implementing the 4 stubbed out socket methods

• Oscar to talk to Colin to get some help on how to manage streams in order to be able to get started. Will let Michael know once he's got that as he might have some cycles to help with implementation

4. Snapshot 2

• Longer terms as spec is not defined yet.
• Guy is going to work on sharing his experimentation/prototyping that he has been doing on this front. Even though this is in JavaScript, agreement is that final implementation for Node.js should be in uvwasi.

5. Finding additional people to contribute (Done)

• Oscar to reach out to people he knows at bytecode alliance to see if he can get some others interested.
• We should think about how we make joining our discussion discoverable, something that new people can join and make a call in other ways as well.

Since things are beginning to stabilize (as much as they can, given that WASI itself is still unstable), it's probably time to document the public API.

To avoid too much reinvention of the wheel, the WASI API docs are probably a good place to start, with the following alterations:

• Replace __WASI_* with UVWASI_*.
• All of the API functions also take an additional uvwasi_t* uvwasi as their first argument (this represents the context so that multiple uvwasis can exists side by side).
• All of the API functions return a uvwasi_errno_t.
• There are also the uvwasi_init() and uvwasi_destroy() functions that are needed to setup and teardown uvwasi instances.

Time

UTC Wed 15-Mar-2023 18:00 (06:00 PM):

Or in your local time:

• https://www.timeanddate.com/worldclock/fixedtime.html?msg=Node.js+Foundation+uvwasi%20team+Meeting+2023-03-15&iso=20230315T1800
• or https://www.wolframalpha.com/input/?i=06PM+UTC%2C+Mar+15%2C+2023+in+local+time

Links

• Minutes Google Doc: https://docs.google.com/document/d/1THdaR4wxAj-8j9tLx4gmOGj9M7m2I1ld2CrUBUbSipI/edit

Agenda

Extracted from uvwasi-agenda labelled issues and pull requests from the nodejs org prior to the meeting.

Invited

• uvwasi team: @nodejs/wasi

Observers/Guests

Notes

The agenda comes from issues labelled with uvwasi-agenda across all of the repositories in the nodejs org. Please label any additional issues that should be on the agenda before the meeting starts.

Joining the meeting

• link for participants: https://zoom.us/j/91612484369
• For those who just want to watch:
• youtube admin page: https://www.youtube.com/my_live_events?filter=scheduled

It would be nice to have a new release out, given the various merged fixes, and that the last release came out a year ago.

Is there anyone around to make this happen?

• Add libuv source to this repo ? And maybe change build system to CMake (build on windows)
• I am not familiar with make, Is it possible this can build on macOS

I started to investigate an integration with wabt. So far I have just the tiniest start with an implementation , just hooking up proc_exit:

WebAssembly/wabt#1411

I had a couple of questions:

1. What do you think is the best way for a project like wabt to build against uvwasi. The approach I took was to use add_subdirectory. However that resulted in an error because both uvwasi and wabt both define the custom check target. I hacked that target out locally and it seems to work.

2. Do users of uvwasi actually need the uv.h headers? Currently the public headers for uvwasi include the headers from the uv project. Perhaps that is unavoidable? It does mean that downstream projects need to add more include paths so it could be removed that would be a win.

Time

UTC Wed 15-Mar-2023 18:00 (06:00 PM):

Or in your local time:

• https://www.timeanddate.com/worldclock/fixedtime.html?msg=Node.js+Foundation+uvwasi%20team+Meeting+2023-03-15&iso=20230315T1800
• or https://www.wolframalpha.com/input/?i=06PM+UTC%2C+Mar+15%2C+2023+in+local+time

Links

• Minutes Google Doc: https://docs.google.com/document/d/1lZ64O_yOO19W9EUxhmU9bEF6qiN3C5JAkrB5VpznUvk/edit

Agenda

Extracted from uvwasi-agenda labelled issues and pull requests from the nodejs org prior to the meeting.

nodejs/uvwasi

• uvwasi team working tasks #187

Invited

• uvwasi team: @nodejs/wasi

Observers/Guests

Notes

The agenda comes from issues labelled with uvwasi-agenda across all of the repositories in the nodejs org. Please label any additional issues that should be on the agenda before the meeting starts.

Joining the meeting

• link for participants: https://zoom.us/j/91612484369
• For those who just want to watch:
• youtube admin page: https://www.youtube.com/my_live_events?filter=scheduled

Refs: nodejs/node#33864

I don't think renaming the primary branch to main will have any effects on ongoing work in this repo.

Any concerns with me doing the rename?

There are a number of TODO comments sprinkled throughout the code. A number of them are Windows specific. The most important are probably in uvwasi__is_absolute_path() and uvwasi__resolve_path(). Once those ones are resolved there will still be some Windows limitations, but libuv should smooth out most of them.

Compilation failure if you follow the instructions in README.md on how to build.

[ 52%] Building C object CMakeFiles/uvwasi.dir/src/poll_oneoff.c.o
[ 54%] Building C object CMakeFiles/uvwasi.dir/src/uv_mapping.c.o
[ 55%] Building C object CMakeFiles/uvwasi.dir/src/uvwasi.c.o
[ 55%] Building C object CMakeFiles/uvwasi.dir/src/wasi_rights.c.o
[ 56%] Building C object CMakeFiles/uvwasi.dir/src/wasi_serdes.c.o
[ 58%] Linking C shared library libuvwasi.so
/usr/bin/ld: _deps/libuv-build/libuv_a.a(udp.c.o): warning: relocation against `in6addr_any@@GLIBC_2.2.5' in read-only section `.text'
/usr/bin/ld: _deps/libuv-build/libuv_a.a(core.c.o): relocation R_X86_64_PC32 against symbol `environ@@GLIBC_2.2.5' can not be used when making a shared object; recompile with -fPIC

I can build with the same arguments that the ci uses:

cmake  .
  cmake --build . --target check

Similar to libuv/libuv#2858, but I am not sure.

cc @cjihrig

I'm seeing the following link error when building locally using the following commands:

$ mkdir build                                                                   
$ cd build                                                                      
$ cmake ..                                                                      
$ make                                                                          
[ 59%] Linking C shared library libuvwasi.so                                    
/usr/bin/ld: _deps/libuv-build/libuv_a.a(random.c.o): relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC
...                                                                             
collect2: error: ld returned 1 exit status                                      
make[2]: *** [CMakeFiles/uvwasi.dir/build.make:210: libuvwasi.so] Error 1          
make[1]: *** [CMakeFiles/Makefile2:196: CMakeFiles/uvwasi.dir/all] Error 2         
make: *** [Makefile:146: all] Error 2

This can be avoided around by setting CMAKE_POSITION_INDEPENDENT_CODE to True:

$ cmake -DCMAKE_POSITION_INDEPENDENT_CODE=True ..

This could also be set in CMakeLists.txt:

set(CMAKE_POSITION_INDEPENDENT_CODE ON)                                         

GCC version:

$ gcc --version
gcc (GCC) 11.2.1 20220127 (Red Hat 11.2.1-9)

I'm not sure if this is an issue with my local environment, as the CI servers are obviously working as expected. But I wanted to create this issue just in case anyone else runs into it.

See wasm3/wasm3#126 (comment) for the reasoning.

uvwasi should provide a constant that specifies the version of WASI (currently snapshot_0, but soon snapshot_1).

Changes that need to be addressed in uvwasi

Work is going on in the snapshot2 branch. Progress is indicated in the list below.

• The __wasi_proc_raise() function and the __wasi_signal_t type and constants were removed in WebAssembly/WASI#136. This change impacts ephemeral only.
• The functions __wasi_path_permissions_set() and __wasi_fd_permissions_set() were added in WebAssembly/WASI#170.
• The __wasi_poll_oneoff() function should return EINVAL if nsubscriptions is zero. WebAssembly/WASI#193.
• The uvwasi_filetype_t added UVWASI_FILETYPE_FIFO in WebAssembly/WASI#189.
• The UVWASI_O_CREAT flag should be renamed to UVWASI_O_CREATE, in accordance with WebAssembly/WASI#199.
• Union formats have changed in WebAssembly/WASI#220. See WebAssembly/wasi-libc#165.
• The clocks process_cputime_id and thread_cputime_id were removed in WebAssembly/WASI#197.
• The error acces was renamed to access in WebAssembly/WASI#211.
• The uvwasi_dirent_t fields have been rearranged to move the d_namlen field to the end of the struct. See WebAssembly/WASI#264.

It would be useful if embedders didn't need to worry about serializing and deserializing between WASI data structures and the WASM memory. For example, Node.js currently does this:

uvwasi_fdstat_t stats;
uvwasi_errno_t err = uvwasi_fd_fdstat_get(&wasi->uvw_, fd, &stats);

if (err == UVWASI_ESUCCESS) {
  wasi->writeUInt8(memory, stats.fs_filetype, buf);
  wasi->writeUInt16(memory, stats.fs_flags, buf + 2);
  wasi->writeUInt64(memory, stats.fs_rights_base, buf + 8);
  wasi->writeUInt64(memory, stats.fs_rights_inheriting, buf + 16);
}

The wasi->write*() calls could be replaced with a uvwasi_serdes_write_fdstat_t(memory, stats, buf).

Another option could be to provide wrappers for each function (uvwasi_serdes_fd_fdstat_get(), etc.). This would take care of bounds checking, reading from memory, executing the WASI API calls, writing back to memory, and forwarding the correct return value. This would be the simplest thing for embedders, but would also require a wrapper function for every WASI API call.

Potentially useful reference: https://github.com/WebAssembly/tool-conventions/blob/master/BasicCABI.md

Any thoughts or opinions from others?

path_resolver.h defines PATH_MAX_BYTES, which is used to stack allocate buffers for paths. Update uvwasi__resolve_path() to return a dynamically allocated path (it already exists as host_path, but it is memcpy()'ed to the stack buffer). The call sites will also need to be updated. Once that is done, remove PATH_MAX_BYTES.

Changes that need to be addressed in uvwasi

• The whence_t values changed in WebAssembly/WASI#106. This change landed in ephemeral, not unstable.
• The __wasi_linkcount_t data type changed to uint64_t in WebAssembly/WASI#127. This change landed in ephemeral only.
• The subscription_t's clock.identifier field was removed in WebAssembly/WASI#125. This change landed in ephemeral only.
• The __wasi_proc_raise() function and the __wasi_signal_t type and constants are being removed in WebAssembly/WASI#136. EDIT: This change impacts ephemeral only. This change isn't in snapshot_preview1

Changes that have been addressed in uvwasi

• The clockid_t values changed in WebAssembly/WASI#112. This change langed in ephemeral, as well as wasi_unstable_preview0. (Addressed in #47)

hi， uvwasi requires three file descriptors to startup -- 0, 1, and 2（stdin、stdout、stderr）. Windows application without console has not stdin、stdout、stderr, I can open three files instead of them, but I don’t want to do this, is there any other solution? Thanks

While working on VFS support, I run into this problem.
A temporary directory is created and I'd like to mount it to the root fs:

    uvwasi_preopen_t preopens[3];
    preopens[0].mapped_path = "/";
    preopens[0].real_path = ".";
    preopens[1].mapped_path = ".";
    preopens[1].real_path = ".";
    preopens[2].mapped_path = "/_wasmer";
    preopens[2].real_path = "/tmp/wasm3_temp/1234/_wasmer";

This conflicts with the first (root) entry, and I cannot access _wasmer.
If I reorder preopens, I can access _wasmer, but not the root content.

How should this be handled?

Would it be better to avoid the native size_t type and use a fixed size wasi_size_t?

For example in the following API signature:

uvwasi_errno_t uvwasi_fd_write(uvwasi_t* uvwasi,                                                                              
                               uvwasi_fd_t fd,                                      
                               const uvwasi_ciovec_t* iovs,                      
                               size_t iovs_len,                                  
                               size_t* nwritten);   

In this case it would make sense to pass the actual address of the nwritten out param in the wasm memory. However since wasi's size_t is fixed at 4 bytes, we wouldn't want to write a 64-bit value into that location. It seems that on LP64 systems we uvwasi_fd_write would currently write 8 bytes. Maybe I'm misunderstanding?

Not sure should we dealing with the following

This was raised in #121 (comment). I'm opening a separate issue so that it doesn't get forgotten about.

It would be nice to automatically generated wasi_types.h and the serdes API from the witx definitions.

See https://clang.llvm.org/docs/AddressSanitizer.html

Current problem

1: Test command: /mnt/d/Developer/code/uvwasi/cmake-build-debug/out/test-args-get
1: Test timeout computed to be: 10000000
1: 
1: =================================================================
1: ==11768==ERROR: LeakSanitizer: detected memory leaks
1: 
1: Direct leak of 24 byte(s) in 1 object(s) allocated from:
1:     #0 0x7fa25449dce6 in calloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10dce6)
1:     #1 0x7fa254e14103 in main ../test/test-args-get.c:33
1:     #2 0x7fa2541971e2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x271e2)
1: 
1: Direct leak of 24 byte(s) in 1 object(s) allocated from:
1:     #0 0x7fa25449dce6 in calloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10dce6)
1:     #1 0x7fa254e13dea in main ../test/test-args-get.c:17
1:     #2 0x7fa2541971e2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x271e2)
1: 
1: Indirect leak of 19 byte(s) in 1 object(s) allocated from:
1:     #0 0x7fa25449dae8 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10dae8)
1:     #1 0x7fa254e1416b in main ../test/test-args-get.c:35
1:     #2 0x7fa2541971e2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x271e2)
1: 
1: SUMMARY: AddressSanitizer: 67 byte(s) leaked in 3 allocation(s).
 1/11 Test  #1: test-args-get .......................***Failed    0.16 sec
test 2
      Start  2: test-basic-file-io

2: Test command: /mnt/d/Developer/code/uvwasi/cmake-build-debug/out/test-basic-file-io
2: Test timeout computed to be: 10000000
2: 
2: =================================================================
2: ==11770==ERROR: LeakSanitizer: detected memory leaks
2: 
2: Direct leak of 16 byte(s) in 1 object(s) allocated from:
2:     #0 0x7f3869badce6 in calloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10dce6)
2:     #1 0x7f386a530f64 in main ../test/test-basic-file-io.c:37
2:     #2 0x7f38698a71e2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x271e2)
2: 
2: SUMMARY: AddressSanitizer: 16 byte(s) leaked in 1 allocation(s).
 2/11 Test  #2: test-basic-file-io ..................***Failed    0.17 sec
test 3
      Start  3: test-ebadf-input-validation

3: Test command: /mnt/d/Developer/code/uvwasi/cmake-build-debug/out/test-ebadf-input-validation
3: Test timeout computed to be: 10000000
 3/11 Test  #3: test-ebadf-input-validation .........   Passed    0.10 sec
test 4
      Start  4: test-einval-input-validation

4: Test command: /mnt/d/Developer/code/uvwasi/cmake-build-debug/out/test-einval-input-validation
4: Test timeout computed to be: 10000000
 4/11 Test  #4: test-einval-input-validation ........   Passed    0.17 sec
test 5
      Start  5: test-enotsup-apis

5: Test command: /mnt/d/Developer/code/uvwasi/cmake-build-debug/out/test-enotsup-apis
5: Test timeout computed to be: 10000000
 5/11 Test  #5: test-enotsup-apis ...................   Passed    0.21 sec
test 6
      Start  6: test-environ-get

6: Test command: /mnt/d/Developer/code/uvwasi/cmake-build-debug/out/test-environ-get
6: Test timeout computed to be: 10000000
 6/11 Test  #6: test-environ-get ....................   Passed    0.11 sec
test 7
      Start  7: test-fd-prestat-dir-name

7: Test command: /mnt/d/Developer/code/uvwasi/cmake-build-debug/out/test-fd-prestat-dir-name
7: Test timeout computed to be: 10000000
7: 
7: =================================================================
7: ==11780==ERROR: LeakSanitizer: detected memory leaks
7: 
7: Direct leak of 16 byte(s) in 1 object(s) allocated from:
7:     #0 0x7f39177edce6 in calloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10dce6)
7:     #1 0x7f391816ef0e in main ../test/test-fd-prestat-dir-name.c:27
7:     #2 0x7f39174e71e2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x271e2)
7: 
7: SUMMARY: AddressSanitizer: 16 byte(s) leaked in 1 allocation(s).
 7/11 Test  #7: test-fd-prestat-dir-name ............***Failed    0.11 sec

I would like to point out that identifiers like “__UVWASI_H__” and “uvwasi__translate_uv_error” do eventually not fit to the expected naming convention of the C++ language standard.
Would you like to adjust your selection for unique names?

At least NetBSD 8.2 is subject to a build failure for nodejs 14.6.0: nodejs/node#34510. @addaleax provides a patch that fixes the issue:

diff --git a/deps/uvwasi/include/wasi_serdes.h b/deps/uvwasi/include/wasi_serdes.h
index f927b82bac9c..746fb72b123e 100644
--- a/deps/uvwasi/include/wasi_serdes.h
+++ b/deps/uvwasi/include/wasi_serdes.h
@@ -9,17 +9,16 @@
   void uvwasi_serdes_write_##name(void* ptr, size_t offset, type value);      \
   type uvwasi_serdes_read_##name(const void* ptr, size_t offset);             \
 
-#define BASIC_TYPE(type) BASIC_TYPE_(type, type)
 #define BASIC_TYPE_UVWASI(type) BASIC_TYPE_(type, uvwasi_##type)
 
 #define UVWASI_SERDES_SIZE_uint8_t sizeof(uint8_t)
-BASIC_TYPE(uint8_t)
+BASIC_TYPE_(uint8_t, uint8_t)
 #define UVWASI_SERDES_SIZE_uint16_t sizeof(uint16_t)
-BASIC_TYPE(uint16_t)
+BASIC_TYPE_(uint16_t, uint16_t)
 #define UVWASI_SERDES_SIZE_uint32_t sizeof(uint32_t)
-BASIC_TYPE(uint32_t)
+BASIC_TYPE_(uint32_t, uint32_t)
 #define UVWASI_SERDES_SIZE_uint64_t sizeof(uint64_t)
-BASIC_TYPE(uint64_t)
+BASIC_TYPE_(uint64_t, uint64_t)
 
 #define UVWASI_SERDES_SIZE_advice_t sizeof(uvwasi_advice_t)
 BASIC_TYPE_UVWASI(advice_t)

Whenever O_LARGEFILE flag is being used when opening a file stream for readonly, the file gets truncated: data of the file is wiped out because this gets hit:

It is caused by this code here in wasi-libc:

https://github.com/WebAssembly/wasi-libc/blob/cab0ec601e0d3b1b6eb1be9d76f36aad5507998b/libc-bottom-half/cloudlibc/src/libc/fcntl/openat.c#L79

which makes O_LARGEFILE (0x8000) become 0x0008 after the bit shift, which is the value of UVWASI_O_TRUNC. If I understand wasi-lib's openat code correctly, the real O_TRUNC flag (0x200 I believe) would appear in fs_flags, not in o_flags... I am not sure if the bug is on wasi-libc's side or on uvwasi's side. If the mistake is on wasi-libc's side, please let me know and I will re-create this issue on their side instead.

Thanks!

I would be super interested in being able to have socket support in order to be able to implement network applications, such as a pure WASI HTTP server in https://github.com/sdeleuze/kowasm which leverages Node WASI API. I am not a C developer so I create this issue is case somebody would be interested to help on this, since there are a lot of use cases that require it. The support would be initially single-threaded but https://github.com/WebAssembly/wasi-threads is moving again so there is hope that limitation could be removed later.

This can be done by supporting sock_accept() which has been added pretty late to the spec. I previously leveraged that in a Rust + Mio HTTP server prototype which was running on Wasmtime. That would allow to anticipate WASI preview2 support which will provide more first class and standardized networking support.

Currently, uvwasi_path_symlink() does not resolve old_path to fd. This is a bug. It should be resolved to fd the same way new_path is.

EDIT: old_path should not be resolved to fd. That said, path_symlink() is broken.
EDIT: uvwasi_path_open() needs to handle opening symlinks created by WASI.