Re: Segfault in libthr.so on 9.0-BETA2 (with stunnel FWIW)
On Wed, Sep 14, 2011 at 11:04:56PM +0300, Kostik Belousov wrote:
tzload() allocates ~80KB for the local variables. The backtrace you provided
shows the nested call to tzload(), so there is total 160KB of the stack
space consumed.
By default, stack for the amd64 thread is 4MB, that should be plenty. This
is not the case for ezm3. Possibly, stunnel also reduces the size of the
thread stack.
Please, try the patch below. I did not tested it, only compiled. I see
that now tzload allocates only ~300 bytes on the stack.
80KB seems quite a lot indeed, good to bring it down.
diff --git a/contrib/tzcode/stdtime/localtime.c
b/contrib/tzcode/stdtime/localtime.c
index 80b70ac..55d55e0 100644
--- a/contrib/tzcode/stdtime/localtime.c
+++ b/contrib/tzcode/stdtime/localtime.c
[snip]
@@ -406,16 +409,24 @@ register const int doextend;
** to hold the longest file name string that the implementation
** guarantees can be opened.
*/
- charfullname[FILENAME_MAX + 1];
+ char*fullname;
+
+ fullname = malloc(FILENAME_MAX + 1);
+ if (fullname == NULL)
+ goto out;
if (name[0] == ':')
++name;
doaccess = name[0] == '/';
if (!doaccess) {
- if ((p = TZDIR) == NULL)
+ if ((p = TZDIR) == NULL) {
+ free(fullname);
return -1;
- if ((strlen(p) + 1 + strlen(name) + 1) = sizeof
fullname)
+ }
+ if ((strlen(p) + 1 + strlen(name) + 1) = sizeof
fullname) {
This sizeof is now the sizeof of a pointer. The comparison should be
against FILENAME_MAX + 1 instead.
Alternatively, the name could be created using asprintf().
--
Jilles Tjoelker
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Segfault in libthr.so on 9.0-BETA2 (with stunnel FWIW)
On Sun, Sep 18, 2011 at 01:56:50PM +0200, Jilles Tjoelker wrote:
On Wed, Sep 14, 2011 at 11:04:56PM +0300, Kostik Belousov wrote:
tzload() allocates ~80KB for the local variables. The backtrace you provided
shows the nested call to tzload(), so there is total 160KB of the stack
space consumed.
By default, stack for the amd64 thread is 4MB, that should be plenty. This
is not the case for ezm3. Possibly, stunnel also reduces the size of the
thread stack.
Please, try the patch below. I did not tested it, only compiled. I see
that now tzload allocates only ~300 bytes on the stack.
80KB seems quite a lot indeed, good to bring it down.
diff --git a/contrib/tzcode/stdtime/localtime.c
b/contrib/tzcode/stdtime/localtime.c
index 80b70ac..55d55e0 100644
--- a/contrib/tzcode/stdtime/localtime.c
+++ b/contrib/tzcode/stdtime/localtime.c
[snip]
@@ -406,16 +409,24 @@ register const intdoextend;
** to hold the longest file name string that the implementation
** guarantees can be opened.
*/
- charfullname[FILENAME_MAX + 1];
+ char*fullname;
+
+ fullname = malloc(FILENAME_MAX + 1);
+ if (fullname == NULL)
+ goto out;
if (name[0] == ':')
++name;
doaccess = name[0] == '/';
if (!doaccess) {
- if ((p = TZDIR) == NULL)
+ if ((p = TZDIR) == NULL) {
+ free(fullname);
return -1;
- if ((strlen(p) + 1 + strlen(name) + 1) = sizeof
fullname)
+ }
+ if ((strlen(p) + 1 + strlen(name) + 1) = sizeof
fullname) {
This sizeof is now the sizeof of a pointer. The comparison should be
against FILENAME_MAX + 1 instead.
Alternatively, the name could be created using asprintf().
You are right. I fixed the defect.
Updated patch below.
diff --git a/contrib/tzcode/stdtime/localtime.c
b/contrib/tzcode/stdtime/localtime.c
index 80b70ac..b1981b6 100644
--- a/contrib/tzcode/stdtime/localtime.c
+++ b/contrib/tzcode/stdtime/localtime.c
@@ -380,13 +380,16 @@ register const intdoextend;
int fid;
int stored;
int nread;
+ int res;
union {
struct tzhead tzhead;
charbuf[2 * sizeof(struct tzhead) +
2 * sizeof *sp +
4 * TZ_MAX_TIMES];
- } u;
+ } *u;
+ u = NULL;
+ res = -1;
sp-goback = sp-goahead = FALSE;
/* XXX The following is from OpenBSD, and I'm not sure it is correct */
@@ -406,16 +409,24 @@ register const intdoextend;
** to hold the longest file name string that the implementation
** guarantees can be opened.
*/
- charfullname[FILENAME_MAX + 1];
+ char*fullname;
+
+ fullname = malloc(FILENAME_MAX + 1);
+ if (fullname == NULL)
+ goto out;
if (name[0] == ':')
++name;
doaccess = name[0] == '/';
if (!doaccess) {
- if ((p = TZDIR) == NULL)
+ if ((p = TZDIR) == NULL) {
+ free(fullname);
return -1;
- if ((strlen(p) + 1 + strlen(name) + 1) = sizeof
fullname)
+ }
+ if (strlen(p) + 1 + strlen(name) = FILENAME_MAX) {
+ free(fullname);
return -1;
+ }
(void) strcpy(fullname, p);
(void) strcat(fullname, /);
(void) strcat(fullname, name);
@@ -426,37 +437,45 @@ register const intdoextend;
doaccess = TRUE;
name = fullname;
}
- if (doaccess access(name, R_OK) != 0)
+ if (doaccess access(name, R_OK) != 0) {
+ free(fullname);
return -1;
- if ((fid = _open(name, OPEN_MODE)) == -1)
+ }
+ if ((fid = _open(name, OPEN_MODE)) == -1) {
+ free(fullname);
return -1;
+ }
if ((_fstat(fid, stab) 0) || !S_ISREG(stab.st_mode)) {
+ free(fullname);
_close(fid);
return -1;
}
}
- nread = _read(fid, u.buf, sizeof u.buf);
+ u = malloc(sizeof(*u));
+ if (u == NULL)
+ goto out;
+
Segfault in libthr.so on 9.0-BETA2 (with stunnel FWIW)
Hi list, I've recently migrated my services from a box running 8.1-STABLE to another one running 9.0-BETA2. I run stunnel 4.28 on 8.1-STABLE, and it has run flawlessly so far. I compiled manually this very version on 9.0-BETA2. But I get the following segfault: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 803008c00 (LWP 100496/stunnel)] 0x00080110d359 in gmtime_r () from /lib/libc.so.7 (gdb) thread [Current thread is 3 (Thread 803008c00 (LWP 100496/stunnel))] (gdb) bt #0 0x00080110d359 in gmtime_r () from /lib/libc.so.7 #1 0x00080110cdde in gmtime_r () from /lib/libc.so.7 #2 0x00080110dab4 in gmtime_r () from /lib/libc.so.7 #3 0x00080110dcc8 in gmtime_r () from /lib/libc.so.7 #4 0x000800e1d9e8 in pthread_once () from /lib/libthr.so.3 #5 0x00080110ca9f in timegm () from /lib/libc.so.7 #6 0x000805dff8d9 in OPENSSL_gmtime () from /usr/local/lib/libcrypto.so.7 #7 0x000805e74631 in ASN1_UTCTIME_adj () from /usr/local/lib/libcrypto.so.7 #8 0x000805e9462d in X509_time_adj_ex () from /usr/local/lib/libcrypto.so.7 #9 0x000805e9478c in X509_cmp_time () from /usr/local/lib/libcrypto.so.7 #10 0x000805e9496d in internal_verify () from /usr/local/lib/libcrypto.so.7 #11 0x000805e95f46 in X509_verify_cert () from /usr/local/lib/libcrypto.so.7 #12 0x000805b7f4c8 in ssl_verify_cert_chain () from /usr/local/lib/libssl.so.7 #13 0x000805b5d6e3 in ssl3_get_client_certificate () from /usr/local/lib/libssl.so.7 #14 0x000805b612bc in ssl3_accept () from /usr/local/lib/libssl.so.7 #15 0x00406f6e in init_ssl (c=0x803093000) at client.c:329 #16 0x004069a6 in do_client (c=0x803093000) at client.c:202 #17 0x0040676b in run_client (c=0x803093000) at client.c:150 #18 0x004066cf in client (arg=0x803093000) at client.c:123 #19 0x000800e18224 in pthread_getprio () from /lib/libthr.so.3 #20 0x in ?? () Note that I tried with the newest version of stunnel, it crashes at the same place. I also tried libssl.so both from the base system and from the ports, same thing. Regards, -- Jeremie Le Hen Men are born free and equal. Later on, they're on their own. Jean Yanne ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Segfault in libthr.so on 9.0-BETA2 (with stunnel FWIW)
On Wed, Sep 14, 2011 at 02:36:07PM +0200, Jeremie Le Hen wrote: Hi list, I've recently migrated my services from a box running 8.1-STABLE to another one running 9.0-BETA2. I run stunnel 4.28 on 8.1-STABLE, and it has run flawlessly so far. I compiled manually this very version on 9.0-BETA2. But I get the following segfault: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 803008c00 (LWP 100496/stunnel)] 0x00080110d359 in gmtime_r () from /lib/libc.so.7 (gdb) thread [Current thread is 3 (Thread 803008c00 (LWP 100496/stunnel))] (gdb) bt #0 0x00080110d359 in gmtime_r () from /lib/libc.so.7 #1 0x00080110cdde in gmtime_r () from /lib/libc.so.7 #2 0x00080110dab4 in gmtime_r () from /lib/libc.so.7 #3 0x00080110dcc8 in gmtime_r () from /lib/libc.so.7 #4 0x000800e1d9e8 in pthread_once () from /lib/libthr.so.3 #5 0x00080110ca9f in timegm () from /lib/libc.so.7 #6 0x000805dff8d9 in OPENSSL_gmtime () from /usr/local/lib/libcrypto.so.7 #7 0x000805e74631 in ASN1_UTCTIME_adj () from /usr/local/lib/libcrypto.so.7 #8 0x000805e9462d in X509_time_adj_ex () from /usr/local/lib/libcrypto.so.7 #9 0x000805e9478c in X509_cmp_time () from /usr/local/lib/libcrypto.so.7 #10 0x000805e9496d in internal_verify () from /usr/local/lib/libcrypto.so.7 #11 0x000805e95f46 in X509_verify_cert () from /usr/local/lib/libcrypto.so.7 #12 0x000805b7f4c8 in ssl_verify_cert_chain () from /usr/local/lib/libssl.so.7 #13 0x000805b5d6e3 in ssl3_get_client_certificate () from /usr/local/lib/libssl.so.7 #14 0x000805b612bc in ssl3_accept () from /usr/local/lib/libssl.so.7 #15 0x00406f6e in init_ssl (c=0x803093000) at client.c:329 #16 0x004069a6 in do_client (c=0x803093000) at client.c:202 #17 0x0040676b in run_client (c=0x803093000) at client.c:150 #18 0x004066cf in client (arg=0x803093000) at client.c:123 #19 0x000800e18224 in pthread_getprio () from /lib/libthr.so.3 #20 0x in ?? () Note that I tried with the newest version of stunnel, it crashes at the same place. I also tried libssl.so both from the base system and from the ports, same thing. You need to compile both libc and libthr with debugging symbols and do a backtrace with such libraries. pgpvXUeoZClco.pgp Description: PGP signature
Re: Segfault in libthr.so on 9.0-BETA2 (with stunnel FWIW)
On Wed, Sep 14, 2011 at 03:59:53PM +0300, Kostik Belousov wrote: On Wed, Sep 14, 2011 at 02:36:07PM +0200, Jeremie Le Hen wrote: Hi list, I've recently migrated my services from a box running 8.1-STABLE to another one running 9.0-BETA2. I run stunnel 4.28 on 8.1-STABLE, and it has run flawlessly so far. I compiled manually this very version on 9.0-BETA2. But I get the following segfault: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 803008c00 (LWP 100496/stunnel)] 0x00080110d359 in gmtime_r () from /lib/libc.so.7 (gdb) thread [Current thread is 3 (Thread 803008c00 (LWP 100496/stunnel))] (gdb) bt #0 0x00080110d359 in gmtime_r () from /lib/libc.so.7 #1 0x00080110cdde in gmtime_r () from /lib/libc.so.7 #2 0x00080110dab4 in gmtime_r () from /lib/libc.so.7 #3 0x00080110dcc8 in gmtime_r () from /lib/libc.so.7 #4 0x000800e1d9e8 in pthread_once () from /lib/libthr.so.3 #5 0x00080110ca9f in timegm () from /lib/libc.so.7 #6 0x000805dff8d9 in OPENSSL_gmtime () from /usr/local/lib/libcrypto.so.7 #7 0x000805e74631 in ASN1_UTCTIME_adj () from /usr/local/lib/libcrypto.so.7 #8 0x000805e9462d in X509_time_adj_ex () from /usr/local/lib/libcrypto.so.7 #9 0x000805e9478c in X509_cmp_time () from /usr/local/lib/libcrypto.so.7 #10 0x000805e9496d in internal_verify () from /usr/local/lib/libcrypto.so.7 #11 0x000805e95f46 in X509_verify_cert () from /usr/local/lib/libcrypto.so.7 #12 0x000805b7f4c8 in ssl_verify_cert_chain () from /usr/local/lib/libssl.so.7 #13 0x000805b5d6e3 in ssl3_get_client_certificate () from /usr/local/lib/libssl.so.7 #14 0x000805b612bc in ssl3_accept () from /usr/local/lib/libssl.so.7 #15 0x00406f6e in init_ssl (c=0x803093000) at client.c:329 #16 0x004069a6 in do_client (c=0x803093000) at client.c:202 #17 0x0040676b in run_client (c=0x803093000) at client.c:150 #18 0x004066cf in client (arg=0x803093000) at client.c:123 #19 0x000800e18224 in pthread_getprio () from /lib/libthr.so.3 #20 0x in ?? () Note that I tried with the newest version of stunnel, it crashes at the same place. I also tried libssl.so both from the base system and from the ports, same thing. You need to compile both libc and libthr with debugging symbols and do a backtrace with such libraries. Here it is: #0 0x000807509359 in tzload (name=0x807536281 posixrules, sp=0x7fbf8e80, doextend=0) at /usr/src/lib/libc/../../contrib/tzcode/stdtime/localtime.c:393 #1 0x000807508dde in tzparse (name=0x7fbeec95 , sp=0x7fbf8e80, lastditch=Variable lastditch is not available. ) at /usr/src/lib/libc/../../contrib/tzcode/stdtime/localtime.c:1001 #2 0x000807509ab4 in tzload (name=Variable name is not available. ) at /usr/src/lib/libc/../../contrib/tzcode/stdtime/localtime.c:579 #3 0x000807509cc8 in gmtload (sp=0x80776f6c0) at /usr/src/lib/libc/../../contrib/tzcode/stdtime/localtime.c:1196 #4 0x00080ce5d9e8 in _pthread_once (once_control=0x80776af00, init_routine=0x807509cf0 gmt_init) at /usr/src/lib/libthr/thread/thr_once.c:87 #5 0x000807508a9f in gmtsub (timep=0x7fbfdaf8, offset=0, tmp=0x7fbfdb00) at /usr/src/lib/libc/../../contrib/tzcode/stdtime/localtime.c:1485 #6 0x00080e7e58d9 in OPENSSL_gmtime () from /usr/local/lib/libcrypto.so.7 #7 0x00080e85a631 in ASN1_UTCTIME_adj () from /usr/local/lib/libcrypto.so.7 #8 0x00080e87a62d in X509_time_adj_ex () from /usr/local/lib/libcrypto.so.7 #9 0x00080e87a78c in X509_cmp_time () from /usr/local/lib/libcrypto.so.7 #10 0x00080e87a96d in internal_verify () from /usr/local/lib/libcrypto.so.7 #11 0x00080e87bf46 in X509_verify_cert () from /usr/local/lib/libcrypto.so.7 #12 0x000809ec94c8 in ssl_verify_cert_chain () from /usr/local/lib/libssl.so.7 #13 0x000809ea76e3 in ssl3_get_client_certificate () from /usr/local/lib/libssl.so.7 #14 0x000809eab2bc in ssl3_accept () from /usr/local/lib/libssl.so.7 #15 0x004076f9 in ?? () #16 0x004082cf in ?? () #17 0x00408c50 in ?? () #18 0x00408d17 in ?? () #19 0x00080ce58224 in thread_start (curthread=0x80d408c00) at /usr/src/lib/libthr/thread/thr_create.c:284 #20 0x in ?? () Error accessing memory address 0x7fbfe000: Bad address. -- Jeremie Le Hen Men are born free and equal. Later on, they're on their own. Jean Yanne ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Segfault in libthr.so on 9.0-BETA2 (with stunnel FWIW)
On Wednesday, September 14, 2011 8:59:53 am Kostik Belousov wrote: On Wed, Sep 14, 2011 at 02:36:07PM +0200, Jeremie Le Hen wrote: Hi list, I've recently migrated my services from a box running 8.1-STABLE to another one running 9.0-BETA2. I run stunnel 4.28 on 8.1-STABLE, and it has run flawlessly so far. I compiled manually this very version on 9.0-BETA2. But I get the following segfault: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 803008c00 (LWP 100496/stunnel)] 0x00080110d359 in gmtime_r () from /lib/libc.so.7 (gdb) thread [Current thread is 3 (Thread 803008c00 (LWP 100496/stunnel))] (gdb) bt #0 0x00080110d359 in gmtime_r () from /lib/libc.so.7 #1 0x00080110cdde in gmtime_r () from /lib/libc.so.7 #2 0x00080110dab4 in gmtime_r () from /lib/libc.so.7 #3 0x00080110dcc8 in gmtime_r () from /lib/libc.so.7 #4 0x000800e1d9e8 in pthread_once () from /lib/libthr.so.3 #5 0x00080110ca9f in timegm () from /lib/libc.so.7 #6 0x000805dff8d9 in OPENSSL_gmtime () from /usr/local/lib/libcrypto.so.7 #7 0x000805e74631 in ASN1_UTCTIME_adj () from /usr/local/lib/libcrypto.so.7 #8 0x000805e9462d in X509_time_adj_ex () from /usr/local/lib/libcrypto.so.7 #9 0x000805e9478c in X509_cmp_time () from /usr/local/lib/libcrypto.so.7 #10 0x000805e9496d in internal_verify () from /usr/local/lib/libcrypto.so.7 #11 0x000805e95f46 in X509_verify_cert () from /usr/local/lib/libcrypto.so.7 #12 0x000805b7f4c8 in ssl_verify_cert_chain () from /usr/local/lib/libssl.so.7 #13 0x000805b5d6e3 in ssl3_get_client_certificate () from /usr/local/lib/libssl.so.7 #14 0x000805b612bc in ssl3_accept () from /usr/local/lib/libssl.so.7 #15 0x00406f6e in init_ssl (c=0x803093000) at client.c:329 #16 0x004069a6 in do_client (c=0x803093000) at client.c:202 #17 0x0040676b in run_client (c=0x803093000) at client.c:150 #18 0x004066cf in client (arg=0x803093000) at client.c:123 #19 0x000800e18224 in pthread_getprio () from /lib/libthr.so.3 #20 0x in ?? () Note that I tried with the newest version of stunnel, it crashes at the same place. I also tried libssl.so both from the base system and from the ports, same thing. You need to compile both libc and libthr with debugging symbols and do a backtrace with such libraries. You really only need symbols from libc. timegm() probably inlines time1() and maybe even gmtsub() which calls pthread_once() to invoke the static routine gmt_init() in src/lib/libc/stdtime/localtime.c. I wonder if this is similar to the crashes seen in cvsup when parsing /usr/share/zoneinfo/UTC (as gmt_init() is going to parse /usr/share/zoneinfo/UTC as well). -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Segfault in libthr.so on 9.0-BETA2 (with stunnel FWIW)
On Wed, Sep 14, 2011 at 05:42:21PM +0200, Jeremie Le Hen wrote: On Wed, Sep 14, 2011 at 03:59:53PM +0300, Kostik Belousov wrote: On Wed, Sep 14, 2011 at 02:36:07PM +0200, Jeremie Le Hen wrote: Hi list, I've recently migrated my services from a box running 8.1-STABLE to another one running 9.0-BETA2. I run stunnel 4.28 on 8.1-STABLE, and it has run flawlessly so far. I compiled manually this very version on 9.0-BETA2. But I get the following segfault: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 803008c00 (LWP 100496/stunnel)] 0x00080110d359 in gmtime_r () from /lib/libc.so.7 (gdb) thread [Current thread is 3 (Thread 803008c00 (LWP 100496/stunnel))] (gdb) bt #0 0x00080110d359 in gmtime_r () from /lib/libc.so.7 #1 0x00080110cdde in gmtime_r () from /lib/libc.so.7 #2 0x00080110dab4 in gmtime_r () from /lib/libc.so.7 #3 0x00080110dcc8 in gmtime_r () from /lib/libc.so.7 #4 0x000800e1d9e8 in pthread_once () from /lib/libthr.so.3 #5 0x00080110ca9f in timegm () from /lib/libc.so.7 #6 0x000805dff8d9 in OPENSSL_gmtime () from /usr/local/lib/libcrypto.so.7 #7 0x000805e74631 in ASN1_UTCTIME_adj () from /usr/local/lib/libcrypto.so.7 #8 0x000805e9462d in X509_time_adj_ex () from /usr/local/lib/libcrypto.so.7 #9 0x000805e9478c in X509_cmp_time () from /usr/local/lib/libcrypto.so.7 #10 0x000805e9496d in internal_verify () from /usr/local/lib/libcrypto.so.7 #11 0x000805e95f46 in X509_verify_cert () from /usr/local/lib/libcrypto.so.7 #12 0x000805b7f4c8 in ssl_verify_cert_chain () from /usr/local/lib/libssl.so.7 #13 0x000805b5d6e3 in ssl3_get_client_certificate () from /usr/local/lib/libssl.so.7 #14 0x000805b612bc in ssl3_accept () from /usr/local/lib/libssl.so.7 #15 0x00406f6e in init_ssl (c=0x803093000) at client.c:329 #16 0x004069a6 in do_client (c=0x803093000) at client.c:202 #17 0x0040676b in run_client (c=0x803093000) at client.c:150 #18 0x004066cf in client (arg=0x803093000) at client.c:123 #19 0x000800e18224 in pthread_getprio () from /lib/libthr.so.3 #20 0x in ?? () Note that I tried with the newest version of stunnel, it crashes at the same place. I also tried libssl.so both from the base system and from the ports, same thing. You need to compile both libc and libthr with debugging symbols and do a backtrace with such libraries. Here it is: #0 0x000807509359 in tzload (name=0x807536281 posixrules, sp=0x7fbf8e80, doextend=0) at /usr/src/lib/libc/../../contrib/tzcode/stdtime/localtime.c:393 #1 0x000807508dde in tzparse (name=0x7fbeec95 , sp=0x7fbf8e80, lastditch=Variable lastditch is not available. ) at /usr/src/lib/libc/../../contrib/tzcode/stdtime/localtime.c:1001 #2 0x000807509ab4 in tzload (name=Variable name is not available. ) at /usr/src/lib/libc/../../contrib/tzcode/stdtime/localtime.c:579 #3 0x000807509cc8 in gmtload (sp=0x80776f6c0) at /usr/src/lib/libc/../../contrib/tzcode/stdtime/localtime.c:1196 #4 0x00080ce5d9e8 in _pthread_once (once_control=0x80776af00, init_routine=0x807509cf0 gmt_init) at /usr/src/lib/libthr/thread/thr_once.c:87 #5 0x000807508a9f in gmtsub (timep=0x7fbfdaf8, offset=0, tmp=0x7fbfdb00) at /usr/src/lib/libc/../../contrib/tzcode/stdtime/localtime.c:1485 #6 0x00080e7e58d9 in OPENSSL_gmtime () from /usr/local/lib/libcrypto.so.7 #7 0x00080e85a631 in ASN1_UTCTIME_adj () from /usr/local/lib/libcrypto.so.7 #8 0x00080e87a62d in X509_time_adj_ex () from /usr/local/lib/libcrypto.so.7 #9 0x00080e87a78c in X509_cmp_time () from /usr/local/lib/libcrypto.so.7 #10 0x00080e87a96d in internal_verify () from /usr/local/lib/libcrypto.so.7 #11 0x00080e87bf46 in X509_verify_cert () from /usr/local/lib/libcrypto.so.7 #12 0x000809ec94c8 in ssl_verify_cert_chain () from /usr/local/lib/libssl.so.7 #13 0x000809ea76e3 in ssl3_get_client_certificate () from /usr/local/lib/libssl.so.7 #14 0x000809eab2bc in ssl3_accept () from /usr/local/lib/libssl.so.7 #15 0x004076f9 in ?? () #16 0x004082cf in ?? () #17 0x00408c50 in ?? () #18 0x00408d17 in ?? () #19 0x00080ce58224 in thread_start (curthread=0x80d408c00) at /usr/src/lib/libthr/thread/thr_create.c:284 #20 0x in ?? () Error accessing memory address 0x7fbfe000: Bad address. tzload() allocates ~80KB for the local variables. The backtrace you provided shows the nested call to tzload(), so there is total 160KB of the stack space consumed. By default, stack for the amd64 thread is 4MB, that should be plenty. This is not
Re: Segfault in libthr.so on 9.0-BETA2 (with stunnel FWIW)
On Wed, Sep 14, 2011 at 11:04:56PM +0300, Kostik Belousov wrote: tzload() allocates ~80KB for the local variables. The backtrace you provided shows the nested call to tzload(), so there is total 160KB of the stack space consumed. Isn't it a little bit hungry? To do this on stack? Softwares with a large amount of threads might want to reduce their stack size dramatically, and so much space might not be available. By default, stack for the amd64 thread is 4MB, that should be plenty. This is not the case for ezm3. Possibly, stunnel also reduces the size of the thread stack. Correct, I checked stunnel source, it reduces it to 64KB by default. However it is possible to override it from the config file. Raising solves the problem indeed. Please, try the patch below. I did not tested it, only compiled. I see that now tzload allocates only ~300 bytes on the stack. I've also tried it, leaving the default stack size chosen by stunnel. It works. Please go ahead and commit it if it's still possible. Thanks. Regards, -- Jeremie Le Hen Men are born free and equal. Later on, they're on their own. Jean Yanne ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
