> From: owner-openssl-us...@openssl.org On Behalf Of Michael D > Sent: Wednesday, 30 September, 2009 17:58
> I don't mind digging in and trying to figure out why the crash.. > but could somebody point me in the right direction? > Thanks, > Mike > > CONNECTED(00000003) > depth=0 > /C=US/ST=Minnesota/L=Tonka/O=IWP/OU=t1/CN=Mike/emailAddress=mm > m...@go.metrstate.edu > verify error:num=18:self signed certificate > verify return:1 > depth=0 > /C=US/ST=Minnesota/L=Tonka/O=IWP/OU=t1/CN=Mike/emailAddress=mm > m...@go.metrstate.edu > verify return:1 > *** glibc detected *** > /home/mike/openssl-1.0.0-stable-SNAP-20090821/apps/openssl: > double free or corruption (!prev): 0x09c64410 *** > ======= Backtrace: ========= > /lib/i686/cmov/libc.so.6[0xb7ea1624] > /lib/i686/cmov/libc.so.6(cfree+0x96)[0xb7ea3826] > /home/mike/openssl-1.0.0-stable-SNAP-20090821/apps/openssl[0x80c5365] > ======= Memory map: ======== <snip> (Confirmed in later message this is s_client, as it appears.) Okay, something's clobbering memory. You've apparently hit a bug. I don't run snapshots. Unless you need bleeding-edge, I'd suggest backing off to (at least) beta3. I'm sure even betas get more testing and more widespread use than snapshots. FWIW beta3 runs without fault for this case on the one (oldish) Linux box easily available to me, though that's far from a complete test. I find it suspicious that you get no more backtrace than that. Perhaps the stack is getting clobbered as well, maybe even first. But it could be an unusually bad case of omit-frameptr, see next. And apparently you don't have symbols in your executable; to debug you almost always need them. On Linux assuming gcc, I just shove -g in CFLAG in the top Makefile by hand, and to simplify debug I would also take out optimization options (-O3 -fomit-frame-pointer) if the problem occurs without them. There's probably a way to get Configure to do these officially, but for me it isn't worth the trouble of figuring out. Did you run s_client with -msg? If so: the *symptom* apparently happens soon after verify_callback (used by s_client and also s_server) returns, so I would set a breakpoint there, make sure the (whole) stack looks valid and if so start stepping forward, and if not try to find an earlier time where it is. Unfortunately the openssl cert-verify code is a maze of twisty little passages that always drives me nuts; fortunately once an 'error' has been hit as here it should exit out quickly, back into protocol logic which is relatively straightforward. If not: use -msg to see if/which other protocol steps did occur before the fault; if none, proceed as above; if any, break on the last apparently good step, verify its stack is (fully) plausible, and step forward similarly. Remember that with C memory clobbers, the actual cause may be long before the symptom. If you find the line that faults using data that should be valid but isn't, that data may have been clobbered quite some time before. Or have been correctly derived (computed, fetched etc.) from other data that was clobbered earlier yet. Yes this is a pain. When the stack is suspect, as here, everytime you step out say from foo() to alleged-bar(), check you're in or just after a line in bar() which calls foo() -- or with the many macros in OpenSSL, invokes something that reasonably could be an alias for foo(). If not, you've already jumped wild and you're past the problem, and anything from here forward will just be chaos. Good luck. You may need it. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
