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.
