With OpenSSL-1.0.1c downloaded from openssl.org and compiled from source
on x86 Linux 2.6 (LinuxMint 12) using gcc-4.6.1, I get an abort with
following error

int_thread_release, bad reference count

Analyzing situation...

(gdb) bt
#0  0x00920416 in __kernel_vsyscall ()
#1  0x0037ac8f in raise () from /lib/i386-linux-gnu/libc.so.6
#2  0x0037e2b5 in abort () from /lib/i386-linux-gnu/libc.so.6
#3  0x0020efae in int_thread_release (hash=0x42a4e18) at err.c:479
#4  0x0020f059 in int_thread_get_item (d=0x42a4e4c) at err.c:499
#5  0x002100de in ERR_get_state () at err.c:1014
#6  0x0020f9ff in get_error_values (inc=1, top=0, file=0x42a50b4, 
    line=0x42a50c0, data=0x42a50b8, flags=0x42a50bc) at err.c:798
#7  0x0020f88f in ERR_get_error_line_data (file=0x42a50b4, line=0x42a50c0, 
    data=0x42a50b8, flags=0x42a50bc) at err.c:766
#8  0x0808b3ca in zx_report_openssl_err (logkey=0x8142e19 "SSL again read")
    at zxsig.c:399
#9  0x08062d2e in hi_read (hit=0x42a5370, io=0xb67d8f44) at hiread.c:175
#10 0x08055245 in hi_in_out (hit=0x42a5370, io=0xb67d8f44) at hiios.c:294
#11 0x08056fa6 in hi_shuffle (hit=0x42a5370, shf=0x93b1d28) at hiios.c:348
#12 0x0804fdbf in thread_loop (_shf=0x93b1d28) at zxbusd.c:564
#13 0x007eed31 in start_thread () from /lib/i386-linux-gnu/libpthread.so.0
#14 0x0042046e in clone () from /lib/i386-linux-gnu/libc.so.6
Backtrace stopped: Not enough registers or memory available to unwind further
(gdb) 

This is statistically reproducible, i.e. it does not happen every time,
but seems to happen about 20% of the time with 10 worker threads. With
one or two threads I have not seen it happen.

I am somewhat at loss about what would be the best way to debug this
or what would be the most useful input to give for you to debug it.

Peculiarities of my situation

1. I use nonblocking I/O with epoll(2) based I/O loop

2. I use late accept approach, calling SSL_set_accept_state(io->ssl)
   at accept time and relying on SSL_read() to do the rest, i.e.
   I never call SSL_accept().

3. I have multiple worker threads synchronized such that one thread
   may be reading while other is writing, but never two threads
   simultaneously reading or simultaneously writing. At accept time
   there is no data on write queue so in reality only the read thread
   will happen (I realize that in the bowels of SSL_read() a write(2)
   system call may actually be made, but I do not think there is
   any other intefering thread at this time).

4. I have multiple SSL connections, sharing SSL_CTX, i.e. the SSL_CTX
   has multithreaded access.

5. I suspect the problem happens during accept processing as no data
   seems to come through the connection.

6. This is somewhat of a Heisenbug as turning on debug prints,
   such as SSL_CTX_set_info_callback() that would allow me to
   see if it is in accept processing, makes the bug go away.

The openssl was configured and compiled as follows:

"sampo-debug-linux-pentium",         "gcc:-DREF_CHECK -DCONF_DEBUG -DL_ENDIAN 
-DTERMIO -g -march=pentium  -Wall::-D_REENTRANT::-ldl:BN_LLONG ${x86_gcc_des} 
${x86_gcc_opts}:${x86_elf_asm}:dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",

PATH=/usr/bin:/bin ./Configure --prefix=/apps/openssl/1.0.1c-gcc-4.6.1-debug 
enable-rc5 enable-mdc2 no-dso no-hw no-engine zlib sampo-debug-linux-pentium
PATH=/usr/bin:/bin make install

Then when I compile my own code I get following link error

/usr/bin/cc  -o zxid zxid.o -L. -lzxid -L/apps/openssl/std/lib -L/apps/lib 
-pthread -lpthread -L/apps/lib -L/apps/openssl/std/lib -lcurl -lssl -lcrypto -lz
/usr/bin/ld: warning: type and size of dynamic symbol `DES_SPtrans' are not 
defined
/usr/bin/ld: dynamic variable `DES_SPtrans' is zero size
/usr/bin/ld: /apps/openssl/std/lib/libcrypto.a(crypt586.o)(.text+0xa): 
unresolvable R_386_32 relocation against symbol `DES_SPtrans'
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: ld returned 1 exit status
make: *** [zxid] Error 1

Seems DES_SPtrans is referenced in des/crypt586.s and defined in des-586.s
Moving definition of fcrypt_body from crypt586.s to des-586.s seems to
solve the problem, though I doubt this is the right fix.

Perhaps the pentium assembly code has not been tested/used in ages?

Cheers,
--Sampo
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@openssl.org
Automated List Manager                           majord...@openssl.org

Reply via email to