Hi Sander,
yep the order is correct - the thread callbacks (pthread) init function
is before the Engine initialization (which happens before the spawning
of the threads).
The error you are describing sounds definitely familiar - although my
magic number is 12 (if I use 13 threads then... crash...). The backtrace
is not really useful as well - unless you have the source code:
0xb7fe5410 in ?? ()
(gdb) backtrace
#0 0xb7fe5410 in ?? ()
#1 0xb5a3e3f8 in ?? ()
#2 0x00000006 in ?? ()
#3 0x000027a0 in ?? ()
#4 0xb7cd8811 in raise () from /lib/tls/i686/cmov/libc.so.6
#5 0xb7cd9fb9 in abort () from /lib/tls/i686/cmov/libc.so.6
#6 0xb7cd1fbf in __assert_fail () from /lib/tls/i686/cmov/libc.so.6
#7 0xb7adbada in receive (conn=0x8086380, cctx=0xb5a3ebf0, replyp=0xb5a3e86c,
tctx_r=0x0, nonblocking=0, functionname=0xb7b41ce0 "Wait")
at ../client.c:945
#8 0xb7adc3eb in NFastApp_Wait (conn=0x8086380, cctx=0xb5a3ebf0, replyp=0x0,
tctx_r=0x0) at ../client.c:982
#9 0xb7adaa1b in NFastApp_Transact (conn=0x8086380, cctx=0xb5a3ebf0,
command=0x0, reply=0xb5a3e9e0, tctx=0x0) at ../client.c:211
#10 0xb7ab40e9 in nfast_hwch_command (upc=0xb5a3ebf0, conn=0x0, remember=0,
command=0xb5a3eaa0, reply=0xb5a3e9e0, status_r=0x0, ebuf=0x0, ebuflen=0)
at ../command.c:15
#11 0xb7ab42a1 in nfast_hwch_command_chk (upc=0xb5a3ebf0, conn=0x0,
remember=0, command=0x0, reply=0x0, what=0x0) at ../command.c:59
#12 0xb7aaf338 in nfast_hwch_raw_rsa (upc=0xb5a3ebf0, conn=0x0, remember=0,
key=0, msg=
{buf = 0x808ba68 "\210E\032��\234�6�ED*\220�h��2Bʸ\217", size = 128},
result=0x0) at ../keys.c:260
#13 0xb7aaf214 in HWCryptoHook_RSA (msg=
{buf = 0x808ba68 "\210E\032��\234�6�ED*\220�h��2Bʸ\217", size = 128},
k=0x806c858, result=0x0, errors=0xb5a3f0c0) at ../keys.c:260
#14 0xb7b7bc1f in bind_engine () from /usr/lib/ssl/engines/libchil.so
#15 0xb7ee7736 in RSA_PKCS1_SSLeay ()
from /usr/lib/i686/cmov/libcrypto.so.0.9.8
#16 0x0808bf10 in ?? ()
#17 0x0808bee8 in ?? ()
#18 0x08072078 in ?? ()
#19 0x0808be30 in ?? ()
#20 0xce86bb62 in ?? ()
#21 0x03d508e8 in ?? ()
#22 0x00000021 in ?? ()
#23 0xb7f8d830 in ?? () from /usr/lib/i686/cmov/libcrypto.so.0.9.8
#24 0xb7f7c048 in CAST_S_table7 () from /usr/lib/i686/cmov/libcrypto.so.0.9.8
#25 0x00000080 in ?? ()
#26 0x0808bee8 in ?? ()
#27 0x0808bf10 in ?? ()
#28 0x0808befc in ?? ()
#29 0x0807eed8 in ?? ()
#30 0x08085558 in ?? ()
#31 0x00000010 in ?? ()
#32 0x00000000 in ?? ()
Any Idea ???
Later,
Max
Sander Temme wrote:
On Nov 19, 2008, at 11:24 PM, Max Pala wrote:
The software that I am writing is a multi-threaded OCSP responder.
Please make sure you initialize the engine correctly, and set up your
locking callbacks before you actually initialize the engine. If you
look at Apache:
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_engine_init.c?view=markup
the invocation of ssl_init_Engine() and ssl_util_thread_setup() used to
be in the wrong order, which led to Apache children crashing on an
assert() from within the Hardware Crypto Hook library (libnfhwcrhk)
whenever more than five threads were used. Sounds familiar?
If that is all in order, perhaps you can trap that assert() in gdb and
take a backtrace.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
