Brad ArantandClaude Sonnet 5
a51a486560
TCPSocket's SSL_CTX*-taking constructor - the one every accepted TCPSession actually goes through (TCPSession(EPoll&, TCPServer*, ...) passes server->ctx into it) - never initialized the `tlsInfo` member, and TCPSocket.h gave it no default either. Every session's `tlsInfo` was uninitialized garbage. receiveData()/sendData() key their TLS-vs-plain dispatch on `if(tlsInfo)`. Since that garbage value is non-zero often enough on a real stack, sessions on a plain, non-TLS server were intermittently routed through TLS::receiveData()/sendData() (SSL_read()/SSL_write()) against an also-uninitialized SSL*, segfaulting inside libssl. Confirmed via dmesg: repeated "general protection fault ... in libssl.so.3", signal 11, non-deterministic timing consistent with depending on whatever garbage happened to be on the stack for a given session. Fixed by dispatching on `ctx` instead of `tlsInfo`. `ctx` (TLS.h) now defaults to NULL (previously also uninitialized) and is the value that actually gets set for real in TLS::createContext() and correctly inherited by every session via TLS(SSL_CTX*) - unlike `tlsInfo`, which is only ever set on the listening TCPServer's own constructor and never propagated to sessions at all. For the previously-working TLS-enabled case this is a no-op: ctx and tlsInfo were always both set (or both unset) together on the listening server, so the observable behavior there is unchanged - only the previously-undefined session-level behavior is fixed. Verified live: restarted the APIServer test instance (a plain, non-TLS TCPServer - the exact configuration that was crashing), ran 100 sequential requests with no failures, and confirmed no new libssl segfaults in dmesg since the fix (three separate pre-fix crash incidents are all still visible in the dmesg history for comparison). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>