Windows: WebContent crashes on every page load — VERIFY(target_entry->document_state()->ever_populated()) in LocalTraversableNavigable.cpp:756

[novaxertz]

Windows: WebContent crashes on every page load — VERIFY(target_entry->document_state()->ever_populated()) in LocalTraversableNavigable.cpp:756

Summary

On a native Windows build (clang-cl), the WebContent process crashes immediately on any page load, including about:blank. The browser window opens, but WebContent dies and is respawned in a loop, so no content is ever rendered.

The failure is a spec assertion in the "traverse" branch of LocalTraversableNavigable:

VERIFICATION FAILED: target_entry->document_state()->ever_populated()
  at Libraries/LibWeb/HTML/LocalTraversableNavigable.cpp:756

The same commit builds and runs correctly on Linux, so this appears specific to the Windows port.

Environment

Commit	561d89e787 (LibWeb: Drop subtree paint captures when a box becomes scrollable)
OS	Windows 11 Home Single Language, build 26200
Compiler	clang-cl 19.1.5 (bundled with VS 2022 Community)
MSVC toolset	14.44.35207
Windows SDK	10.0.26100.0
Qt	6.10.0 (vcpkg, x64-windows)
Skia	148, features core,direct3d,freetype,harfbuzz,icu
Build preset	Release, via py Meta\ladybird.py build
CPU / GPU	i7-12650H / RTX 4060 Laptop + Intel UHD

The build itself completed with zero errors.

Steps to reproduce

.\Ladybird.exe --headless=text about:blank

Or simply launch Ladybird.exe normally — the same crash loop occurs with the GUI.

Expected

about:blank loads. On Linux, this command exits 0 and prints no assertion.

Actual

WebContent aborts on the assertion and is respawned repeatedly:

Ladybird(23028): WebContent process crashed! Last page loaded: about:blank
Ladybird(23028): Consider raising an issue at https://github.com/LadybirdBrowser/ladybird/issues/new/choose

~12 crash/respawn cycles in 40 seconds. Windows Error Reporting records an identical fault every time:

Faulting application: WebContent.exe
Faulting module:      lagom-web.dll
Exception code:       0xc0000005   (access violation)
Fault offset:         0x0000000001ba2ac3

The fault bucket is identical across all occurrences, so this is deterministic rather than a race.

Stack trace

VERIFICATION FAILED: target_entry->document_state()->ever_populated() at Libraries\LibWeb\HTML\LocalTraversableNavigable.cpp:756
Stack trace (most recent call first):
#0  AK::Function<void ()>::CallableWrapper<`lambda at Libraries\LibWeb\HTML\LocalTraversableNavigable.cpp:678:105'>::call() at AK\Function.h:224
#1  Web::HTML::Task::execute() at Libraries\LibWeb\HTML\EventLoop\Task.cpp:54
#2  Web::HTML::EventLoop::process() at Libraries\LibWeb\HTML\EventLoop\EventLoop.cpp:158
#3  AK::Function<void ()>::CallableWrapper<`lambda at Libraries\LibWeb\Platform\Timer.cpp:19:27'>::call() at AK\Function.h:224
#4  Core::Timer::timer_event() at Libraries\LibCore\Timer.cpp:94
#5  Core::ThreadEventQueue::process() at Libraries\LibCore\ThreadEventQueue.cpp:113
#6  Core::EventLoopImplementationWindows::pump(Core::EventLoopImplementation::PumpMode) at Libraries\LibCore\EventLoopImplementationWindows.cpp:365
#7  Core::EventLoopImplementationWindows::exec() at Libraries\LibCore\EventLoopImplementationWindows.cpp:270
#8  ladybird_main(Main::Arguments) at Services\WebContent\main.cpp:277
#9  main(int, char**) at Libraries\LibMain\Main.cpp:46
#10 __scrt_common_main_seh() at exe_common.inl:288
#11 BaseThreadInitThunk
#12 RtlUserThreadStart

Cross-platform comparison

Same command on Ubuntu 26.04 (gcc 15.2, system Qt 6.10.2) under WSL2:

$ ./Build/release/bin/Ladybird --headless=text about:blank
EXIT=0
ever_populated assertions:  0
VERIFICATION FAILED count:  0

Linux passes cleanly; Windows fails deterministically.

Note on commits: the Windows crash is confirmed at 561d89e787 (current master at time of filing) and was originally found at 3f3bf5c7c1. The Linux control run above was performed at 3f3bf5c7c1. git diff 3f3bf5c7c1..561d89e787 shows no changes to Libraries/LibWeb/HTML/LocalTraversableNavigable.cpp, to any ever_populated logic, or to Libraries/LibCore/EventLoopImplementationWindows.cpp, so the comparison should still hold — but I have not re-run the Linux control at 561d89e787.

Additional observations

• Not rendering-related. --force-cpu-painting produces the identical crash (21 crashes observed), so the Direct3D/Skia backend is not implicated. The process never reaches renderer initialization.
• No web content required — about:blank is sufficient.
• The crash arrives via EventLoopImplementationWindows::pump(), i.e. the Windows-specific event loop, and the failing task is the queue_apply_history_step_task continuation lambda from LocalTraversableNavigable.cpp:678.

