# Linux: "Qoder Remote Control Sync" helper SIGSEGVs during history sync after a turn with images **URL:** \ **Category:** Bug Reports\ **Tags:** settings\ **Created:** [October 19, 2026, 5:25am UTC](https://forum.qoder.com/t/linux-qoder-remote-control-sync-helper-sigsegvs-during-history-sync-after-a-turn-with-images/13338 "2026-10-19T05:25:01Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![Mystical89](https://yyz2.discourse-cdn.com/flex010/user_avatar/forum.qoder.com/mystical89/32/6546_2.png) [@Mystical89](https://forum.qoder.com/u/Mystical89)\ **Post date:** [October 19, 2026, 5:25am UTC](https://forum.qoder.com/t/linux-qoder-remote-control-sync-helper-sigsegvs-during-history-sync-after-a-turn-with-images/13338/1 "2026-10-19T05:25:01Z")
## Environment - Qoder Desktop 0.4.8 (stable), Linux x86\_64 - Arch Linux / Omarchy 2026.9.7, kernel 7.2.8-9-omarchy, Wayland (Hyprland) - Remote Control: enabled (Settings → Mobile) - Chat session contains image attachments / tool-result images - Bundled: @img/sharp 0.34.5, @img/sharp-libvips-linux-x64 1.2.4 (libvips 8.17.3) - System GLib/libgobject 2.90.0 - Helper process: `Qoder Remote Control Sync`, `node.mojom.NodeService`, `--max-old-space-size=512` ## Summary Completing an assistant turn in a chat that contains images starts the Remote Control history sync. 9–17 ms after the sync logs `REMOTE_CONTROL_IMAGE_INVALID` (stage `resources`), the `Qoder Remote Control Sync` utility process dies with SIGSEGV (exit code 139). The main process survives and respawns the helper, which retries — in one episode this produced 6 crashes in 24 seconds. I collected 11 coredumps over 4 episodes; every core has the same stack. ## Steps to reproduce 1. Enable Remote Control (Settings → Mobile). 2. Open a chat session that contains image attachments. 3. Complete an assistant turn (this triggers the history sync; in my case it was a long final report). 4. Watch `main.log`: `REMOTE_CONTROL_IMAGE_INVALID` is followed 9–17 ms later by the helper crash. Reproduced 4/4 episodes, 11 cores. `reason:"killed", exitCode:15` entries in the log are normal helper shutdowns; the crashes are the `exitCode:139` entries. ## Expected The sync either completes, or skips the offending image and continues. The helper process stays alive. ## Actual SIGSEGV in a libuv worker thread inside the bundled sharp/libvips addon. The helper exits with 139, gets respawned, and the retry loop can crash repeatedly. The main window stays responsive; no data was lost and there was no OOM pressure. ## Log evidence (timestamps UTC; main.1.log) ```auto [2026-10-18T18:29:55.586Z] [WARN] [main] [QoderRemoteControl] Remote Control 操作未完成 {"sessionId":"","stage":"resources","failureCode":"REMOTE_CONTROL_IMAGE_INVALID"} [2026-10-18T18:29:55.595Z] [ERROR] [main] [App] Electron child process exited {"type":"Utility","reason":"crashed","exitCode":139,"serviceName":"node.mojom.NodeService","name":"Qoder Remote Control Sync"} ``` ## Core dump stack (gdb, all 11 cores identical) ```auto SIGSEGV, SEGV_MAPERR, PC = 0x0, thread = libuv-worker #0 0x0000000000000000 (call through null) #1 g_object_unref (system libgobject-2.0.so.0, GLib 2.90.0) #2 sharp-linux-x64.node + 0x1835d #3 sharp-linux-x64.node + 0x2000c #4 sharp-linux-x64.node + 0x16eac ... node::ThreadPoolWork / libuv-worker ``` ## Analysis Verified from the core and the shipped binaries: - The crashing path is the image-handling (“resources”) stage of the Remote Control sync, on its error path. - `sharp-linux-x64.node` has no `NEEDED` entry for libgobject but references `g_object_unref` as an undefined symbol, so it binds at runtime to the system libgobject that Electron loads. - The bundled `libvips-cpp.so.8.17.3` statically embeds GLib: it defines and exports its own `g_object_unref`, `g_object_ref`, `g_malloc`, etc. (1788 `g_*` symbols), and has no `NEEDED` entry for libglib/libgobject. Inference: two independent GLib implementations coexist in the helper. A VipsImage allocated/finalized through the bundled GLib is unref’d through the system GLib (or vice versa), so the object’s class pointer is incompatible and the finalize vfunc resolves to NULL — which matches the deterministic PC = 0. Because this happens on the validation-failure path, any image the sync considers invalid can trigger it. Secondary observation: at least one image URL that the sync reported as `REMOTE_CONTROL_IMAGE_INVALID` returned a valid PNG when fetched manually, so I could not confirm that the image was genuinely invalid — the validation itself may also be worth a look. ## Suggested fixes 1. Ensure a single GLib implementation for the image pipeline (e.g. link libvips/libgobject against the same GLib, or prevent the addon’s `g_*` symbols from binding across the two copies). 2. Treat per-image sync failures as non-fatal: log, skip the image, keep the helper alive. ## Workaround Disabling Settings → Mobile → Remote Control stops the crashes. As of 2026-10-18 the updater reports `server-no-update`, so 0.4.8 is the latest offered build. ## Attachments I can provide a redacted `main.log` excerpt. Core dumps are not attached: they contain full process memory, including chat content. ---
**Author:** ![Screen\_White](https://yyz2.discourse-cdn.com/flex010/user_avatar/forum.qoder.com/screen_white/32/6349_2.png) [@Screen\_White](https://forum.qoder.com/u/Screen_White)\ **Post date:** [October 22, 2026, 2:20am UTC](https://forum.qoder.com/t/linux-qoder-remote-control-sync-helper-sigsegvs-during-history-sync-after-a-turn-with-images/13338/2 "2026-10-22T02:20:00Z")
One thing that stood out to me is the repeated crash-and-restart cycle. Even before the underlying issue is fixed, maybe the sync helper could stop retrying the same failed job after a few crashes. That might at least prevent it from getting stuck in a loop.