> From: owner-openssl-us...@openssl.org On Behalf Of Josue Andrade Gomes > Sent: Tuesday, 03 November, 2009 07:13
> On Thu, Oct 29, 2009 at 11:42 PM, Dave Thompson > <dave.thomp...@princetonpayments.com> wrote: > > 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 > That last part must be bogus, as the warning suggests. CRYPTO_get_lock_name doesn't call malloc (at all), CRYPTO_malloc doesn't call CRYPTO_get_lock_name, and SSLv3_client_method can't possibly be that large -- as I suggested before, this is probably a location in a part of your program that doesn't have symbols, or if the location the debugger is decoding is itself bogus, it could be outside your program area entirely. > 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. The top part of the traceback (above the warning) does look reasonable for heap corruption. Apparently SOMETHING is calling malloc and triggering the fault, but the above information gives us no idea what. > 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. > I believe at least some browsers do use sessIDs at least 'normally', but you'd need to verify specific cases. One possible inhibitor: if you support 1.1 (as at least most browsers do) and your users do only short interactions, they might get everything in one https session, and not *need* resumption. > > If not you can use openssl s_client to create a test situation. > > "openssl s_client" works fine. > To be clear: s_client with -sessout to a file, followed by s_client with -sessin from the same file (to the same server instance) works? And -sessin to a different server instance is ignored but doesn't fault? Also, it shouldn't make a difference, but with bizarre problems like this you never really know: have your test client (s_client) use the same requested-cipherlist as the problematic client or at least request the first cipher in that list that your server will (is configured and enabled to) accept. > 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
