emscripten-core / emscripten-core/emscripten
Provide a way to forward error stacktraces to the main thread
- Dominant language
- C++
- Stars
- 27.6k
- Forks
- 3.6k
- Avg merge
- 1d 1h
- Merged PRs (30d)
- 105
Description
We would like to have comprehensive error logging across our entire JS + Emscripten application, that should send both JS and C++ exceptions / crashes to our analytics provider, together with stack traces, regardless of which thread they happened on.
✅ I can register a handler for [window:error](https://developer.mozilla.org/en-US/docs/Web/API/Window/error_event). It receives all unhandled errors across the main thread, and the `error` property of the `ErrorEvent` contains the stacktrace.
✅ I can compile with `--emit-symbol-map` so that we can symbolicate the C++ stack traces we receive.
✅ Errors raised on worker threads are re-raised on the main thread.
❌ But when they are, they arrive in the window error handler in the form of an `ErrorEvent` whose `error` property is null.
❓Would it be possible / appropriate to change the way Emscripten workers reraise errors on the main thread so that more information is forwarded?
✅ I could register a handler for [WorkerGlobalScope.error](https://developer.mozilla.org/en-US/docs/Web/API/WorkerGlobalScope/error_event) when starting a new thread. That receives the stacktrace, which I can forward to the main thread with custom code.
❌ But the worker.js code initializing each worker is generated at buildtime and is AFAIK not customizable.
❌ Our code is cross platform and heavily multithreaded and we would like to avoid littering each std::async and std::thread call with a web specific error handler registration. It would also be unenforceable during future development.
❓Would it be possible / appropriate for Emscripten to provide a way, some sort of build setting to customize the generation of worker.js?
Note: I tried to write some code that runs on each starting thread, but ` __attribute__((constructor))` runs only on the main thread and a `thread_local` global is not constructed until accessed.
Contributor guide
Assessment
This issue has not been assessed yet.