<scratches head>
On Thu, Apr 9, 2009 at 7:48 AM, Balaji Kannadassan <[email protected]> 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: [email protected]
mobile: +31-6-11 120 978
--------------------------------------------------
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [email protected]
Automated List Manager [email protected]
