On Wed, Mar 18, 2009 at 11:29 AM, <stefan.n...@t-online.de> wrote: > Hi, > >> > 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) > >> And if I read that backtrace in the correct direction, > > Sorry to interrupt, but no, you didn't read it in the correct > direction. It's pclose being called by _IO_proc_close which in > turn was called by CRYPTO_free...
Yes, I see that now. Thanks for correcting my assumptions! This implies (assuming a 'good' stacktrace) they've very probably hooked some pipe-based debug hook functions into CRYPTO_free() (one can do that sort of thing), but that's 'advanced usage' and should immediately have led internally to a 'hm, let's check our debug tracing/logging code hooks, eh?' sort of response. Ah well... > Either that or a completely corrupted stack or heap, in which case > something like valgrind or purify is probably going to be helpful in > finding the _real_ problem. Yup. (Reading that stacktrace this way, I'd say it's a plausible trace, which means the error is in an unmatched popen/pclose pair in some user debug code - which is a good case for using purify to help dig this one out - or does valgrind check handles as well these days? The bit that's makes it extra 'hmmm' is no stacktrace beyond the CRYPO_free() invocation.) -- 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
