You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
wasm-gui task#11 CLOSED: applicationsmenu panel DRAWS via inotify fix (clean upstream GLib)
End-to-end validated. Instrumented g_local_file_monitor_new (diagnosis-only,
reverted): with the inotify backend enabled GIO now picks GInotifyFileMonitor (47
selections = the watched menu files) instead of the hanging GPollFileMonitor, and
the busy-spin is GONE (net_poll BLOCK 0, was 4176).
FINAL CLEAN BUILD (GLib fully unmodified): the applicationsmenu+clock+separator
panel BAR DRAWS -- 23200 px, 0 spins, FB 1923232 bytes. Proof under
~/tmp/gui-progress/2026-06-25T12/.
Root cause: no inotify in wasi -> GLib's inotify backend uncompiled -> g_file_monitor
falls back to GPollFileMonitor -> g_file_query_info_async per file -> ~46 hung
workers -> black panel. Fix (constraint #5, sysroot+runtime only): sys/inotify.h +
no-op inotify stubs (never-ready fd) so GLib's UNMODIFIED inotify backend compiles
+ is selected (no events, fine for a static menu). Earlier black runs were a
stale-libgio panel + a 95s readback-timing fluke.
XU3 applicationsmenu = DONE. Same fix unblocks all g_file_monitor users
(Thunar/xfdesktop). M8+XU0-XU2 green; XU3 panel+applicationsmenu DONE; XU4
wallpaper done; XU5 builds+runs.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Copy file name to clipboardExpand all lines: experiments/wasm-gui/M8-STATUS-LOG.md
+1Lines changed: 1 addition & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -100,3 +100,4 @@
100
100
2026-06-25T16c (task#11 -- ★★★ ROOT CAUSE FULLY PINNED: GPollFileMonitor (no-inotify fallback) async query_info): traced the 46 hanging GLocalFile async tasks to their true origin. CHAIN: (1) garcon calls g_file_monitor on the menu dirs/files (garcon-menu.c etc.; it uses g_file_monitor 4x + SYNC g_file_enumerate_children -- none of garcon's own file ops are _async). (2) wasm has NO inotify -- sys/inotify.h is ABSENT from the wasi-sysroot, so GLib's inotify file-monitor backend is not compiled. (3) With no supported local-file-monitor backend, g_local_file_monitor_new returns NULL and g_file_monitor falls back to GPollFileMonitor (the polling monitor). (4) gpollfilemonitor.c:159+208 -> GPollFileMonitor does g_file_query_info_async (ETAG+SIZE) per watched file to detect changes. (5) Those ~46 async query_info workers are exactly the 46 hanging GLocalFile tasks (gtaskdiag): same call-site (one tag), query_info (not load_contents -- matches the probe where get_contents worked but query_info failed), 46 = number of watched menu files. So the menu hang is the GPollFileMonitor polling fallback's async query_info never completing. THE FIX (platform-layer, constraint #5 in-scope): provide an inotify backend so GIO does NOT fall back to polling -- add sys/inotify.h to the wasi-sysroot + stub inotify_init1/inotify_add_watch/inotify_rm_watch in the runtime (a dummy fd that never delivers events is fine -- a static menu needs no live change events), then reconfigure+rebuild GLib gio so its UNMODIFIED inotify backend compiles and its is_supported() returns true. GIO then uses the no-op inotify monitor instead of the hanging poll monitor -> the 46 query_info_async calls never happen -> menu loads. (Alt fix: make async query_info complete in workers -- the deeper root, harder.) This is the cleanest, most actionable task#11 fix found in the entire arc, and it is a sysroot/runtime fix, not a component patch. NEXT: implement the inotify sysroot header + runtime stubs + GLib gio rebuild. M8+XU0-XU2 green; XU3 core done; XU4 wallpaper done; XU5 builds+runs.
101
101
2026-06-25T16d (task#11 -- ★★★ FIX BUILT: inotify backend enabled, GIO no longer falls back to the hanging poll monitor): implemented the root-cause fix. (1) Added toolchain/compat-include/sys/inotify.h (struct inotify_event + IN_* constants + inotify_init/init1/add_watch/rm_watch decls) -- the wasi-sysroot has none, which is why GLib's inotify backend was never compiled. (2) Added NO-OP inotify runtime stubs to toolchain/wasi-compat.c: inotify_init1 returns the read end of a kernel pipe whose write end is held open + never written (a real but NEVER-READY fd), so GLib's inotify GSource polls but receives no events; add_watch returns a dummy wd; rm_watch no-ops. A static desktop menu needs no live change events. (3) Reconfigured GLib (meson --reconfigure --clearcache) -- now detects HAVE_SYS_INOTIFY_H=YES + inotify_init1=YES (the func test needed the fresh wasi-compat-threads.o, which cross-env.sh rebuilds with -I compat-include, in the cross-file c_link_args). (4) Rebuilt libgio: the inotify backend now compiles (28 inotify symbols incl _ik_startup + g_inotify_file_monitor_get_type; 8 ninja targets). (5) Relinked the panel (rc=0). So GIO now selects the no-op inotify file monitor instead of GPollFileMonitor -> garcon's g_file_monitor no longer spawns g_file_query_info_async per file -> the 46 hanging workers never happen. Constraint #5 honored: GLib's inotify backend is UNMODIFIED upstream; the fix is purely the sysroot header + runtime syscall stubs. VALIDATION PENDING: the shared target/ + root node_modules were wiped by a concurrent session (D node_modules in git status; esbuild missing -> host/sidecar can't rebuild right now). The menu-draws screenshot test is blocked on infra recovery (pnpm install + cargo build of wasm-gui-host + secure-exec-sidecar), NOT on the fix. Next fire: restore node_modules, rebuild the host, run the applicationsmenu panel, confirm the bar draws. M8+XU0-XU2 green; XU3 core done; XU4 wallpaper done; XU5 builds+runs.
102
102
2026-06-25T16e (task#11 -- ★★ FIX VALIDATED: file-monitor hang GONE; applicationsmenu has a separate remaining block): rebuilt host+sidecar (after restoring node_modules via pnpm install -- concurrent churn had wiped target/ + esbuild) and tested the inotify fix. RESULTS: (1) The infinite hang is GONE -- the applicationsmenu panel now PROGRESSES past where it used to stick forever: it reaches "No window manager registered on screen 0" (45s) + the system-bus connect, and its worker threads EXIT WITH CODE 0 (previously they parked forever, never reaching g_task_return). So GIO no longer falls back to the hanging GPollFileMonitor. (2) NO REGRESSION: panel-core (clock+separator, no applicationsmenu) still DRAWS cleanly (23200 bar px) with the inotify-enabled libgio -- and it shows the SAME "No window manager" warning yet draws, proving that warning is non-blocking. (3) REMAINING (separate, smaller): the applicationsmenu plugin specifically still prevents the bar from drawing -- clock+separator alone draws, but adding applicationsmenu -> black bar even at a 175s timeout. Since the file-monitor workers now complete, the remaining block is elsewhere in the applicationsmenu/garcon init (candidates: the missing 'org.xfce.panel.applicationsmenu' button icon blocking widget construction, or garcon's eager menu load blocking the panel's sequential plugin-add loop so clock+separator never get added). NET: task#11's ROOT CAUSE (GPollFileMonitor async query_info, no inotify) is FIXED + validated at the mechanism level; xfce4-panel no longer hangs on file monitors. The applicationsmenu-renders-the-bar goal is one step away. Fix is constraint-#5 clean (sysroot inotify.h + runtime no-op stubs; GLib inotify backend unmodified). NEXT: diagnose the applicationsmenu plugin's remaining block (stage the button icon; check garcon eager-load). M8+XU0-XU2 green; XU3 core done; XU4 wallpaper done; XU5 builds+runs.
103
+
2026-06-25T17 (task#11 -- ★★★★ CLOSED + VALIDATED: applicationsmenu panel DRAWS via the inotify fix, clean upstream GLib): the fix is COMPLETE and confirmed end-to-end. Instrumented g_local_file_monitor_new (diagnosis-only, reverted) to log the chosen backend -> with the inotify backend enabled, GIO now picks "GInotifyFileMonitor" (47 selections = the ~46 watched menu files + 1) instead of the hanging GPollFileMonitor, and the busy-spin is GONE (net_poll BLOCK count 0, was 4176). FINAL CLEAN BUILD (GLib fully unmodified, FMBACKEND + all diagnostics reverted): the applicationsmenu+clock+separator panel BAR DRAWS -- 23200 bar pixels, 0 spins, FB read back 1923232 bytes. Proof: ~/tmp/gui-progress/2026-06-25T12/xu3-applicationsmenu-bar-draws.png + xu3-applicationsmenu-bar-CLEAN.png. ROOT CAUSE (confirmed): wasi has no inotify -> GLib's inotify file-monitor backend wasn't compiled -> g_file_monitor fell back to GPollFileMonitor -> g_file_query_info_async per watched file -> ~46 async workers hung -> black panel. FIX (constraint #5 clean, sysroot+runtime only): toolchain/compat-include/sys/inotify.h + no-op inotify stubs in wasi-compat.c (never-ready fd) -> meson detects inotify -> GLib's UNMODIFIED inotify backend compiles + is selected (no-op, no events; a static menu needs none). The earlier "still black" runs were a stale-libgio panel + an FB-readback timing fluke (needed ~95s); the clean inotify build draws reliably. Note: required relinking the panel against the freshly-rebuilt inotify libgio + regenerating panel.wasm. XU3 applicationsmenu = DONE. The same fix unblocks any g_file_monitor user (Thunar/xfdesktop). M8+XU0-XU2 green; XU3 panel+applicationsmenu DONE; XU4 wallpaper done; XU5 builds+runs. NEXT: whiskermenu (XU3 remainder), then XU4/XU5 full render under the now-unblocked file-monitor path.
0 commit comments