Capture has serialized lock events since d6f32a083 and 3e3aa80fa, so
the out-of-order reconstruction machinery has nothing left to repair.
Mark now targets the recorded Wait/Obtain event index; the old reverse
scan could walk off the start of the timeline for a thread that never
waited.
InsertLockEvent wraps the uint8 slot index past the 64-entry
per-lock table, misattributing the 65th distinct thread to slot
0. Set the failure instead.
With unlock -> notify order the thread can be preempted by other thread,
for example one that wants to lock the very same lock. This would produce
incorrect ordering of lock release and acquire events.
The deploy job SFTPs the emscripten build using repo secrets
(SERVER/USERNAME/PRIVATE_KEY/REMOTE_PATH) that only exist upstream.
On a fork these are empty, so every push to a fork's master fails
with "remote_path is empty" even though the actual build succeeded.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LVBiYgtsB6okBueTwp5swa
Opening and parsing on the browser main thread froze the tab for the
whole load; the file selector path already loads in a worker thread,
so boot now uses the same thread, progress modal, and error dialogs.
The preloaded data package made every ?t= load download embed.tracy
as well. The startup glue now fetches embed.tracy only when no URL is
given, into the same /url.tracy slot, and the boot code has a single
open path.
Version and integrity checks throw from the View constructor, which
was outside the try/catch guarding the file open, so a bad argv trace
terminated the process. Catch and report it there as well.
The compare load thread caught only UnsupportedVersion, so a
corrupted or otherwise unloadable second trace escaped the thread as
std::terminate. Catch the same set as the main trace load and route
it to the existing bad-version dialog.
Exception catching was off by default in the web build, so the
try/catch handlers around trace loading were dead code and any
failure unwound through the page.
Loading on the browser main thread cannot start more than the 8
pre-created workers: beyond that, thread creation waits for the main
thread to return to its event loop, which the load never does.
Decompression threads were only an optimization, so on emscripten
spawn workers for at most 4 streams and decompress the rest on the
loading thread.
glfw 3.5.1 enables OBJC build-wide under CMake 4.x, remapping nfd's
nfd_cocoa.m to a language its scope never loaded; generate then fails on
CMAKE_OBJC_COMPILE_OBJECT. Initialize OBJC at the top level so sibling
scopes get the rules.
