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
{{ message }}
Repository navigation
WebSocket pending-event callbacks and payload snapshots are not rooted across moving GC #10027
Native MB24 loses the initial auction subscription during page load: two browsers complete the WebSocket handshake and send valid subscribe frames, but neither receives a subsequent committed bid. Re-sending the identical subscription after page initialization immediately restores delivery. This reproduces with the native binary; the same application passes its Node browser suite. Direct socket probes without page-load pressure pass.
The event pump snapshots raw callback pointers, then allocates the message string and invokes callbacks:
let listeners = listeners_on_client(ws_id,"message");let s = alloc_string(&text);for cb in listeners {JsClosure::from_raw(cb as*constRawClosureHeader).call1(msg_f64);}
The mutable root scanner updates WS_CLIENT_LISTENERS, but cannot update this copied Vec<i64> or the unrooted message value. Allocation or an earlier callback can therefore leave later dispatches using stale pointers. server::emit_server_event already roots its equivalent snapshots and arguments with TransientRootScope; js_ws_process_pending does not.
Reduced regression shape: register two message listeners; the first forces an evacuating collection, and the second must still receive the original payload through the relocated callback. Assert that both callback and payload addresses actually moved, so the test cannot pass without exercising relocation.
Observed on the MB24 v3 diagnostic runtime (source base d36a1af) with the #10023 compiler fix, PERRY_GC_INCREMENTAL=0, default moving GC, and mark verification enabled. The application binary is coherent with its runtime archives. Five other native browser scenarios pass, including voucher persistence and redemption.
Investigate and repair the dispatch roots; confirm the original browser scenario after rebuilding the WS extension. Keep this issue open until the deployed application has been retested.
Activity