asyncify & exception catching

[Александр Гурьянов]

Hi. I use asyncify for dosbox/dosbox-x project, everything works well. But I have little problem, I need to force exit from dosbox. To do this I set flag exitRequested in c++ code while asyncify is in paused state. When it resumes the dosbox check this flag and breaks normal loop execution.

This trick works mostly, but it can happen that something goes wrong (e.g. bad place to break the loop), and some unhandled exception will be thrown from webassembly.

Typical is:

Uncaught RuntimeError: memory access out of bound

This exception is unhadled and my client script can't understand that dosbox is died. So I want to catch this exception somehow.I tried to wrap wakeUp (js) function with try/catch but no luck.

The only way I found is to add "error" listener, but it is not possible to understand if it error from my dosbox instance (I can run multiple instances per page).

So, my question is it possible to turn this unhandled exception to handled?

[Floh]

Aplologies for the drive-by comment, I don't have a solution for the exception handling question, but that error message caught my eye. If you're already on emsdk 3.1.27 (with the default stack size reduced to 64 KBytes) you would get that exact same error in debug mode when a stack overflow happens (or rather underflow, because AFAIK in debug mode the stack now sits at the bottom of the address space to catch stack overflows).

[Sam Clegg]

IIUC this is what the `-sABORT_ON_WASM_EXCEPTIONS` settings is for.  This basically wraps all the entry points to your wasm module in a try/catch.  I'm not sure its the best way to handle this but its sounds like its trying to solve the problem you are facing:

```

// Abort on unhandled excptions that occur when calling exported WebAssembly        
// functions. This makes the program behave more like a native program where the
// OS would terminate the process and no further code can be executed when an      
// unhandled exception (e.g. out-of-bounds memory access) happens.                  
// This will instrument all exported functions to catch thrown exceptions and      
// call abort() when they happen. Once the program aborts any exported function    
// calls will fail with a "program has already aborted" exception to prevent    
// calls into code with a potentially corrupted program state.                      
// This adds a small fixed amount to code size in optimized builds and a slight    
// overhead for the extra instrumented function indirection.  Enable this if you    
// want Emscripten to handle unhandled exceptions nicely at the cost of a few      
// bytes extra.                                                                  
// Exceptions that occur within the `main` function are already handled via an      
// alternative mechanimsm.                                                          
// [link]                                                                          
var ABORT_ON_WASM_EXCEPTIONS = false;    

```

 

--
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-disc...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/CAKOm%3DVF%3Dmkcr-GYCeP3MVTccAbSy2a3dEnLnKv5X6MVXrmH7rg%40mail.gmail.com.

[Александр Гурьянов]

Thanks for advices, I found solution. There is whenDone() function that called on end of Asyncify execution, and in case of unhandled exception you can cath. Like this:

    Asyncify.whenDone().catch((error) => { ... });
    return Asyncify.handleSleep(function(wakeUp) { ...; wakeUp(); })

ср, 7 дек. 2022 г. в 22:24, 'Sam Clegg' via emscripten-discuss <emscripte...@googlegroups.com>:

To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/CAL_va28p1y1uZ84LsVWa3cci8zBicT46b-1heHWBGjN09WX4PQ%40mail.gmail.com.