On Thu, Oct 29, 2009 at 11:42 PM, Dave Thompson <dave.thomp...@princetonpayments.com> wrote:
Thanks for your help. > I'd bet the traceback is wrong. Indeed a detailed analysis by the debugger show: ntdll!KiFastSystemCallRet kernel32!UnhandledExceptionFilter+0x7c0 kernel32!BaseThreadStart+0x4a kernel32!_except_handler3+0x61 ntdll!ExecuteHandler2+0x26 ntdll!ExecuteHandler+0x24 ntdll!KiUserExceptionDispatcher+0xe ntdll!RtlAllocateHeap+0x675 msvcr80!malloc+0x7a WARNING: Stack unwind information not available. Following frames may be wrong. libeay32!CRYPTO_get_lock_name+0x5b libeay32!CRYPTO_malloc+0x42 ssleay32!SSLv3_client_method+0x45a5 I have to custom the build of OpenSSL DLLs to generate the symbols. The crash occurs due to a 'heap corruption' exception (a feature of Windows runtime) and the origin is a call to a memory allocation system call. I'm customizing OpenSSL DLLs makefiles to generate the correct symbols. > 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? No. > I see you later say other clients do work. Do they > (does any of them) resume sessIDs? I don't really now. This is a webserver and it works with any mainstream web browser. > If not you can use openssl s_client to create a test situation. "openssl s_client" works fine. I'm still investigating and I'll put my findings here. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