Possible direction (speculative)

I have not root-caused this, and the following is a hypothesis only.

The assertion at line 756 is the spec assertion for navigationType == "traverse":

case Bindings::NavigationType::Traverse:
    // - "traverse": Assert: targetEntry's document state's ever populated is true.
    VERIFY(target_entry->document_state()->ever_populated());
    break;

Reaching it during initial about:blank startup suggests a traversal is being applied against a session history entry whose document state was never populated. Given that the only platform-specific frame in the stack is EventLoopImplementationWindows, a difference in task scheduling or ordering between the Windows event loop and the POSIX one seems a plausible place to look — e.g. the history-step task running before the initial document has been populated.

Related

• Windows support #38 — Windows support (tracking)
• WebContent crash in TraversableNavigable #6840 — WebContent crash in TraversableNavigable. Different branch of the same switch: that issue concerns adding the FIXME assertions for Replace/Push and finding ever_populated is true where the spec expects false. This report is the inverse case in the existing Traverse assertion (false where the spec requires true), which may indicate the same underlying bookkeeping problem.

Happy to test patches or gather more diagnostics; I have working builds of this commit on both Windows and Linux for comparison.

[novaxertz]

Update: the assertion is a secondary failure — the primary one is an IPC startup failure

I instrumented both a Windows and a Linux build at the same commit to compare. The assertion in LocalTraversableNavigable.cpp is not the original fault; it is reached only through crash recovery after WebContent has already died.

Failure chain

1. WebContent fails a synchronous IPC wait during startup and shuts the transport down before processing any queued messages:

WebContent: Failed to receive message_id: 8
WebContent: Transport shutdown with unprocessed messages left: 33
 Message 000 is:  4-WebContentServer::Initialize
 Message 005 is: 16-WebContentServer::ConnectToCompositorProcess
 Message 006 is:  8-WebContentServer::SetWindowHandle
 ... (33 total, none processed)

This comes from wait_for_specific_endpoint_message_impl in Libraries/LibIPC/Connection.cpp:172, on the peer_disconnected_during_wait path that calls shutdown().

2. The UI observes the dead process and enters crash recovery. Stack captured with a temporary VERIFY(false) at the top of recover_from_web_content_process_crash:

#0 WebView::CanonicalTraversable::recover_from_web_content_process_crash(...)      CanonicalTraversable.cpp
#1 WebView::ViewImplementation::recover_current_session_history_entry_with_history_operation(...)  ViewImplementation.cpp:2691
#2 WebView::ViewImplementation::handle_web_content_process_crash()                 ViewImplementation.cpp:3013
#3 lambda at WebContentClient.cpp:444
#4 Core::ThreadEventQueue::process()                                               ThreadEventQueue.cpp:130
#5 Core::EventLoopImplementationWindows::pump(...)                                 EventLoopImplementationWindows.cpp:365

3. Recovery calls enqueue_browser_history_traversal(...) with the current step, so the operation has was_initiated_by_browser = true. start_history_operation then takes the is_browser_traversal() branch and applies the step as NavigationType::Traverse.

4. The replacement WebContent applies that Traverse against the initial about:blank entry, whose document state was never populated, and hits VERIFY(target_entry->document_state()->ever_populated()).

5. That kills the new WebContent, which triggers recovery again — hence the loop.

Instrumented comparison (same commit, 561d89e787)

Logging in CanonicalTraversable::apply_history_step (UI side) and at the navigationType switch in LocalTraversableNavigable (WebContent side):

Linux (Ubuntu 26.04, gcc 15.2, system Qt 6.10.2) — exits 0:

APPLYSTEP(ui): step=0 nav_type=1 check_for_cancelation=false browser_traversal=false
APPLYHIST: nav_type=1 update_only=false traverses_from_initial_about_blank=false displayed==target=false
           ever_populated=true reload_pending=false displayed_is_initial_about_blank=true target_step=0

Windows (clang-cl 19.1.5, vcpkg Qt 6.10.0) — crash loop:

APPLYSTEP(ui): step=0 nav_type=3 check_for_cancelation=false browser_traversal=true
APPLYHIST: nav_type=3 update_only=false traverses_from_initial_about_blank=true displayed==target=false
           ever_populated=false reload_pending=false displayed_is_initial_about_blank=true target_step=0

(nav_type 1 = Replace, 3 = Traverse.)

Linux applies the initial step as Replace against a populated entry and never enters crash recovery. Windows applies it as a browser-initiated Traverse against an unpopulated entry.

Notes

• Reproduces with --temporary-profile, so this is not stale session state.
• --force-cpu-painting makes no difference; the renderer never gets that far.
• Only WebContent.exe faults. Compositor.exe does not fault at any point.

Possible starting point (unverified)

The only Windows-specific synchronous IPC in the WebContent startup path that I could find is the peer-PID handshake in Services/WebContent/ConnectionFromClient.cpp:

