stunnel segfaulting on connection with 4.10
Hello having a problem with stunnel sigsegv'ing on a machine answers to list questions below: 1. https to/from IPs bound on same machine the contents of my config file: cert = /usr/local/etc/poundcert.pem foreground = yes [poundssl] connect = xx.xx.xx.xx:80 accept = xx.xx.xx.xx:443 foreground option because I was debugging, does it with or without this option. 2. 4.10 3. standalone, /usr/local/sbin/stunnel /usr/local/etc/stunnel.cfg 4. -D and -f aren't flags in version I am using apparently. assume -D 7 is debug level debug (7) I'll add the log from a single session, all I am doing is connecting from a mozilla client and it instantly segfaults: # /usr/local/sbin/stunnel /usr/local/etc/stunnel.cfg 2005.06.15 10:02:21 LOG5[1245:1]: stunnel 4.10 on i686-pc-linux-gnu UCONTEXT+POLL+IPv4+LIBWRAP with OpenSSL 0.9.7g 11 Apr 2005 2005.06.15 10:02:21 LOG7[1245:1]: Snagged 64 random bytes from /root/.rnd 2005.06.15 10:02:21 LOG7[1245:1]: Wrote 1024 new random bytes to /root/.rnd 2005.06.15 10:02:21 LOG7[1245:1]: RAND_status claims sufficient entropy for the PRNG 2005.06.15 10:02:21 LOG6[1245:1]: PRNG seeded successfully 2005.06.15 10:02:21 LOG7[1245:1]: Certificate: /usr/local/etc/poundcert.pem 2005.06.15 10:02:21 LOG7[1245:1]: Key file: /usr/local/etc/poundcert.pem 2005.06.15 10:02:21 LOG6[1245:1]: file ulimit = 1024 (can be changed with 'ulimit -n') 2005.06.15 10:02:21 LOG6[1245:1]: poll() used - no FD_SETSIZE limit for file descriptors 2005.06.15 10:02:21 LOG5[1245:1]: 500 clients allowed 2005.06.15 10:02:21 LOG7[1245:1]: FD 3 in non-blocking mode 2005.06.15 10:02:21 LOG7[1245:1]: FD 4 in non-blocking mode 2005.06.15 10:02:21 LOG7[1245:1]: FD 5 in non-blocking mode 2005.06.15 10:02:21 LOG7[1245:1]: SO_REUSEADDR option set on accept socket 2005.06.15 10:02:21 LOG7[1245:1]: poundssl bound to xx.xx.xx.xx:443 2005.06.15 10:02:21 LOG7[1245:1]: Created pid file /usr/local/var/run/stunnel.pid 2005.06.15 10:02:21 LOG7[1245:0]: Waiting -1 second(s) for 2 file descriptor(s) 2005.06.15 10:02:39 LOG7[1245:0]: CONTEXT 1, FD=3, (IN)->() 2005.06.15 10:02:39 LOG7[1245:0]: CONTEXT 1, FD=5, (IN)->(IN) 2005.06.15 10:02:39 LOG7[1245:1]: poundssl accepted FD=6 from xx.xx.xx.xx:3939 2005.06.15 10:02:39 LOG7[1245:1]: Creating a new context 2005.06.15 10:02:39 LOG7[1245:1]: Context 2 created Segmentation fault 5. /usr/local/sbin/stunnel -version stunnel 4.10 on i686-pc-linux-gnu UCONTEXT+POLL+IPv4+LIBWRAP with OpenSSL 0.9.7g 11 Apr 2005 Global options cert = /usr/local/etc/stunnel/stunnel.pem ciphers = ALL:!ADH:+RC4:@STRENGTH debug = 5 key = /usr/local/etc/stunnel/stunnel.pem pid = /usr/local/var/run/stunnel.pid RNDbytes = 64 RNDfile = /dev/urandom RNDoverwrite = yes session = 300 seconds verify = none Service-level options TIMEOUTbusy = 300 seconds TIMEOUTclose = 60 seconds TIMEOUTconnect = 10 seconds TIMEOUTidle = 43200 seconds 6. uname -a Linux hsc14 2.4.27 #1 SMP Fri Feb 11 09:13:33 EST 2005 i686 i686 i386 GNU/Linux 7. # /lib/libc.so.6 GNU C Library stable release version 2.3.2, by Roland McGrath et al. Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled by GNU CC version 3.2.2 20030222 (Red Hat Linux 3.2.2-5). Compiled on a Linux 2.4.20 system on 2003-02-27. Available extensions: GNU libio by Per Bothner crypt add-on version 2.1 by Michael Glad and others linuxthreads-0.10 by Xavier Leroy BIND-8.2.3-T5B libthread_db work sponsored by Alpha Processor Inc NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk Thread-local storage support included. 8.]# gcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --host=i386-redhat-linux Thread model: posix gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5) 9. ok maybe this is a problem? # ]# openssl version OpenSSL 0.9.7a Feb 19 2003 but: [root@hsc14 etc]# grep "OpenSSL 0.9.7a" /usr/local/sbin/stunnel [root@hsc14 etc]# grep "OpenSSL 0.9.7g" /usr/local/sbin/stunnel Binary file /usr/local/sbin/stunnel matches which -a openssl only shows one binary and it's that old one. additionally here is the output of gdb: [root@hsc14 etc]# gdb /usr/local/sbin/stunnel GNU gdb Red Hat Linux (5.3post-0.20021129.18rh) 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 "i386-redhat-linux-gnu"... (gdb) set arg /usr/local/etc/stunnel.cfg (gdb) run Starting program: /usr/local/sbin/stunnel /usr/local/etc/stunnel.cfg [New Thread 16384 (LWP 20866)] 2005.06.15 09:44:11 LOG5[20866:1]: stunnel 4.10 on i686-pc-linux-gnu UCONTEXT+PO LL+IPv4+LIBWRAP with OpenSSL 0.9.7g 11 Apr 2005 2005.06.15 09:44:11 LOG5[20866:1]: 500 clients allowed Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 20866)] 0x40026f0c in __pthread_internal_tsd_get () from /lib/libpthread.so.0 (gdb) bt #0 0x40026f0c in __pthread_internal_tsd_get () from /lib/libpthread.so.0 #1 0x40105edd in malloc () from /lib/libc.so.6 #2 0x400f59e3 in __fopen_internal () from /lib/libc.so.6 #3 0x400f5aae in fopen@@GLIBC_2.1 () from /lib/libc.so.6 #4 0x4008c28b in hosts_access () from /usr/lib/libwrap.so.0 #5 0x4008c207 in hosts_access () from /usr/lib/libwrap.so.0 #6 0x0804b9d9 in auth_libwrap (c=0x4009225c) at client.c:706 #7 0x0804a535 in init_local (c=0x811d638) at client.c:196 #8 0x0804a3b1 in do_client (c=0x811d638) at client.c:143 #9 0x0804a338 in client (arg=0x811d638) at client.c:120 #10 0x400d84b4 in __makecontext () from /lib/libc.so.6 any help is much appreciated. let me know if you need any more information. Thank you, brian
On 2005-06-15, at 16:13, brianmas@highstream.net wrote:
0x40026f0c in __pthread_internal_tsd_get () from /lib/libpthread.so.0
Yes! I think I found a way to solve Linux coredumps (including my UML problem). Here is the how to build 4.10: 1. Configure stunnel with "./configure" (with usual options). 2. Edit src/Makefile, search for "-lpthread" and remove it. 3. Build stunnel with "make". It looks like ucontext can't be safely used together with /lib/libpthread.so.0 library. I'll release fixed stunnel 4.11 in a week or so. Best regards, Mike
On 2005-06-15, at 16:13, brianmas@highstream.net wrote:
0x40026f0c in __pthread_internal_tsd_get () from /lib/libpthread.so.0
Yes! I think I found a way to solve Linux coredumps (including my UML problem).
Here is the how to build 4.10: 1. Configure stunnel with "./configure" (with usual options). 2. Edit src/Makefile, search for "-lpthread" and remove it. 3. Build stunnel with "make".
It looks like ucontext can't be safely used together with /lib/libpthread.so.0 library.
Think this might be the fix for FreeBSD too? Thanks, Tuc
On 2005-06-15, at 17:03, Tuc at T-B-O-H wrote:
Think this might be the fix for FreeBSD too?
Is there any FreeBSD problem that is not fixed with ftp://stunnel.mirt.net/stunnel/bsd.patch ?
Already compiled in. They are also making changes in client.c : --- src/client.c.orig Thu May 12 14:01:28 2005 +++ src/client.c Thu May 12 14:04:19 2005 @@ -841,6 +841,14 @@ sigemptyset(&newmask); sigprocmask(SIG_SETMASK, &newmask, NULL); #endif + if (c->opt->execargs != NULL && c->opt->execargs[0] == NULL) { + free(c->opt->execargs); + c->opt->execargs = NULL; + } + if (c->opt->execargs == NULL) { + c->opt->execargs = calloc(2, sizeof(c->opt->execargs[0])); + c->opt->execargs[0] = c->opt->execname; + } execvp(c->opt->execname, c->opt->execargs); ioerror(c->opt->execname); /* execv failed */ _exit(1); and looks like a few in common.h : --- src/common.h.orig Sat Apr 23 13:40:10 2005 +++ src/common.h Tue Jun 14 08:27:11 2005 @@ -38,17 +38,44 @@ #endif /* threads model */ +#if defined(FORCE_THREADING_MODEL) + +#undef USE_UCONTEXT +#undef USE_PTHREAD +#undef USE_FORK + +#ifdef FORCE_UCONTEXT +#define USE_UCONTEXT +#else +#ifdef FORCE_PTHREAD +#define USE_PTHREAD +#else +#define USE_FORK +#endif /* FORCE_PTHREAD */ +#endif /* FORCE_UCONTEXT */ + +#else /* FORCE_THREADING_MODEL */ + #if HAVE_UCONTEXT_H && HAVE_GETCONTEXT && HAVE_POLL #define USE_UCONTEXT -#include <ucontext.h> #elif HAVE_PTHREAD_H && HAVE_LIBPTHREAD #define USE_PTHREAD +#else +#define USE_FORK +#endif + +#endif /* FORCE_THREADING_MODEL */ + +#ifdef USE_UCONTEXT +#include <sys/types.h> +#include <ucontext.h> +#endif + +#ifdef USE_PTHREAD #include <pthread.h> #define THREADS #define _REENTRANT #define _THREAD_SAFE -#else -#define USE_FORK #endif /* TCP wrapper */ And something tiny in ssl.c : --- src/ssl.c.orig Mon Dec 27 13:47:16 2004 +++ src/ssl.c Mon Dec 27 13:50:36 2004 @@ -116,6 +116,8 @@ static void init_engine(void) { ENGINE *e; + s_log(LOG_ERR, "This version of stunnel was compiled WITHOUT support for Op enSSL hardware engines! If you need this functionality, rebuild the FreeBSD por t with the WITH_STUNNEL_SSL_ENGINE option set to 'yes'; contact Peter Pentchev < roam@FreeBSD.org> for details."); + exit(1); ENGINE_load_builtin_engines(); if(!strcasecmp(options.engine, "auto")) { s_log(LOG_DEBUG, "Enabling auto engine support"); Thanks, Tuc
Quoting Michal Trojnara <Michal.Trojnara@mirt.net>:
On 2005-06-15, at 16:13, brianmas@highstream.net wrote:
0x40026f0c in __pthread_internal_tsd_get () from /lib/libpthread.so.0
Yes! I think I found a way to solve Linux coredumps (including my UML problem).
Here is the how to build 4.10: 1. Configure stunnel with "./configure" (with usual options). 2. Edit src/Makefile, search for "-lpthread" and remove it. 3. Build stunnel with "make".
It looks like ucontext can't be safely used together with /lib/libpthread.so.0 library.
I'll release fixed stunnel 4.11 in a week or so.
ok this works, I have to ask what does not linking with pthread imply exactly though! Thank you, brian
participants (3)
-
brianmas＠highstream.net -
Michal Trojnara -
Tuc＠T-B-O-H