emscripten-core / emscripten-core/emscripten

Provide a way to forward error stacktraces to the main thread

Open
#18,016 2 comments 1 reaction 0 assignees View on GitHub
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

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.