> Is the test harness and the library-under-test designed to be compiled into the > same executable?
Yes. We prefer to have the library-under-test be a shared object or Windows DLL, on platforms where that's possible, but we can have the harness and the library linked together, and that's what I'm planning to do for WebAssembly. I'm trying to avoid producing a JS wrapper for an API with hundreds of functions, hundreds of structs, and thousands of constants. It also passes lots of pointers to code and data through the interface. My customers who want a WebAssembly version of the library already have C/C++ or Swift code that calls it and want to use it that way. > i.e. on other platforms does it somehow catch and recover from sefaults? Yes.On platforms with signals, those are turned on for segmentation faults (and for some other signals, depending on the platform). The code is C, which sets regular checkpoints with setjmp() and the signal handling function longjmp()s to the latest checkpoint with a "test aborted" value. That's the basic idea, though it's rather more complicated in practice. The JS code I'm going to use will be very minimal. The test harness already has its own scripting language (a LISP dialect) built into it, and we have hundreds of thousands (not hyperbole) of test cases already written in it. So I'm not going to try to organise and control the testing from JS, because that would be a duplication of work already done. I'm just going to start the test harness and let it do its thing. I am *not* an experienced JS coder - I learned some of the language for the first time for this project - and the product is not targeted to the general web application market. > 1. Wrap your calls in a JS try/catch and inspect the exception you caught > and then (somehow?) continue with the test suite. (This is what Brooke > suggested already) I have a couple of questions about that: When the catch gets called, is it called by the same thread as did the segmentation violation? Is that thread's stack still intact? Has it been unwound? If it is the same thread and the stack is intact, then I should be able to call the function within the library that does signal handling on other platforms, and have it do its longjmp()s. If those conditions don't apply, then things are going to get more difficult. > 2. Install a global `onerror` handler that will catch all exceptions (much like the > global signal handler on linux). See https://nodejs.org/api/process.html#event-uncaughtexception. That says it's unsafe to resume, so that probably also applies to the case above? Thanks, John John On Thu, Sep 4, 2025 at 12:52 AM 'Sam Clegg' via emscripten-discuss < [email protected]> wrote: > > > On Wed, Sep 3, 2025 at 6:09 AM John Dallman <[email protected]> > wrote: > >> I'm porting a math library and its test harness to WebAssembly. The test >> harness is allowed to be specific to Node.js, but the library is not. Both >> are compiled from C and C++ code, which is my comfort zone. JavaScript is a >> language I don't know well and haven't done anything difficult in. >> >> I'm aware that WASI doesn't support traditional signals >> <https://github.com/WebAssembly/WASI/issues/166>. At present, when I >> intentionally set off an access violation, I get "RuntimeError: memory >> access out of bounds" and a traceback as Node.js exits. >> >> Is there a way to catch these errors and prevent Node.js exiting? >> Ideally, I'd be able to notify the test harness in some way that this had >> happened. If this involves JavaScript, please explain slowly and gently: >> I'm from the C world and new to web applications. >> > > Is the test harness and the library-under-test designed to be compiled > into the same executable? i.e. on other platforms does it somehow catch > and recover from sefaults? > > From the JS side you basically have two choice: > > 1. Wrap your calls in a JS try/catch and inspect the exception you caught > and then (somehow?) continue with the test suite. (This is what Brooke > suggested already) > 2. Install a global `onerror` handler that will catch all exceptions (much > like the global signal handler on linux). See > https://nodejs.org/api/process.html#event-uncaughtexception. > > I suppose in either the case the tricky part is going to be continuing the > test suite where you left off. How does that work in the native case? > > > >> >> The reason I'm asking this is that I will have to provide support to >> customers when the WebAssembly version of the library is released, and >> prefer to have my answers ready ahead of time. My employer wants to >> maintain their good reputation for customer service, and goes as far as >> having tests for deliberately-set-off runtime errors as part of routine >> testing, so that we can document what happens and how to handle them. >> >> Thanks very much, >> >> John >> >> -- >> 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 visit >> https://groups.google.com/d/msgid/emscripten-discuss/CAH1xqgnMY0%2BoOLMs51mo2x%2BBUhWdZq%3DkxFp-En7AX3OsVqcoQQ%40mail.gmail.com >> <https://groups.google.com/d/msgid/emscripten-discuss/CAH1xqgnMY0%2BoOLMs51mo2x%2BBUhWdZq%3DkxFp-En7AX3OsVqcoQQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- > 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 visit > https://groups.google.com/d/msgid/emscripten-discuss/CAL_va294N3hjD7ihiDiUNKx5nHMo%2BRNK4y%3D4nPp4Yh-282DFnA%40mail.gmail.com > <https://groups.google.com/d/msgid/emscripten-discuss/CAL_va294N3hjD7ihiDiUNKx5nHMo%2BRNK4y%3D4nPp4Yh-282DFnA%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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 visit https://groups.google.com/d/msgid/emscripten-discuss/CAH1xqgm%2Bcf1138QFG51%2B%3DE%3DC8J-5Opf%3D9juMS14vyMvzoqDEFg%40mail.gmail.com.
