Hi Cyril, On Thu, Jan 16, 2014 at 10:48:10PM +0100, Cyril Bonté wrote: > Hi Willy, > > Le 15/01/2014 01:08, Willy Tarreau a écrit : > >On Tue, Jan 14, 2014 at 12:25:37PM -0800, Steve Ruiz wrote: > >>Patched and confirmed in our environment that this is now working / seems > >>to have fixed the issue. Thanks! > > > >Great, many thanks to you both guys. We've got rid of another pretty > >old bug, these are the ones that make me the happiest once fixed! > > > >I'm currently unpacking my laptop to push the fix so that it appears > >in todays snapshot. > > > >Excellent work! > > I fear there are some more work to do on this patch. > I made some tests on ssl and it looks to be broken since this commit :-( > > The shortest configuration I could find to reproduce the issue is : > listen test > bind 0.0.0.0:443 ssl crt cert.pem > mode http > timeout server 5s > timeout client 5s > > When a request is received by haproxy, the cpu raises to 100% in a > epoll_wait loop (timeouts are here to prevent an unlimited loop). > > $ curl -k https://localhost/ > ... > epoll_wait(3, {{EPOLLIN, {u32=5, u64=5}}}, 200, 0) = 1 > epoll_wait(3, {{EPOLLIN, {u32=5, u64=5}}}, 200, 0) = 1 > epoll_wait(3, {{EPOLLIN, {u32=5, u64=5}}}, 200, 0) = 1 > epoll_wait(3, {{EPOLLIN, {u32=5, u64=5}}}, 200, 0) = 1 > epoll_wait(3, {{EPOLLIN, {u32=5, u64=5}}}, 200, 0) = 1 > ...
So I might have broken something in the way to count the "try" value, ending up with zero being selected and nothing done. Unfortunately it works fine here. Could you try to single-step in gdb through ssl_sock_to_buf ? I'll continue to test if I can reproduce it and also to understand in which case we could end up with a wrong size computation. Thanks, Willy
