The problem is that even if you can detect when you are nearing exhaustion of linear memory (and thus exhaustion of shadow stack space), you have no way to know when you are nearing the VM's stack limit. IIUC the stack limit of the VM is implementation defined and can't be relied upon which means that currently I don't think its possible to do what you are trying to do.
Also note that the shadow stack (the one you can measure) only grows when you use address taken local variables (or alloca) so in general I would expect to grow more slowly and the invisible VM stack which is going to grow by a non-zero amount on each call (I don't think any JS VMs currently implement automatic tail calls). On Fri, Nov 8, 2019 at 1:05 PM Hostile Fork <[email protected]> wrote: > > Hi Brion, thanks for the information! (Sorry, I posted earlier in the week > then got a bit busy...) > > > On Monday, November 4, 2019 at 3:49:39 PM UTC-5, Brion Vibber wrote: > >> The good news is that too-deep recursion has reasonably predictable behavior >> _after the fact_ -- a trap/exception is thrown on a too-deep call for the >> native call stack, which will unwind all the Wasm functions on the stack up >> to the nearest JS catch block. > > > That could be useful -if- you had associated atomicity guarantees. But is > even malloc() itself guaranteed to -either- successfully execute -or- throw a > stack overflow, leaving the heap in a safe state? Or might a stack overflow > happen in mid-bookkeeping of the C library functions? > > malloc()'s atomicity would be a necessary (but not sufficient) condition to > get safe stack overflow handling in a C-to-WASM program. You still need some > knowledge of how to bracket composite code of your own with an "all of these > operations will run, or none do" mechanic. > > (Can that even be achieved in plain JavaScript, or can stack overflows occur > from within "system" calls there as well?) > > >> The linear memory stack is maintained by convention within the WebAssembly >> code, with the stack pointer in a global variable which points at a region >> of linear memory, and is just used for stack-allocating data that needs to >> have its address taken or otherwise cannot fit in locals. > > > Okay... so the concept of the "locals" that *aren't* stack allocated, would > thus live in the "native stack" somewhere (?) > > >> But you can access that stack pointer and see how close you are to the edge. > > > If there's no other choice but this, it would be good to have it documented > how to do "right" and put into some regression test. A previous trick we > used for detecting stack growth direction and measurement stopped working > with the binaryen update: > > https://github.com/metaeducation/ren-c/blob/8f0dd1347b38958c0dff5c8e36256148eaf3de15/src/core/b-init.c#L114 > > I'm not sure what broke. I had suspected it was because the frames were > being allocated from the heap and not following any pattern (which wold be > free game according to the spec). But it doesn't sound like you're saying it > does that... > > > Thanks! > --Brian > http://hostilefork.com > > -- > You received this message because you are subscribed to the Google Groups > "emscripten-discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/emscripten-discuss/a8417cf2-e473-4f1b-97ee-219b8e0de7ad%40googlegroups.com. -- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/CAL_va290tH%3DxTg8h8Or%3DhKV49LY-6sFzz4dxXXm-Y139JqA2rA%40mail.gmail.com.
