pclose() is related to pipes (popen/pclose). OpenSSL itself doesn't use pipes, so this must be an issue in some user code.
And if I read that backtrace in the correct direction, then some call to pclose() call the libc internal _IO_proc_close(), which... in your case calls CRYPTO_free() ???????? Either gdb has gone totally ape shit or you've been doing some _very_ interesting things to the libc source code. ;-) A quick google (you made me wonder) delivers several implementations of _IO_proc_close() code, all of whom have two theoretical ways to push another call on the stack: _IO_close() and _IO_waitpid() (my expectation is that _IO_fileno() is a macro). _IO_close() is a candidate for calling heap free() somewhere in there, but that should _never_ rise from these depths like the Great White in Jaws to end up in CRYPTO_free(): the latter is an upper layer wrapper API, not a libc-or-deeper core method! Anyway, the short and long version of this is: none of those would/should end up at CRYPTO_free(), as _that_ method would be located in a layer ABOVE libc: it's a OPENSSL_wrapper around your choice of malloc/free plus a few extras, so how that one comes to be the next on the call stack is a true wonder. _I_ would suspect my own code and since this yaks about a pclose() my first question to the team would be: what have we got on pipes in our project? And see if you can put some diagnostics around it. A parallel process would be to check if your project assigns custom malloc/free handlers, and/or special debug hooks for OpenSSL memory allocation API ( CRYPTO_set_mem_debug_functions() / CRYPTO_set_mem_functions() ) While you're at it, you might want to register a debug_free hook function which pops up in your debugger (by forcibly invoking the debugger, for example by causing a hardware exception (division by zero, null memory reference, anything goes) And while you're at it, and assuming you're in a multithreaded app, check whether the OpenSSL thread lock hooks are done properly, just to cover all the bases. If it is indeed CRYPTO_free() in there as an active participant in your call stack at that depth, it sure as Hell means some libc function pointers or other libc internal references have been shot to kingdom come. My bet is some part of your software has gone totally bonkers. With OpenSSL being part of the collateral. On Tue, Mar 17, 2009 at 8:02 AM, Balaji Kannadassan <balaj...@nortel.com> wrote: > Hi All! > > We are facing a crash as below. We are clueless on why is it happening. > btw the tracebacks are partial in certain instances. Any help on how to > trouble shoot the same would be ver much helpful. > > Thanks > Balaji Kamal Kannadassan > > > Core 1 > ---------- > (gdb) bt > #0 0x4021e76e in pclose () from /lib/libc.so.6 > #1 0x4021e548 in _IO_proc_close () from /lib/libc.so.6 > #2 0x400b4772 in CRYPTO_free (str=0x0) at mem.c:380 > (gdb) > > Core 2: > ---------- > Loaded symbols for /lib/libnss_files.so.2 > #0 0x4021e76e in pclose () from /lib/libc.so.6 > (gdb) bt > #0 0x4021e76e in pclose () from /lib/libc.so.6 > #1 0x4021e548 in _IO_proc_close () from /lib/libc.so.6 > (gdb) -- Met vriendelijke groeten / Best regards, Ger Hobbelt -------------------------------------------------- web: http://www.hobbelt.com/ http://www.hebbut.net/ mail: g...@hobbelt.com mobile: +31-6-11 120 978 -------------------------------------------------- ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