#ifdef AK_OS_WINDOWS
    // Perform Windows peer PID handshake before any other IPC
    if constexpr (requires { m_compositor_connection->transport().set_peer_pid(0); }) {
        auto response = m_compositor_connection->send_sync<Messages::CompositorWebContentServer::InitTransport>(Core::System::getpid());
        m_compositor_connection->transport().set_peer_pid(response->compositor_pid());
    }
#endif

I want to be clear that I have not confirmed this is the failing wait. Two things argue against jumping to it: Compositor.exe never faults, and the unprocessed messages listed at the failure are WebContentServer messages (i.e. the UI connection) rather than compositor messages. It is simply the most obvious #ifdef AK_OS_WINDOWS sync wait on that path, and possibly related to #10660.

There may also be a second, independent issue here: crash recovery reconstructing an initial about:blank entry as a Traverse looks wrong regardless of what killed the first process, since such an entry can never satisfy the ever_populated assertion.

Happy to run further diagnostics or test patches — I have builds of this commit on both Windows and Linux.

[novaxertz]

Correction to my previous comment, and the actual root cause

Please disregard the IPC failure described in my previous comment. That was my own instrumentation artifact and not part of the real failure.

In the run where I captured Failed to receive message_id: 8 / Transport shutdown with unprocessed messages left: 33, I had a temporary VERIFY(false) at the top of recover_from_web_content_process_crash to capture a caller stack. That assertion killed the UI process, so the child WebContent legitimately lost its IPC peer and reported the unprocessed message backlog. With non-fatal logging only, that IPC error never appears. The #ifdef AK_OS_WINDOWS compositor handshake I speculated about is very likely irrelevant here — apologies for the noise.

The overall shape I described (something kills WebContent first, and crash recovery converts that into a Traverse loop) still holds, and is now confirmed. What was wrong was the identification of that first crash.

Confirmed event ordering

With dbgln-only instrumentation (no traps), on 561d89e787:

ORDER: handle_web_content_process_crash
ORDER: recover_from_web_content_process_crash has_endpoint=true
ORDER: apply_history_step step=0 nav_type=3 browser_traversal=true
VERIFICATION FAILED: target_entry->document_state()->ever_populated()   <- replacement WebContent
ORDER: handle_web_content_process_crash
... repeats

So a WebContent process dies before any assertion, silently. Crash recovery then enqueues a browser-initiated traversal (was_initiated_by_browser = true), start_history_operation takes the is_browser_traversal() branch and applies the step as NavigationType::Traverse, and the replacement process hits the ever_populated assertion. That is the loop.

The first crash

Windows Error Reporting shows two distinct signatures per session:

Occurrence	Faulting module	Exception code
First, once per session	lagom-web.dll	0xc0000005 (access violation)
All subsequent	lagom-ak.dll	0xc000001d (illegal instruction — the VERIFY trap)

The first fault has a stable offset across every run: 0x1ac84ff. Symbolizing it against the build's PDB:

$ llvm-symbolizer --obj=lagom-web.dll --demangle 0x181ac84ff
libweb_rust::painting::paintable_geometry::scrollable_overflow_rect::<
    libweb_rust::painting::paintable_rows::PaintableRows<
        &libweb_rust::layout::layout_node_arena::LayoutNodeArena>>

So the initial crash is an access violation inside the Rust painting code, in Libraries/LibWeb/Rust/src/painting/paintable_geometry.rs:

pub(crate) fn scrollable_overflow_rect(arena: &impl PaintableRowsRead, slot: NodeSlotId) -> Option<CssPixelRect> {
    let data = arena.paintable_data(slot);
    ...
}

Worth noting: PaintableRows::paintable_data in paintable_rows.rs is fully checked — it asserts on an invalid slot id, uses .get(...).expect(...) for the chunk, and asserts on slot_generation. A bad NodeSlotId would therefore panic rather than fault. That suggests the faulting dereference is of self.arena itself (the symbol is instantiated on PaintableRows<&LayoutNodeArena>), i.e. an invalid &LayoutNodeArena reaching Rust — rather than a bad slot index.

I have not gone further than that; I did not want to guess at the arena's lifetime requirements across the FFI boundary.

Environment / reproduction (unchanged)

• Commit 561d89e787, Windows 11 26200, clang-cl 19.1.5, MSVC 14.44, Windows SDK 10.0.26100, Qt 6.10.0 (vcpkg), Release build via py Meta\ladybird.py build
• .\Ladybird.exe --headless=text about:blank
• Reproduces with --temporary-profile and with --force-cpu-painting
• Linux at the same commit (gcc 15.2, system Qt 6.10.2) exits 0; it applies the initial step as Replace with browser_traversal=false and ever_populated=true, and never enters crash recovery

Secondary observation

Independently of what causes the first crash, it may be worth looking at whether crash recovery should issue a Traverse for an initial about:blank entry at all. Such an entry can never satisfy VERIFY(target_entry->document_state()->ever_populated()), so any crash during initial page setup turns into an unrecoverable loop rather than a single recoverable crash.

Happy to run further diagnostics or test patches.