On 10/20/2011 04:26 PM, Alan DeKok wrote:
Phil Mayers wrote:
It's segfaulted a couple of times since then. The most recent occurrence was inside the "detail" module we run in post-auth, and I was able to examine the reply VPs - sure enough, the first VP in the list was a corrupted version of the Cached-Session-Reply VP; the ->next pointer and all the rest of the VPs were intact, but that one VP had corrupted payload, and an absurd length.
Weird stuff...
I put in a hack to set the cached VPs to NULL when the session is free'd. Maybe that will help.
I saw; I was about to apply it and re-build our package, when I had an awful thought... Is it possible that the following sequence of events is occurring: 1. thread #1: client does session resumption a split second before expiry, gets cached VPs 2. thread #1: blocks (e.g. doing SQL) 3. thread #2: receives new TLS session, calls SSL_CTX_flush_sessions 4. thread #2: calls pairfree() on VPs from session 1, now expired 5. thread #1: resumes - boom It might explain why it happens very rarely, and why we see it but Alex doesn't (load-related - Imperial has a few more students that SOAS IIRC)