> From: owner-openssl-us...@openssl.org On Behalf Of Josue Andrade Gomes > Sent: Thursday, 29 October, 2009 14:23
> Shortly: HP Insight Manager (a management tool) crashes my server SSL > application. > Operating system: Windows 2003 Server > OpenSSL version: 0.9.8k > Post-mortem debugger points the crash ocurring in a call to > CRYPTO_malloc() inside SSLv3_client_method() > (wich is weird since I never call this function). > Even if you did, it doesn't allocate anything; it just returns some static data that is later used to dispatch other calls. I'd bet the traceback is wrong, which has two common causes: - the stack and/or regs is clobbered so the trace values are bogus - you're not using the same executable (and symbols if separate) as was running, so the debugger decodes it wrongly (note that a rebuild, even from exact same source, might not be good enough) Check the latter first. If you (can) run the program (here server) under an interactive (not postmortem) debugger (and get the fault), you can usually be sure it's using the right executable. Another possibility is that it faulted in code for which symbols are missing, and these happened to be the closest available ones (or if the debugger is really confused, just some available ones). Does your debugger show symbol+offset and is the offset(s) large? Can you get absolute numbers instead and compare them to your link map or equivalent to see if they are really in the routines? A final possibility is that you (or whoever) compiled with gcc with -fomit-frame-pointer (the default config on at least many platforms) or something analogous on another compiler, and the resulting not-fully-materialized stack(s) confused the debugger. But in my experience this usually gives incomplete tracebacks with missing entries, not wholly absurd ones. > The packet that causes the crash: <snip> > Secure Socket Layer > SSL Record Layer: Handshake Protocol: Client Hello <snip> > Session ID Length: 32 > Session ID: > D2D7B8577F842D69A074F3F90ABD2AE9BF979E78DB2E6631... I see it is specifying sessID. If the server is crashing and being restarted presumably any internal cache is lost; do you have/configure an external cache? If so is it valid, and your callback to fetch from it correct? I see you later say other clients do work. Do they (does any of them) resume sessIDs? If not you can use openssl s_client to create a test situation. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
