httpd-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 32529] - ProxyPass segmentation fault on SMP x86_64
Date Mon, 06 Dec 2004 00:49:43 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=32529>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32529





------- Additional Comments From mitch@comwestcr.com  2004-12-06 01:49 -------
(In reply to comment #6)
> To be clear, you were testing the vanilla 2.0.52 and 2.0.48 sources against the
> *unpatched* version of OpenSSL, not the one you have patched?
That is correct, the unpatched OpenSSL.
> 
> Could you try changing the first line of ssl_callback_SSLVerify as follows,
instead:
> 
> -    SSL *ssl            = (SSL *)X509_STORE_CTX_get_app_data(ctx);
> +    SSL *ssl = X509_STORE_CTX_get_ex_data(ctx,
> +                                         SSL_get_ex_data_X509_STORE_CTX_idx());
I'll try it, but see below because there may be bigger problems.

> 
> I can't really see why that segfault could happen in the first place, though.
The reason that its happening is that in some cases the openssl code is storing
the SSL* pointer at an index of 1 rather than 0 (the 
X509_STORE_CTX_get_app_data() macro always uses 0).  I discovered this by
putting a fprintf statement in the function X509_STORE_CTX_get_ex_new_index() to
see what values are being returned as indexes in the
SSL_get_ex_data_X509_STORE_CTX_idx() function.  Again, this only happens on the
live apache server not the test one.

By looking at the function  SSL_get_ex_data_X509_STORE_CTX_idx() one would
presume that this would be impossible.  For reference here's the function:

int SSL_get_ex_data_X509_STORE_CTX_idx(void)
	{
	static volatile int ssl_x509_store_ctx_idx= -1;

	if (ssl_x509_store_ctx_idx < 0)
		{
		/* any write lock will do; usually this branch
		 * will only be taken once anyway */
		CRYPTO_w_lock(CRYPTO_LOCK_SSL_CTX);

		if (ssl_x509_store_ctx_idx < 0)
			{
			ssl_x509_store_ctx_idx=X509_STORE_CTX_get_ex_new_index(
				0,"SSL for verify callback",NULL,NULL,NULL);
			}

		CRYPTO_w_unlock(CRYPTO_LOCK_SSL_CTX);
		}
	return ssl_x509_store_ctx_idx;
	}


Also for reference, here is a dump of the assembler for this code:

Dump of assembler code for function SSL_get_ex_data_X509_STORE_CTX_idx:
0x0000000000024710 <SSL_get_ex_data_X509_STORE_CTX_idx+0>:      sub    $0x8,%rsp
0x0000000000024714 <SSL_get_ex_data_X509_STORE_CTX_idx+4>:      mov   
1094190(%rip),%eax        # 0x12f948 <ssl_x509_store_ctx_idx.0>
0x000000000002471a <SSL_get_ex_data_X509_STORE_CTX_idx+10>:     test   %eax,%eax
0x000000000002471c <SSL_get_ex_data_X509_STORE_CTX_idx+12>:     js     0x24730
<SSL_get_ex_data_X509_STORE_CTX_idx+32>
0x000000000002471e <SSL_get_ex_data_X509_STORE_CTX_idx+14>:     mov   
1094180(%rip),%eax        # 0x12f948 <ssl_x509_store_ctx_idx.0>
0x0000000000024724 <SSL_get_ex_data_X509_STORE_CTX_idx+20>:     add    $0x8,%rsp
0x0000000000024728 <SSL_get_ex_data_X509_STORE_CTX_idx+24>:     retq
0x0000000000024729 <SSL_get_ex_data_X509_STORE_CTX_idx+25>:     data16
0x000000000002472a <SSL_get_ex_data_X509_STORE_CTX_idx+26>:     data16
0x000000000002472b <SSL_get_ex_data_X509_STORE_CTX_idx+27>:     data16
0x000000000002472c <SSL_get_ex_data_X509_STORE_CTX_idx+28>:     nop
0x000000000002472d <SSL_get_ex_data_X509_STORE_CTX_idx+29>:     data16
0x000000000002472e <SSL_get_ex_data_X509_STORE_CTX_idx+30>:     data16
0x000000000002472f <SSL_get_ex_data_X509_STORE_CTX_idx+31>:     nop
0x0000000000024730 <SSL_get_ex_data_X509_STORE_CTX_idx+32>:     lea   
20449(%rip),%rdx        # 0x29718 <empty.0+908>
0x0000000000024737 <SSL_get_ex_data_X509_STORE_CTX_idx+39>:     mov    $0x8d,%ecx
0x000000000002473c <SSL_get_ex_data_X509_STORE_CTX_idx+44>:     mov    $0xc,%esi
0x0000000000024741 <SSL_get_ex_data_X509_STORE_CTX_idx+49>:     mov    $0x9,%edi
0x0000000000024746 <SSL_get_ex_data_X509_STORE_CTX_idx+54>:     callq  0xc268
0x000000000002474b <SSL_get_ex_data_X509_STORE_CTX_idx+59>:     mov   
1094135(%rip),%eax        # 0x12f948 <ssl_x509_store_ctx_idx.0>
0x0000000000024751 <SSL_get_ex_data_X509_STORE_CTX_idx+65>:     test   %eax,%eax
0x0000000000024753 <SSL_get_ex_data_X509_STORE_CTX_idx+67>:     jns    0x24770
<SSL_get_ex_data_X509_STORE_CTX_idx+96>
0x0000000000024755 <SSL_get_ex_data_X509_STORE_CTX_idx+69>:     lea   
20423(%rip),%rsi        # 0x29723 <empty.0+919>
0x000000000002475c <SSL_get_ex_data_X509_STORE_CTX_idx+76>:     xor    %r8d,%r8d
0x000000000002475f <SSL_get_ex_data_X509_STORE_CTX_idx+79>:     xor    %ecx,%ecx
0x0000000000024761 <SSL_get_ex_data_X509_STORE_CTX_idx+81>:     xor    %edx,%edx
0x0000000000024763 <SSL_get_ex_data_X509_STORE_CTX_idx+83>:     xor    %edi,%edi
0x0000000000024765 <SSL_get_ex_data_X509_STORE_CTX_idx+85>:     callq  0xc8a8
0x000000000002476a <SSL_get_ex_data_X509_STORE_CTX_idx+90>:     mov   
%eax,1094104(%rip)        # 0x12f948 <ssl_x509_store_ctx_idx.0>
0x0000000000024770 <SSL_get_ex_data_X509_STORE_CTX_idx+96>:     lea   
20385(%rip),%rdx        # 0x29718 <empty.0+908>
0x0000000000024777 <SSL_get_ex_data_X509_STORE_CTX_idx+103>:    mov    $0x95,%ecx
0x000000000002477c <SSL_get_ex_data_X509_STORE_CTX_idx+108>:    mov    $0xc,%esi
0x0000000000024781 <SSL_get_ex_data_X509_STORE_CTX_idx+113>:    mov    $0xa,%edi
0x0000000000024786 <SSL_get_ex_data_X509_STORE_CTX_idx+118>:    callq  0xc268
0x000000000002478b <SSL_get_ex_data_X509_STORE_CTX_idx+123>:    mov   
1094071(%rip),%eax        # 0x12f948 <ssl_x509_store_ctx_idx.0>
0x0000000000024791 <SSL_get_ex_data_X509_STORE_CTX_idx+129>:    add    $0x8,%rsp
0x0000000000024795 <SSL_get_ex_data_X509_STORE_CTX_idx+133>:    retq

The call to CRYPTO_w_lock() should ensure that ssl_x509_store_ctx_idx can only
take on a value of zero.  The assembler looks correct to me.

It looks like a thread synchronization problem, but its hard to believe that
thread synchronization is broken.  Remember that this is an SMP box.  I'm
thinking that the reason I can't reproduce the problem is because the test
server is not as heavily loaded as the live server.

Also note that this is running the prefork mpm module.



-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org


Mime
View raw message