<scratches head> On Thu, Apr 9, 2009 at 7:48 AM, Balaji Kannadassan <balaj...@nortel.com> wrote: > Hi All! > > When I built and openssl with -g first I noticed that it needed another > additional library libefence. Second when a malloc of size zero is done it > crashes. Hence planning to ignore -g option. So now my question is what > would the -g plays in the build ?. Since I have seen few users saying they > got only from half way on stack trace and could see the complete path debug > image. I am planning to login the stack function calls when CRYPTO_free is > called inside libcrypto. Since we are hitting the double free crash want to > find the caller. Any help on this would be great. > > Thanks in advance for your help > Balaji Kamal Kannadassan
:-S libefence needed? Well, it's probably useful in your case, but it being mandatory is new to me. ... <grep> ... ah... you're using the 'debug' target in Configure, eh? well, that's not how you might want it done (at least, that one hasn't worked here for ages; those are presets for when you know what you are doing & have a specific system.) So you want a lib with debugging included, no other changes? Here's a way to get it, while still using the autodetect features in ./config There may be easier ways to accomplish this, but this what I did when constructing my own tiny shell scripts which invoke ./Configure when I need to rerun the config/setup code (done every time after I update from CVS) First, you use the ./config script to help autodetect what your machine is to OpenSSL. Instead of running the config through, you want the ./Configure invocation here, so you add '-t' to the ./config invocation: ./config -t which just prints the Configure script invocation line (it's a perl script). Over here, the output is: ----------------------------- Operating system: x86_64-whatever-linux2 Configuring for linux-x86_64 /usr/bin/perl ./Configure linux-x86_64 --prefix=./inst zlib experimental-jpake enable-mdc2 enable-rfc3779 enable-rc5 experimental-store no-asm ----------------------------------- The next thing is track down that system (linux-x86_64) in the Configure script %table definition. Then do like the OpenSSL developers clearly did themselves: copy&paste that line and create another target that way. In my case it's the line -------------------------------- "linux-x86_64", "gcc:-m64 -DL_ENDIAN -DTERMIO -O3 -Wall -DMD32_REG_T=int::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHUNK BF_PTR2 DES_INT DES_UNROLL:${x86_64_asm}:elf:dlfcn:linux-shared:-fPIC:-m64:.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR):::64", ------------------------------------ in Configure, which' copy&pasted debug version reads (after adding -g (or -g3 for modern gcc) at the proper spot: ------------------------------------ "linux-x86_64-debug", "gcc:-g3 -m64 -DL_ENDIAN -DTERMIO -O3 -Wall -DMD32_REG_T=int::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHUNK BF_PTR2 DES_INT DES_UNROLL:${x86_64_asm}:elf:dlfcn:linux-shared:-fPIC:-m64:.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR):::64", ------------------------------------ That last line what ADDED to Configure. Save, then invoke ./Configure with any extras you want, specifying your freshly created debug target, for example: ./Configure linux-x86_64 or in my personal case it often reads: ./Configure linux-x86_64-debug --prefix=./inst zlib experimental-jpake enable-mdc2 enable-rfc3779 enable-rc5 experimental-store no-asm because I want those extra features oftentimes. No efence or other stuff added to the build requirements; just my usual target, but now with -g3 added. Warning: make sure you check the report at the top of the ./Configure output to ensure your CC/CFLAGS/etc. look like you want them to. Just as an example what might be, here's <snip> from my local dev box: ------------------------------------ Configuring for linux-x86_64-debug no-asm [option] OPENSSL_NO_ASM no-gmp [default] OPENSSL_NO_GMP (skip dir) no-krb5 [krb5-flavor not specified] OPENSSL_NO_KRB5 no-shared [default] no-zlib-dynamic [default] IsMK1MF=0 CC =gcc CFLAG =-DOPENSSL_NO_ZLIB_SHARED -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -g3 -m64 -DL_ENDIAN -DTERMIO -O3 -Wall -DMD32_REG_T=int -DOPENSSL_EXPERIMENTAL_JPAKE -DOPENSSL_EXPERIMENTAL_STORE EX_LIBS =-ldl -lz CPUID_OBJ =mem_clr.o BN_ASM =bn_asm.o DES_ENC =des_enc.o fcrypt_b.o AES_ENC =aes_core.o aes_cbc.o BF_ENC =bf_enc.o CAST_ENC =c_enc.o RC4_ENC =rc4_enc.o rc4_skey.o RC5_ENC =rc5_enc.o MD5_OBJ_ASM = SHA1_OBJ_ASM = RMD160_OBJ_ASM= CMLL_ENC= =camellia.o cmll_misc.o cmll_cbc.o PROCESSOR = RANLIB =/usr/bin/ranlib ARFLAGS = PERL =/usr/bin/perl SIXTY_FOUR_BIT_LONG mode DES_UNROLL used DES_INT used RC4_CHUNK is unsigned long BF_PTR2 used ----------------------------------- The alternative without editing Configure is './Configure linux-x86_64:gcc -g3', but that is not-so-subtly /wrong/ on my box at least, at it switches back to 32-bit build mode. Haven't taken the time to find what I've been screwing up there; the Configure edit-and-add-my-own-target-a-la-OpenSSL-devs works like a charm. Caveat: Do NOT use as-is, but review this and edit to make sure it is like the ./config / Configure invocation you regularly use yourselves. (I can imagine you don't want the experimental* nor the no-asm in there, for example.) And by the way, which made me scratch my head: malloc(0) is an illegal invocation of malloc anyhow and you should check for that (a LOT of systems will coredump on you when you do that sort of thing); see the ANSI spec, but also, for example: http://bytes.com/groups/c/508471-malloc-0-a and the answer there by Lew Pitcher. Do you have any experienced C developers near? I didn't expect the implicit wondering at the malloc(0) behaviour there - or I might have misread your mail. Too little context over long distance, but this makes me go hmmmmmmmmm if you get my drift ;-) And whatever you do to config or Configure, always watch what make does commandline-wise when invoking the compiler while building the lib. (And most importantly: check the CC= and CFLAGS= report at the top of the output when you run config or Configure: the -g / -g3 should sit in the CFLAGS there, as shown above in this email. Oh, and last but not least a bit about Net courtesy / etiquette: cross-posting is frowned upon. That is: posting to both users@ and dev@ is cross-posting. Pick one, but not both. Others may react a bit sharper and treat cross-posting as an implicit request to be plonked. (google = education) -- 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 User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org