Three correctness gaps found in code review of the private-loop
rewrite, all in how chansrv's thread and the IBus thread interact
around `bus`:
- xrdp_input_enable() read the shared `bus` pointer with no
synchronization at all, despite the IBus thread being free to null
it out (disconnect, teardown) at any time - a real use-after-free
risk, not just a formality, since this function actively calls
methods on it rather than just checking it's non-NULL. Fixed by
taking a ref under state_mutex before touching it, and using that
local reference for the rest of the call; bus's creation and
teardown in xrdp_input_main_loop() now publish/clear the shared
pointer under the same lock so the ref-under-lock pattern actually
synchronizes against something.
- xrdp_input_unicode_init()'s fast path trusted ibus_ready without
re-checking the connection. ibus_ready and connection liveness
normally change together, but there's a window between the
underlying socket actually dying and the "disconnected" signal being
dispatched on the IBus thread. A client that reconnects into that
window would get a false "unicode input is supported"
advertisement it could never actually use. Now double-checks
ibus_bus_is_connected() before taking the fast path.
- That staleness check can't just flip ibus_ready and fall through to
spawning a new thread - the old one may still be alive and about to
touch bus/g_engine itself, racing the new thread's own setup. Now
asks the stale thread to shut down (g_main_loop_quit, safe to call
cross-thread) and waits on the exit condvar before proceeding, so
there's never more than one IBus thread alive at a time.
Verified: 20 back-to-back xrdp_input_unicode_init() calls on a healthy
connection all take the fast path correctly (no spurious thread
restarts); 5 kill/restart cycles still show no thread leak; an 18-char
rapid-fire send against a real focused GTK entry still lands every
character in order with zero drops after these changes.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
XrdpIme never actually became the active engine after the private
main loop rewrite - ibus_bus_set_global_engine() returned FALSE every
time. Confirmed the actual D-Bus error by bypassing the boolean-only
wrapper and calling SetGlobalEngine directly:
Set global engine failed: Timeout was reached
Root cause: xrdp_input_enable() was being marshaled onto the IBus
thread via g_main_context_invoke(), on the (wrong) theory that it
"must run on the IBus thread" like commit_text does. But
set_global_engine() blocks synchronously waiting for ibus-daemon's
reply, and ibus-daemon can't reply until it finishes instantiating the
engine - which means calling back into our own IBusFactory's
"create-engine" over the same connection. Running xrdp_input_enable()
on the IBus thread left that thread stuck blocked inside its own
synchronous call, unable to service the nested callback ibus-daemon
needed answered before it could reply - a self-deadlock, resolved only
by ibus-daemon's own timeout.
Calling xrdp_input_enable() directly from chansrv's thread instead
(matching the original pre-rewrite code, which did this without
apparent reason but happened to sidestep the deadlock) leaves the IBus
thread free to answer the nested call while chansrv's thread blocks.
GDBusConnection sync calls are documented thread-safe to issue from
any thread, so this doesn't need marshaling despite `bus` otherwise
being owned by the IBus thread.
Verified end-to-end against a real ibus-daemon and a focused GTK entry
widget (not just the D-Bus trace): ibus engine now correctly reports
"XrdpIme" after a send, and 27 characters fired with zero delay
between them - the exact rapid-fire pattern that used to drop most
commits under the old design - landed in order with zero drops and
zero duplicates.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Replace the shared-global-context design with one where chansrv's
thread never touches libibus directly. All IBus objects (bus, engine,
factory, component) are now owned exclusively by a private
GMainContext/GMainLoop created inside the IBus thread; chansrv hands
off unicode codepoints through a thread-safe GAsyncQueue and wakes the
loop, instead of calling ibus_engine_commit_text() from the wrong
thread or relying on ibus_main()/ibus_quit(), which turned out to
operate on a single loop shared by the whole process rather than one
per connection.
Fixes along the way, found by testing against a live ibus-daemon and
a real focused GTK app rather than just reading the diff:
- xrdp_engine_enable()/disable() now take a real reference on g_engine
(g_object_ref/unref) instead of caching a bare pointer. The old code
unreffed g_engine on teardown without ever having reffed it - IBusEngine
derives from GInitiallyUnowned, so that was releasing a reference it
never owned.
- A custom GSource drains the unicode queue, gated on the engine
actually existing (engine creation is async once XrdpIme is
selected), so a character queued before the engine is ready isn't
lost - it commits as soon as the "enable" signal fires, instead of
racing a one-shot commit against that async setup.
- ibus_engine_commit_text() releases its IBusText argument itself
(it's floating, documented behavior for that specific call) - an
earlier draft of this rewrite added an extra g_object_unref() after
it, which would have been a double-release.
- bus (and anything else that opens a GDBusConnection) must be created
after the private GMainContext is pushed as thread-default, not
before - otherwise its async I/O silently binds to the global
default context, which nothing here iterates, and signals like
"disconnected" simply never fire.
- xrdp_input_unicode_init() now blocks on a condvar until the IBus
thread actually signals ready (or exits), instead of returning
immediately and hoping the engine shows up in time.
- unicode_init()/destroy() no longer touch bus/g_engine from chansrv's
own thread while the IBus thread may still be running against them;
destroy() schedules real teardown on the IBus thread and joins it via
a condvar before returning.
Known limitation, confirmed empirically rather than assumed: this does
NOT make reconnect-after-daemon-restart (#3230) actually work.
ibus_bus_new() returns a process-wide singleton in this libibus
version - two calls in the same process with no disconnect involved
return the identical pointer - so once its connection dies, every
later call just hands back the same dead object; ibus_bus_is_connected()
on it stays permanently false, confirmed not to be a transient state
via repeated retries with delay. The "disconnected" handler still
tears the thread down cleanly so a later xrdp_input_unicode_init()
fails fast instead of hanging or operating on stale state, but a real
fix would mean bypassing IBusBus for a raw GDBusConnection to
ibus-daemon, which isn't justified given how rarely the daemon
actually restarts mid-session.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
A few follow-on fixes found while testing the ibus reconnect changes
in a live session:
- xrdp_input_unicode_init() failed outright if ibus had no default
global engine yet at connect time, which is a normal state on a
fresh session (nothing has chosen one yet), not an error. Since
nothing else used the return value, this permanently killed unicode
input for the whole session over a spurious check.
- ibus can disable our engine instance (e.g. on a focus change) while
leaving the global engine name as "XrdpIme", since those are tracked
separately. xrdp_input_enable()'s fast path only checked the name,
so it could skip re-asserting and leave xrdp_input_send_unicode()
committing text through a disabled g_engine. Clear g_engine on
disable and require it to be set for the fast path to apply.
- ibus_engine_commit_text() was being called from chansrv's own
thread, not the thread pumping the glib main loop that owns the
engine's D-Bus connection (xrdp_input_main_loop). Marshal the actual
commit through g_main_context_invoke() onto the correct thread.
None of these are the full fix for intermittent dropped commits during
real pinyin input testing - that's still open, with the current lead
being ibus Reset calls interleaved with commit bursts, likely from the
FocusOut/FocusIn churn caused by passing every raw keystroke through
engine_process_key_event_cb. To be continued.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Fixes#3230. The static `bus` global was only ever checked for
non-NULL, not for whether the underlying connection was still alive.
If ibus disconnected (daemon restart, stale socket) or the initial
connect attempt failed, `bus` was left set to a dead/freed connection,
so every later call to xrdp_input_unicode_init() took the "already
initialized" fast path and operated on it.
- Null out bus/g_engine in the "disconnected" signal handler instead
of leaving them dangling after g_object_unref().
- Check ibus_bus_is_connected() before trusting a cached bus, and
tear down + reconnect if it's stale.
- Unref and clear bus on a failed connect attempt instead of leaving
it set.
- Guard the unrefs in xrdp_input_unicode_destroy() now that bus/
g_engine can legitimately already be NULL.
The initial implementation of Uinicode input via IBus used a startup delay
of 3 seconds to wait for the daemon to be ready before connecting to it.
This commit introduces a poll-wait loop which can remove the delay
entirely if the daemon is up when chansrv starts the interface.
Liyi Meng