Matt Arant
8009564a7a
Socket::write() unconditionally called resetSocket() (via EPOLL_CTL_MOD) from whatever thread called it, whenever it could grab `lock` - including while this same socket's OWN eventReceived() call was still mid-flight on another thread (past receiveData()'s lock_guard, but before its own trailing resetSocket()/return). Re-arming makes the fd immediately eligible for a third thread to pick up a fresh event and, if it decides to shut the connection down, delete the object outright (Thread::run() does exactly that on a false return) - while the original thread is still touching it. A real heap-corruption crash inside libc's malloc internals was confirmed live via dmesg under concurrent load, consistent with exactly this: a socket freed while another thread still held a reference to it. inHandler existed as a flag already but only fed a diagnostic log line - never actually gated anything. Made it a real std::atomic<bool> (was `volatile`, which gives no actual atomicity or cross-thread visibility) and used it two ways: - write() now skips its own resetSocket() call entirely while inHandler is true - that call's own eventReceived() will re-arm once it's actually done, seeing the fifo entry write() just queued. - eventReceived() itself was clearing inHandler well before its own resetSocket() call (several statements up, right after EPOLLIN/ EPOLLWRNORM handling) - moved the clear to immediately precede that call, closing the exposed window down to the minimum achievable without restructuring how write() re-arms sockets altogether. This is a distinct bug from the two subscriber/session-list races fixed earlier tonight (SubscriptionManager.cpp, TCPServer.cpp) - found while stress-testing those fixes turned up a third, different crash signature (heap corruption, not the null-EPoll-reference pattern the earlier two produced).