Stephen Henson via RT -> [EMAIL PROTECTED] @ Thu, 13 Jul 2006 20:36:50 +0200
(METDST):
SHvR> Don't have that platform to test on. However from the stack dump:
SHvR> #0 0x0000000800d6e466 in memcpy () from /lib/libc.so.6
SHvR> #1 0x0000000800770a5e in asn1_ex_i2c (pval=0x61d708,
SHvR> cout=0x61d708
SHvR>
"IxMVoXDTA5MDcxMjE2MjIxMVowRDELMAkGA1UEBhMCSFUx\nETAPBgNVBAgTCEJ1ZGFwZXN0MRQwEgYDVQQKEwtHb3YtQ0EgTHRkLjEMMAoGA1UE\nAxMDY2ExMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDOfD7M8XohD/fO5Uwt\nnEB9IzrcbhUDmZ/VvV/9/ZS"...,
SHvR> putype=0x80, it=0x10) at tasn_enc.c:688
SHvR> ^^^^^^^
SHvR> That value of 'it' is obviously dodgy. Going up a level:
SHvR> #2 0x0000000800770c9d in ASN1_item_ex_i2d (pval=0x61b828,
SHvR> out=0x7fffffffc2e0,
SHvR> it=0x8008eef00, tag=4, aclass=0) at tasn_enc.c:551
SHvR> That *may* be OK.
SHvR> #3 0x0000000800771343 in asn1_template_ex_i2d (pval=0x61b828,
SHvR> out=0x7fffffffc2e0, tt=0x8008f5cc8, tag=16, iclass=128) at
SHvR> tasn_enc.c:413
SHvR> And the same here. So if you print out *tt from frame #3 and *it from
SHvR> frame #2 it should be possible to determine which bit of the structure
SHvR> it is processing.
SHvR> Assuming the whole thing isn't a compiler bug.
We have autobuilder, so now I have a slightly different dump. But it is
similar. So
(gdb) bt
#0 0x0000000800d6e466 in memcpy () from /lib/libc.so.6
#1 0x0000000800770a5e in asn1_ex_i2c (pval=0x61d709,
cout=0x61d709
"1M1oXDTA5MDcxMzE5NTg1M1owRDELMAkGA1UEBhMCSFUx\nETAPBgNVBAgTCEJ1ZGFwZXN0MRQwEgYDVQQKEwtHb3YtQ0EgTHRkLjEMMAoGA1UE\nAxMDY2ExMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC/3P3me/P8968Ok4Gr\nSb06DF9z+R+FZ3ylo3lGPGY0"...,
putype=0x80, it=0x10) at tasn_enc.c:688
#2 0x0000000800770c9d in ASN1_item_ex_i2d (pval=0x61b8a8, out=0x7fffffffc950,
it=0x8008eef00, tag=4, aclass=0) at tasn_enc.c:551
#3 0x0000000800771343 in asn1_template_ex_i2d (pval=0x61b8a8,
out=0x7fffffffc950, tt=0x8008f5cc8, tag=16, iclass=128) at tasn_enc.c:413
#4 0x0000000800770fa3 in ASN1_item_ex_i2d (pval=0x7fffffffc648,
out=0x7fffffffc950, it=0x8008f5620, tag=9395440, aclass=0)
at tasn_enc.c:249
#5 0x0000000800771250 in asn1_template_ex_i2d (pval=0x6243c0,
out=0x7fffffffc950, tt=0x8008f5620, tag=16, iclass=128) at tasn_enc.c:467
#6 0x0000000800770fa3 in ASN1_item_ex_i2d (pval=0x61b7a0, out=0x7fffffffc950,
it=0x8008f56a0, tag=9395728, aclass=0) at tasn_enc.c:249
#7 0x0000000800771312 in asn1_template_ex_i2d (pval=0x61b7a0,
out=0x7fffffffc950, tt=0x8008f5ef8, tag=16, iclass=128) at tasn_enc.c:404
#8 0x0000000800770fa3 in ASN1_item_ex_i2d (pval=0x621868, out=0x7fffffffc950,
it=0x8008f56e0, tag=9395824, aclass=0) at tasn_enc.c:249
#9 0x0000000800771343 in asn1_template_ex_i2d (pval=0x621868,
out=0x7fffffffc950, tt=0x8008f9e28, tag=16, iclass=128) at tasn_enc.c:413
#10 0x0000000800770fa3 in ASN1_item_ex_i2d (pval=0x7fffffffc910,
out=0x7fffffffc950, it=0x8008f9b20, tag=9412176, aclass=0)
at tasn_enc.c:249
#11 0x00000008007715d6 in ASN1_item_i2d (val=0x61d709, out=0x7fffffffc950,
it=0x8008f9b20) at tasn_enc.c:120
#12 0x0000000800768b07 in ASN1_i2d_bio (i2d=0x8007b0660 <i2d_TS_RESP>,
out=0x5ff280, x=0x621860 "รก\035b") at a_i2d_fp.c:99
#13 0x000000000045071c in ts_main (argc=5717248, argv=0x0) at ts.c:735
#14 0x000000000041578f in do_cmd (prog=0x573a00, argc=8, argv=0x7fffffffe0b8)
at openssl.c:389
#15 0x00000000004160ca in main (Argc=9, Argv=0x7fffffffe0b0) at openssl.c:304
(gdb) up 3
#3 0x0000000800771343 in asn1_template_ex_i2d (pval=0x61b8a8,
out=0x7fffffffc950, tt=0x8008f5cc8, tag=16, iclass=128) at tasn_enc.c:413
413 return ASN1_item_ex_i2d(pval, out, ASN1_ITEM_ptr(tt->item),
(gdb) p *tt
$1 = {flags = 0, tag = 0, offset = 40, field_name = 0x8007d0244 "enc_digest",
item = 0x8008eef00}
(gdb) down 1
#2 0x0000000800770c9d in ASN1_item_ex_i2d (pval=0x61b8a8, out=0x7fffffffc950,
it=0x8008eef00, tag=4, aclass=0) at tasn_enc.c:551
551 asn1_ex_i2c(pval, *out, &utype, it);
(gdb) p *it
$2 = {itype = 0 '\0', utype = 4, templates = 0x0, tcount = 0, funcs = 0x0,
size = 0, sname = 0x8007cef24 "ASN1_OCTET_STRING"}
We have no the same FreeBSD in 32 bit, but we have a machine with
Solaris on Sparc (SunOS sundae 5.8 Generic_108528-23 sun4u sparc
SUNW,Ultra-1) where we build and test both 32-bit and 64-bit versions.
And there we caught similar problem - on 64-bit version only:
In the same test/tsa directory:
bash-2.03$ gdb64 ../../apps/openssl core
GNU gdb 6.0
Copyright 2003 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "sparc64-sun-solaris"...
Core was generated by `../../apps/openssl ts -reply -section tsa_config1
-queryfile req1.tsq -out resp'.
Program terminated with signal 10, Bus error.
Reading symbols from ../../util/../libcrypto.so.0.9.8...done.
Loaded symbols for ../../util/../libcrypto.so.0.9.8
Reading symbols from ../../util/../libssl.so.0.9.8...done.
Loaded symbols for ../../util/../libssl.so.0.9.8
Reading symbols from /usr/lib/64/libsocket.so.1...done.
Loaded symbols for /usr/lib/64/libsocket.so.1
Reading symbols from /usr/lib/64/libnsl.so.1...done.
Loaded symbols for /usr/lib/64/libnsl.so.1
Reading symbols from /usr/lib/64/libdl.so.1...done.
Loaded symbols for /usr/lib/64/libdl.so.1
Reading symbols from /usr/lib/64/libz.so.1...done.
Loaded symbols for /usr/lib/64/libz.so.1
Reading symbols from /usr/lib/64/libc.so.1...done.
Loaded symbols for /usr/lib/64/libc.so.1
Reading symbols from /usr/local/lib/sparcv9/libgcc_s.so.1...done.
Loaded symbols for /usr/local/lib/sparcv9/libgcc_s.so.1
Reading symbols from /usr/lib/64/libmp.so.2...done.
Loaded symbols for /usr/lib/64/libmp.so.2
Reading symbols from /usr/platform/SUNW,Ultra-1/lib/sparcv9/libc_psr.so.1...
done.
Loaded symbols for /usr/platform/SUNW,Ultra-1/lib/sparcv9/libc_psr.so.1
#0 0xffffffff7f1fd4cc in EVP_PKEY_sign (ctx=0x100235ff0, sig=0x0,
siglen=0xffffffff7fffe41c, tbs=0x0, tbslen=20) at pmeth_fn.c:116
116 return ctx->pmeth->sign(ctx, sig, siglen, tbs, tbslen);
(gdb) bt
#0 0xffffffff7f1fd4cc in EVP_PKEY_sign (ctx=0x100235ff0, sig=0x0,
siglen=0xffffffff7fffe41c, tbs=0x0, tbslen=20) at pmeth_fn.c:116
#1 0xffffffff7f1fe54c in EVP_DigestSignFinal (ctx=0xffffffff7fffe430,
sigret=0x0, siglen=0xffffffff7fffe41c) at m_sigver.c:118
#2 0xffffffff7f23ed08 in PKCS7_SIGNER_INFO_sign (si=0xffffffff7f3b1b70)
at pk7_doit.c:857
(gdb) p *ctx->pmeth
$2 = {pkey_id = 6, flags = 2, init = 0xffffffff7f1d1060 <pkey_rsa_init>,
copy = 0xffffffff7f1d10e0 <pkey_rsa_copy>,
cleanup = 0xffffffff7f1d11a0 <pkey_rsa_cleanup>, paramgen_init = 0,
paramgen = 0, keygen_init = 0,
keygen = 0xffffffff7f1d1d80 <pkey_rsa_keygen>, sign_init = 0,
sign = 0xffffffff7f1d1200 <pkey_rsa_sign>, verify_init = 0,
verify = 0xffffffff7f1d15c0 <pkey_rsa_verify>, verify_recover_init = 0,
verify_recover = 0xffffffff7f1d1400 <pkey_rsa_verifyrecover>,
signctx_init = 0, signctx = 0, verifyctx_init = 0, verifyctx = 0,
encrypt_init = 0, encrypt = 0xffffffff7f1d1780 <pkey_rsa_encrypt>,
decrypt_init = 0, decrypt = 0xffffffff7f1d17e0 <pkey_rsa_decrypt>,
derive_init = 0, derive = 0, ctrl = 0xffffffff7f1d1840 <pkey_rsa_ctrl>,
ctrl_str = 0xffffffff7f1d1ae0 <pkey_rsa_ctrl_str>}
That is, I cannot understand what is the reason of segfault. And yet
another segfault I caught in another place, trying to see the first
one. In the test directory I caught
bash-2.03$ gdb64 ../apps/openssl core
GNU gdb 6.0
Copyright 2003 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "sparc64-sun-solaris"...
Core was generated by `../apps/openssl verify -CApath ../certs
../certs/RegTP-5R.pem ../certs/RegTP-6R'.
Program terminated with signal 10, Bus error.
Reading symbols from ../util/../libcrypto.so.0.9.8...done.
Loaded symbols for ../util/../libcrypto.so.0.9.8
Reading symbols from ../util/../libssl.so.0.9.8...done.
Loaded symbols for ../util/../libssl.so.0.9.8
Reading symbols from /usr/lib/64/libsocket.so.1...done.
Loaded symbols for /usr/lib/64/libsocket.so.1
Reading symbols from /usr/lib/64/libnsl.so.1...done.
Loaded symbols for /usr/lib/64/libnsl.so.1
Reading symbols from /usr/lib/64/libdl.so.1...done.
Loaded symbols for /usr/lib/64/libdl.so.1
Reading symbols from /usr/lib/64/libz.so.1...done.
Loaded symbols for /usr/lib/64/libz.so.1
Reading symbols from /usr/lib/64/libc.so.1...done.
Loaded symbols for /usr/lib/64/libc.so.1
Reading symbols from /usr/local/lib/sparcv9/libgcc_s.so.1...done.
Loaded symbols for /usr/local/lib/sparcv9/libgcc_s.so.1
Reading symbols from /usr/lib/64/libmp.so.2...done.
Loaded symbols for /usr/lib/64/libmp.so.2
Reading symbols from /usr/platform/SUNW,Ultra-1/lib/sparcv9/libc_psr.so.1...
done.
Loaded symbols for /usr/platform/SUNW,Ultra-1/lib/sparcv9/libc_psr.so.1
#0 EVP_PKEY_CTX_free (ctx=0x0) at pmeth_lib.c:292
292 if (ctx->pmeth && ctx->pmeth->cleanup)
(gdb) bt
#0 EVP_PKEY_CTX_free (ctx=0x0) at pmeth_lib.c:292
#1 0xffffffff7f1f2310 in EVP_MD_CTX_cleanup (ctx=0xffffffff7fffe710)
at digest.c:336
#2 0xffffffff7f2034a8 in ASN1_item_verify (it=0xffffffff7fffe710, a=0x4,
signature=0x1, asn=0xffffffff7f27c4a8, pkey=0x95) at a_verify.c:193
(gdb) up 1
#1 0xffffffff7f1f2310 in EVP_MD_CTX_cleanup (ctx=0xffffffff7fffe710)
at digest.c:336
336 EVP_PKEY_CTX_free(ctx->pctx);
(gdb) p *ctx
$1 = {digest = 0x1001891c0, engine = 0xffffffff7f179728, flags = 6429556872,
md_data = 0x100209520, pctx = 0x23}
(gdb) up 2
#2 0xffffffff7f2034a8 in ASN1_item_verify (it=0xffffffff7fffe710, a=0x4,
signature=0x1, asn=0xffffffff7f27c4a8, pkey=0x95) at a_verify.c:193
193 EVP_MD_CTX_cleanup(&ctx);
(gdb) p ctx
$2 = {digest = 0x0, engine = 0xffffffff7f3a8548, flags = 6428294297,
md_data = 0xffffffff7f25b748, pctx = 0x777fffde91}
Well, it would seem very like a compiler bug, but here we have a
different platform and a different gcc version - it is now 3.3.2
vs. 3.4.4 on FreeBSD. And I have an experience on gdb showing that with
optimization it cannot always print the right values. Alas, the Sun is
old and slow, and have the working place on NFS, so I cannot quickly
test the problem without optimization, like on FreeBSD, but I'll try it
tomorrow. These two platforms are the only our 64-bit machines. I have
root on the Solaris machine, but installing another version of compiler
on ancient Sparc is a challenge.
--
Artem Chuprina
RFC2822: <ran{}ran.pp.ru> Jabber: [EMAIL PROTECTED]
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [EMAIL PROTECTED]
