Re: Re: haproxy 1.6.0 crashes

2015-10-20 Thread Willy Tarreau
Hi Rémi, On Tue, Oct 20, 2015 at 10:39:16AM +0200, Remi Gacogne wrote: > Hi, > > On 10/19/2015 05:01 PM, Willy Tarreau wrote: > >> [1] https://www.mail-archive.com/haproxy@formilux.org/msg19962.html > >> [2] https://www.mail-archive.com/haproxy@formilux.org/msg19995.html > > > > Regarding the

Re: Re: haproxy 1.6.0 crashes

2015-10-20 Thread Remi Gacogne
Hi, On 10/19/2015 05:01 PM, Willy Tarreau wrote: >> [1] https://www.mail-archive.com/haproxy@formilux.org/msg19962.html >> [2] https://www.mail-archive.com/haproxy@formilux.org/msg19995.html > > Regarding the second one, maybe Rémi's review could help. I noticed that > you used

Re: haproxy 1.6.0 crashes

2015-10-20 Thread Christopher Faulet
Le 19/10/2015 17:01, Willy Tarreau a écrit : On Mon, Oct 19, 2015 at 03:06:44PM +0200, Christopher Faulet wrote: OK so the unused objects in the tree have a refcount of 1 while the used ones have 2 or more, thus the refcount is always valid. Good that also means we must not test if the tree is

Re: haproxy 1.6.0 crashes

2015-10-20 Thread Willy Tarreau
On Tue, Oct 20, 2015 at 02:14:37PM +0200, Christopher Faulet wrote: > Le 20/10/2015 14:07, Willy Tarreau a écrit : > >On Tue, Oct 20, 2015 at 01:59:52PM +0200, Willy Tarreau wrote: > >>Then my understanding is that we should instead proceed differently : > >> - the cert is generated. It gets a

Re: haproxy 1.6.0 crashes

2015-10-20 Thread Willy Tarreau
On Tue, Oct 20, 2015 at 01:59:52PM +0200, Willy Tarreau wrote: > Then my understanding is that we should instead proceed differently : > - the cert is generated. It gets a refcount = 1. > - we assign it to the SSL. Its refcount becomes two. > - we try to insert it into the tree. The tree

Re: haproxy 1.6.0 crashes

2015-10-20 Thread Christopher Faulet
Le 20/10/2015 14:07, Willy Tarreau a écrit : On Tue, Oct 20, 2015 at 01:59:52PM +0200, Willy Tarreau wrote: Then my understanding is that we should instead proceed differently : - the cert is generated. It gets a refcount = 1. - we assign it to the SSL. Its refcount becomes two. - we

Re: haproxy 1.6.0 crashes

2015-10-20 Thread Willy Tarreau
Hi Christopher, On Tue, Oct 20, 2015 at 01:32:57PM +0200, Christopher Faulet wrote: > >But then how do we know that an SSL_CTX is still in use when we want to > >evict it from the cache and that we must not free it ? Is it just the > >fact that between the moment it's picked from the cache using

Re: haproxy 1.6.0 crashes

2015-10-20 Thread Willy Tarreau
On Tue, Oct 20, 2015 at 03:00:42PM +0200, Christopher Faulet wrote: > Le 20/10/2015 14:41, Willy Tarreau a écrit : > >On Tue, Oct 20, 2015 at 02:14:37PM +0200, Christopher Faulet wrote: > >>Le 20/10/2015 14:07, Willy Tarreau a écrit : > >>>On Tue, Oct 20, 2015 at 01:59:52PM +0200, Willy Tarreau

Re: haproxy 1.6.0 crashes

2015-10-20 Thread Willy Tarreau
So I can confirm with your reproducer that it's OK now. I've merged the proposed fix with copies of your long detailed analysis. Thanks for being so patient to explain me :-) We'll have to wait for the last pending DNS fixes and I'll emit 1.6.1 so that we get rid of these annoying early bugs.

Re: haproxy 1.6.0 crashes

2015-10-20 Thread Christopher Faulet
Le 20/10/2015 14:41, Willy Tarreau a écrit : On Tue, Oct 20, 2015 at 02:14:37PM +0200, Christopher Faulet wrote: Le 20/10/2015 14:07, Willy Tarreau a écrit : On Tue, Oct 20, 2015 at 01:59:52PM +0200, Willy Tarreau wrote: Then my understanding is that we should instead proceed differently :

