On 10/20/2011 05:01 PM, Phil Mayers wrote:
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)
Having gone for a run and thought about this en-route, I'm sure this must be the cause. Alex of course doesn't see it because he's not running c145c7dabbd4 in which the "free" occurs (why he's not seeing the memory leak I don't know - maybe *that* is load-related) Quite how we solve it I don't know... I'm going to (shudder) look at the OpenSSL source to see if it does any locking around session objects; I just don't see from the API how you can used the get/set_ex_data functions safely in a threaded environment!