wasm-gui task#11 FIX VALIDATED: file-monitor hang gone (inotify backend); applicationsmenu has a separate remaining block

Rebuilt host+sidecar (restored node_modules via pnpm install -- concurrent churn
wiped target/+esbuild) and validated the inotify fix:

(1) The infinite hang is GONE: the applicationsmenu panel now PROGRESSES (reaches
the WM check at 45s + the system-bus connect) and its worker threads EXIT CODE 0,
where they previously parked forever never reaching g_task_return. GIO no longer
falls back to the hanging GPollFileMonitor.
(2) NO REGRESSION: panel-core (clock+separator) still draws (23200 px) with the
inotify libgio; it shows the same non-blocking WM warning yet draws.
(3) REMAINING (separate, smaller): the applicationsmenu plugin still blocks the bar
(clock+separator draws; +applicationsmenu -> black). Now that the file-monitor
workers complete, the block is elsewhere in applicationsmenu/garcon init (missing
button icon, or garcon eager-load blocking the plugin-add loop).

task#11 root cause (GPollFileMonitor async query_info, no inotify) is FIXED +
validated; the applicationsmenu-draws-the-bar goal is one step away. Fix is
constraint-#5 clean.

M8+XU0-XU2 green; XU3 core done; XU4 wallpaper done; XU5 builds+runs.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Author: NathanFlurry

experiments/wasm-gui/M8-STATUS-LOG.md

@@ -99,3 +99,4 @@
 2026-06-25T16b (task#11 -- KEEP_NAMES symbolization unlock CONFIRMED BLOCKED via every path): pursued the SECURE_EXEC_KEEP_NAMES symbolizer (which works for build-gtk-app.sh probes) to name the panel's hung GLocalFile worker. RESULT: blocked for the panel, root cause found + multi-path confirmed. (1) The NATIVE panel binary has NO wasm `name` section -- only DWARF (.debug_info 25MB/.debug_str 6MB etc.); the C names (g_file_query_info, garcon_menu_load, g_task_thread_pool_thread) live in DWARF, not a name section. (2) build-xfce4-panel.sh's OWN comment explains why: the libs (GLib/GTK) are built with -g, "so their DWARF dominates the final binary and lld omits the name section" (the panel itself is -g0). (3) Tried to strip the libs' DWARF so lld would emit the name section: llvm-strip --strip-debug is a NO-OP on wasm archive DWARF (2278 .debug sections remain); llvm-objcopy --remove-section ERRORS ("invalid relocation offset") on the relocatable .o archive members. (4) The full-DWARF binary (54MB) won't launch in the sidecar; (5) DWARF DW_AT_low_pc is zeroed (can't build an offline index->name map); (6) fpcast renumbers indices+offsets (breaks offline mapping vs the stripped runnable binary). So a symbolized panel worker stack is unreachable with the current wasi-sdk/binaryen toolchain. The KEEP_NAMES path works only for small single-source probes (build-gtk-app.sh compiles them -g0 with no DWARF-heavy lib inputs, so lld emits the name section). For a names-emitting panel one would need ALL linked libs rebuilt -g0 (huge) OR a binaryen pass that synthesizes a name section from DWARF (doesn't exist). Prefix libs verified intact after the strip attempt (members+symbols OK; strip was a no-op). task#11 remains: GLocalFile-async workers hang in the full panel; the fix needs a names-libs rebuild or in-panel printf-bisection of garcon's query_info path, both focused efforts. M8+XU0-XU2 green; XU3 core done; XU4 wallpaper done; XU5 builds+runs.
 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.
 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.
+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.