Correct. Both Emscripten and Wasm SjLj handling requires the setjmp point
to be "lower" than the longjmp point, because both use exceptions to
simulate setjmp-longjmp.
So this works:
```
static jmp_buf buf;
void bar() {
}
int main() {
int jmpval = setjmp(buf);
if (jmpval == 0) {
printf("first call\n");
} else {
printf("second call\n");
exit(0);
}
bar();
return 0;
}
```
But this does NOT work:
```
static jmp_buf buf;
void foo() {
int jmpval = setjmp(buf);
if (jmpval == 0) {
printf("first call\n");
} else {
printf("second call\n");
exit(0);
}
}
void bar() {
longjmp(buf, 1);
}
int main() {
foo();
bar();
return 0;
}
```
Because by the time longjmp is called, foo's call stack has been destroyed.
On Mon, Sep 8, 2025 at 4:31 PM 'Sam Clegg' via emscripten-discuss <
[email protected]> wrote:
> 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
> <[email protected]> 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 <[email protected]> wrote:
>
>>
>>
>> On Mon, Sep 8, 2025 at 3:40 AM John Dallman <[email protected]>
>> 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 [email protected].
> To view this discussion visit
> https://groups.google.com/d/msgid/emscripten-discuss/CAL_va29WgYahkgoafxhXGs%2BPhfpP-o6GzQSgaTA3xRGhdPKRNg%40mail.gmail.com
> <https://groups.google.com/d/msgid/emscripten-discuss/CAL_va29WgYahkgoafxhXGs%2BPhfpP-o6GzQSgaTA3xRGhdPKRNg%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/CALJpS1Nzcxx0mzS%2BxHTxrETvyGiuppeOcz68PNdjwNtYaG0YcA%40mail.gmail.com.
