Unfortunately, I think the backtrace you've attached is a crash during crash handling, rather than the original crash inside ibus that is the root cause. If I'm reading correctly, this is a crash-reporting thread that was started in response to some sort of crash (SIGSEGV?) on another thread, and it's the original crash that is the actual culprit here. thread apply all bt might show you the original crash.
In general, doing anything from a signal handler that is not async-signal-safe (signal-safety(7)) is undefined behaviour that will often lead to further crashes. There are virtually no libraries that are async-signal-safe, because normal things like taking locks and allocating/freeing memory are not safe to do in a signal handler. The actions that can validly be done in a signal handler are basically just glibc syscall wrappers, a very small number of library functions like sd_journal_sendv() that are specifically documented to be OK in this context, and using a small amount of stack memory.
In particular, libdbus and SDL are not designed to be async-signal-safe (they allocate and free memory), so it is undefined behaviour to invoke libdbus or SDL functions from inside a signal handler, so I think SteamThreadTools::CThread::ThreadExceptionWrapper needs to avoid calling into SDL.
@smcv Do you think this issue is closeable? Has there been anything done in the backend that would make this issue obsolete?
Nothing extracted yet.
Your system information
Please describe your issue in as much detail as possible:
While playing Bejeweled 3, steam crashed in ibus. Normally I don't report these crashes but the location of the crash was outside of Steam which allowed me to get a really good backtrace
backtrace.txt
The backtrace seems to point here https://gitlab.freedesktop.org/dbus/dbus/-/blob/master/dbus/dbus-dataslot.c?ref_type=heads#L157