WASM build needs RUSTFLAGS set to to work

[Manishearth]

If you build the node package (built using this bash file, invoked by npm build) and try to run the wasm demo (npm run start in wasm-demo), it succeeds by default, but it fails if you remove the RUSTFLAGS in the build file.

The failure shows up as "memory access out of bounds" error. The JS web debugger points to a non-heap write for this, I don't fully trust this but it does point to it being a max stack error / stack overflow.

It still succeeds if the RUSTFLAGS are actually just set to the empty string.

We should investigate this.

Things to try:

• Reduce the invocation and try to repro the discrepancy with a simpler set of flags
• Try a newer compiler
• Try reproducing this in pure node. I suspect the website is needed since the website does a lot more at once.

Couple notes:

• Rerunning the build requires deleting lib and rerunning npm build, followed by deleting/reinstalling node_modules in the wasm-build folder via npm i
• Worth clearing out the locally-created target dir to prevent incremental compilation from being a factor

cc @robertbastian @sffc

[Manishearth]

I did -vvv builds with and without RUSTFLAGS. Here's what I got

• without RUSTFLAGS
• with RUSTFLAGS

I'm not 100% sure i've labeled these two correctly

The thing that stands out the most is that -C 'link-args=-z stack-size=20480' (which we set in .cargo/config)

Perhaps the cargo config rustflags key is only obeyed when RUSTFLAGS is set from down high? That feels extremely counterintuitive.

[Manishearth]

I think it's the other way around; wha'ts happening is that RUSTFLAGS disables our stack size setting.

perhaps we don't need it anymore?

[sffc]

Hmm. A few thoughts

1. Good investigation so far
2. Why the heck would ICU4X be using more than 20480 B in stack size? That should be plenty for all non-datagen operations. The default stack size according to a quick Google search is 2 MB, which is much huger than we should want.
3. The reason we had this flag is that it lets us restrain the size of our WASM memory, which I think is still something we should try to do? Browsers kill web pages that use a lot of memory, especially on mobile.
4. Is it expected that we are getting "memory access out of bounds" for this? Why not "stack overflow"?

[Manishearth]

@sffc I'm pretty sure that number is in bytes, not kilobytes 😄

and I just verified that adding three zeores to it works fine

[Manishearth]

Is it expected that we are getting "memory access out of bounds" for this? Why not "stack overflow"?

Yes, because the wasm memory model doesn't work that way.

The WASM memory model is basically that all memory is one giant array buffer and pointers are simple indices. Unlike normal operating systems where memory accesses hit a page fault handler (and the stack is protected by "guard pages" that can emit stack overflow signals instead of simple segfaults), all memory accesses are either in-bounds or out-of-bounds and the wasm runtime can't tell anything further.

[Manishearth]

The reason we had this flag is that it lets us restrain the size of our WASM memory, which I think is still something we should try to do? Browsers kill web pages that use a lot of memory, especially on mobile.

Note that anything in ICU4X's .cargo/config will be respected by cargo invocations inside ICU4X, not elsewhere. We should probably document this flag and ask others to use it, but not set it ourselves except for our published npm package.

[sffc]

The WASM memory model is basically that all memory is one giant array buffer and pointers are simple indices. Unlike normal operating systems where memory accesses hit a page fault handler (and the stack is protected by "guard pages" that can emit stack overflow signals instead of simple segfaults), all memory accesses are either in-bounds or out-of-bounds and the wasm runtime can't tell anything further.

I get that WASM has a linear memory, divided between stack and heap (I'm not completely sure where static memory fits in). I don't have a detailed knowledge of how exactly the linear memory gets divided and what happens with either a heap or a stack overflow. What are the addresses of the bottom and top of the WASM linear memory, and as stack space gets consumed, do the addresses go down or up? I'd hope this is set up in such a way that the stack won't clobber the heap?

[Manishearth]

Also I did some more investigations, and the wasm demo succeeds under 40,000 B, but not 30,000 B.

[sffc]

OK. So, I think we should do two things here

1. Set the WASM stack size to something we know will work, perhaps 1 page (65536 B or maybe round down to 60000 B), and make sure it is used consistently. We can use this to block future PRs that increase the stack size even more.
2. File a new issue to investigate and instrument stack usage for basic ICU4X operations. Get to a point where we can decrease the WASM stack size again.

[Manishearth]

No, hold up, I don't think this is actually stack usage of ICU4X being the problem here. I think something else is increasing that stack size.

These are functions being called directly from JS, we shouldn't be having a stack size increase due to them. It's possible the stack-size command actually does more than it says on the tin, or that WASM's model includes stack size needed for the memcpy for the full postcard data, or something else.

I do think we should bump that number up for now (and I'm currently doing that in my wip changes) though.