Matt Arant
0bb926a264
connectionRequest()/removeFromSessionList() already lock `lock` around every mutation of `sessions` (a session accepting or disconnecting), but every read of it - sendToAll() (all three overloads), getSessionByAlias(), and the debug-console processCommand() - iterated it with no lock at all. Exact same bug shape as Subscription::subscribers, fixed earlier today in SubscriptionManager.cpp, just in a completely separate container. Confirmed live via dmesg: a real segfault at a stable, deterministic instruction offset inside the binary, hit twice across separate process launches tonight - Socket::write() -> resetSocket() dereferencing a null EPoll reference, the same crash signature as the earlier Subscription fix, consistent with iterating `sessions` while another thread concurrently erased and freed one of its entries. sendToAll() backs most real gameplay broadcasts (combat, position, chat), so this is very likely the actual dominant cause of tonight's crash - not just the ItemDataBase-specific subscriber list the earlier fix addressed. Took the existing `lock` mutex around all five read sites. No new reentrancy risk: SubscriptionManager's "invite" verb already calls getSessionByAlias() while holding SubscriptionManager::lock, so the two mutexes now nest in one fixed order (SubscriptionManager::lock, then TCPServer::lock) - nothing acquires them in the reverse order anywhere in this codebase, so no AB-BA deadlock risk.