If you want to use `longjmp` in emscripten to get back to start of the
failing test, we have two setjmp/longjmp mechanism. (1) The old emscripten
method (2) The method using wasm exception handling.
However, I believe that in both cases the target of the long jump has to be
above the caller on the stack. That is, once you unwind the stack all of
the way it will no longer be possible to `longjmp` to the target in
question since its no longer on the stack. @Heejin Ahn
<ahee...@google.com> can you confirm this?
If that is correct then you will need to some kind of alternative
mechanism when running in emscrpten. Something like this maybe:
```
void run_death_test(death_test_fn_t fn) {
#ifdef __EMSCRIPTEN__
EM_ASM({
try {
...call_fn_from_js..
report_failure_to_die()
} catch (e) {
report_success_if_e_looks_good(e)
}
})
#else
setup_longjmp_target():
fn();
#endif
}
```
On Mon, Sep 8, 2025 at 4:17 PM Sam Clegg <s...@google.com> wrote:
>
>
> On Mon, Sep 8, 2025 at 3:40 AM John Dallman <jgdatsiem...@gmail.com>
> wrote:
>
>> > 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.
>>
>
> Oh wow, `longjmp` out of your signal handler sounds pretty gnarly. It's
> going to be even more gnarly trying to make that work with
> emscripten-generated code, but maybe not impossible?
>
> Are there segfault tests limited in number? i.e. would it be possible to
> choose a different approach when running on the web (just for these few
> tests)?
>
>>
>>
--
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 emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion visit
https://groups.google.com/d/msgid/emscripten-discuss/CAL_va29WgYahkgoafxhXGs%2BPhfpP-o6GzQSgaTA3xRGhdPKRNg%40mail.gmail.com.