Re: haproxy 1.6.0 crashes

2015-10-19 Thread Christopher Faulet
Hi Willy, Le 16/10/2015 19:07, Willy Tarreau a écrit : The SSL_CTX and SSL objects are reference-counted objects, so there is no problem. When a SSL_CTX object is created, its refcount is set to 1. When a SSL connection use it, it is incremented and when the connection is closed, it is

Re: haproxy 1.6.0 crashes

2015-10-19 Thread Willy Tarreau
On Mon, Oct 19, 2015 at 03:06:44PM +0200, Christopher Faulet wrote: > >OK so the unused objects in the tree have a refcount of 1 while the used > >ones have 2 or more, thus the refcount is always valid. Good that also > >means we must not test if the tree is null or not in ssl_sock_close(), > >we

Re: haproxy 1.6.0 crashes

2015-10-16 Thread Willy Tarreau
Hi Christopher, sorry for the delay, I spent the whole day in meetings :-/ On Fri, Oct 16, 2015 at 11:42:38AM +0200, Christopher Faulet wrote: > Le 16/10/2015 10:38, Willy Tarreau a écrit : > >Thus this sparks a new question : when the cache is disabled, are we sure > >to always free the ssl_ctx

Re: haproxy 1.6.0 crashes

2015-10-16 Thread Christopher Faulet
Le 15/10/2015 16:55, Willy Tarreau a écrit : Hi Christopher, On Thu, Oct 15, 2015 at 03:22:52PM +0200, Christopher Faulet wrote: Le 15/10/2015 14:45, Seri, Kim a écrit : Christopher Faulet writes: I confirm the bug. Here is a very quick patch. Could you confirm that it works

Re: haproxy 1.6.0 crashes

2015-10-16 Thread Willy Tarreau
Hi Christopher, On Fri, Oct 16, 2015 at 10:03:06AM +0200, Christopher Faulet wrote: > First the LRU tree is only initialized when the SSL certs generation is > configured on a bind line. So, in the most of cases, it is NULL (it is > not the same thing than empty). > When the SSL certs

Re: Re: haproxy 1.6.0 crashes

2015-10-16 Thread Remi Gacogne
Hi Willy, Christopher, > Ideally we'd have the info in the ssl_ctx itself, but I remember that Emeric > told me a while ago that we couldn't store anything in an ssl_ctx. Thus I > can understand that we can't easily "tag" the ssl_ctx as being statically > or dynamically allocated, which is why I

Re: haproxy 1.6.0 crashes

2015-10-16 Thread Christopher Faulet
Le 16/10/2015 10:38, Willy Tarreau a écrit : Thus this sparks a new question : when the cache is disabled, are we sure to always free the ssl_ctx on all error paths after it's generated ? Or are we certain that we always pass through ssl_sock_close() ? That's a good question. By greping on

Re: haproxy 1.6.0 crashes

2015-10-15 Thread Christopher Faulet
Le 15/10/2015 10:51, Seri, Kim a écrit : Hi, all HAProxy 1.6.0 crashes in multiple certificates environment as belows, bind :443 ssl crt test.com.pem crt test2.com.pem ecdhe prime256v1 but, in single certificate environment, haproxy doesn't crash. bind :443 ssl crt test.com.pem ecdhe

Re: haproxy 1.6.0 crashes

2015-10-15 Thread Seri , Kim
Christopher Faulet writes: > I confirm the bug. Here is a very quick patch. Could you confirm that it > works for you ? > Hi, I can confirm this patch fixes the crash!! cf. because of my mail service, I've changed my e-mail Thanks a lot. Seri

Re: haproxy 1.6.0 crashes

2015-10-15 Thread Christopher Faulet
Le 15/10/2015 14:45, Seri, Kim a écrit : Christopher Faulet writes: I confirm the bug. Here is a very quick patch. Could you confirm that it works for you ? Hi, I can confirm this patch fixes the crash!! cf. because of my mail service, I've changed my e-mail Thanks a lot.

Re: haproxy 1.6.0 crashes

2015-10-15 Thread Willy Tarreau
Hi Christopher, On Thu, Oct 15, 2015 at 03:22:52PM +0200, Christopher Faulet wrote: > Le 15/10/2015 14:45, Seri, Kim a écrit : > >Christopher Faulet writes: > > > >>I confirm the bug. Here is a very quick patch. Could you confirm that it > >>works for you ? > >> > > > >Hi, > > > >I