Re: ssl: crashing since 8d85aa (BUG/MAJOR: map: fix segfault ...)

2017-07-06 Thread Jarno Huuskonen 
Hi,

On Wed, Jul 05, Lukas Tribus wrote:
> Am 05.07.2017 um 13:58 schrieb Emeric Brun:
> >
> >> Another bisect (this time with -dM or -DDEBUG_MEMORY), another commit...
> >> Now it points to 23e9e931 (MINOR: log: Add logurilen tunable).
> >>
> >>
> > Hi Lukas,
> >
> > Indeed this commit introduced a regression.
> >
> > The commit in attachment should fix the issue.
> >
> 
> Great, thank you.
> 
> I guess 23e9e931 also made matching a path unreliable, because with the
> crash fixed, the following configuration now works reliably:
> 
> use_backend robots if { path /robots.txt }

I also got a crash with a testconfig(no ssl). (Emeric's patch fixes this).

BTW compiling w/address sanitizer can also help. I got this crash report on OSX 
(-fsanitize=address -fno-omit-frame-pointer):
==22091==ERROR: AddressSanitizer: heap-buffer-overflow on address 
0x6020e311 at pc 0x00010e940bbe bp 0x7fff519b2d90 sp 0x7fff519b2550
WRITE of size 27 at 0x6020e311 thread T0
#0 0x10e940bbd in __asan_memcpy (libclang_rt.asan_osx_dynamic.dylib+0x41bbd)
#1 0x10e2d9d03 in http_wait_for_request proto_http.c:2964
#2 0x10e36cdf7 in process_stream stream.c:1795
#3 0x10e4ad864 in process_runnable_tasks task.c:238
#4 0x10e4318ad in main haproxy.c:2168
#5 0x7fff84d815ac in start (libdyld.dylib+0x35ac)

0x6020e311 is located 0 bytes to the right of 1-byte region 
[0x6020e310,0x6020e311)
allocated by thread T0 here:
#0 0x10e949bf0 in wrap_malloc (libclang_rt.asan_osx_dynamic.dylib+0x4abf0)
#1 0x10e4a809a in pool_refill_alloc memory.c:117
#2 0x10e2d9bd9 in http_wait_for_request memory.h:151
#3 0x10e36cdf7 in process_stream stream.c:1795
#4 0x10e4ad864 in process_runnable_tasks task.c:238
#5 0x10e4318ad in main haproxy.c:2168
#6 0x7fff84d815ac in start (libdyld.dylib+0x35ac)

-Jarno

-- 
Jarno Huuskonen

Re: ssl: crashing since 8d85aa (BUG/MAJOR: map: fix segfault ...)

2017-07-05 Thread Lukas Tribus 
Hi Emeric,


Am 05.07.2017 um 13:58 schrieb Emeric Brun:
>
>> Another bisect (this time with -dM or -DDEBUG_MEMORY), another commit...
>> Now it points to 23e9e931 (MINOR: log: Add logurilen tunable).
>>
>>
> Hi Lukas,
>
> Indeed this commit introduced a regression.
>
> The commit in attachment should fix the issue.
>

Great, thank you.

I guess 23e9e931 also made matching a path unreliable, because with the
crash fixed, the following configuration now works reliably:

use_backend robots if { path /robots.txt }




Thanks!

Lukas

Re: ssl: crashing since 8d85aa (BUG/MAJOR: map: fix segfault ...)

2017-07-05 Thread Willy Tarreau 
Hi Aleks,

On Wed, Jul 05, 2017 at 02:12:13PM +0200, Aleksandar Lazic wrote:
> Amazing how fast this Open source community is ;-)
> 
> Open : Dienstag, 04. Juli 2017, 21:56:09  (Tue, 4 Jul 2017 21:56:09 +0200)
> Close: Mittwoch, 05. Juli 2017, 14:00:32  (Wed, 5 Jul 2017 14:00:32 +0200)
> 
> Duration: ~16 Hours ( 16 hours, 3 minutes and 51 seconds )
> https://www.timeanddate.com/date/durationresult.html?d1=04=07=2017=05=07=2017=21=56=09=14=00=

You could even count the moment the bug was introduced, it was about 1.5
months ago, which validates the benefit of having an open development
model :

  commit 23e9e931284b44e9d06cca26ab13648873b4029b
  Author: Stéphane Cottin 
  Date:   Thu May 18 08:58:41 2017 +0200

MINOR: log: Add logurilen tunable.

  (...)

Willy

Re: ssl: crashing since 8d85aa (BUG/MAJOR: map: fix segfault ...)

2017-07-05 Thread Willy Tarreau 
On Wed, Jul 05, 2017 at 01:58:03PM +0200, Emeric Brun wrote:
> Indeed this commit introduced a regression.
> 
> The commit in attachment should fix the issue.

Awesome, now merged, thanks! And it was specific to 1.8-dev.

Willy

Re: ssl: crashing since 8d85aa (BUG/MAJOR: map: fix segfault ...)

2017-07-05 Thread Emeric Brun 
On 07/05/2017 12:25 AM, Lukas Tribus wrote:
> 
> Am 04.07.2017 um 23:18 schrieb Willy Tarreau:
>> On Tue, Jul 04, 2017 at 10:57:08PM +0200, Lukas Tribus wrote:
>>> The call trace doesn't really look different when I used -dM or 
>>> -DDEBUG_MEMORY.
>>>
>>> I was able to get a different trace by actually connecting to a backend 
>>> however,
>>> (instead of showing an haproxy internal 403 error):
>> (...)
>>
>> Thank you Lukas, let's hope this will help.
>>
>>
> 
> Another bisect (this time with -dM or -DDEBUG_MEMORY), another commit...
> Now it points to 23e9e931 (MINOR: log: Add logurilen tunable).
> 
> 

Hi Lukas,

Indeed this commit introduced a regression.

The commit in attachment should fix the issue.

R,
Emeric
>From 595396561c380aa100e2c1f80299e5fadd18e663 Mon Sep 17 00:00:00 2001
From: Emeric Brun 
Date: Wed, 5 Jul 2017 13:33:16 +0200
Subject: [PATCH] BUG/MAJOR: http: fix buffer overflow on loguri buffer.

The pool used to log the uri was created with a size of 0 because the
configuration and 'tune.http.logurilen' were parsed too earlier.

The fix consist to postpone the pool_create as it is done for
cookie captures.

Regression introduced with 'MINOR: log: Add logurilen tunable'
---
 src/cfgparse.c   | 2 ++
 src/proto_http.c | 1 -
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/cfgparse.c b/src/cfgparse.c
index 3706bca..600f273 100644
--- a/src/cfgparse.c
+++ b/src/cfgparse.c
@@ -7404,6 +7404,8 @@ int check_config_validity()
 	if (!global.tune.requri_len)
 		global.tune.requri_len = REQURI_LEN;
 
+	pool2_requri = create_pool("requri", global.tune.requri_len , MEM_F_SHARED);
+
 	pool2_capture = create_pool("capture", global.tune.cookie_len, MEM_F_SHARED);
 
 	/* allocate pool of resolution per resolvers */
diff --git a/src/proto_http.c b/src/proto_http.c
index 46cb6ff..7141833 100644
--- a/src/proto_http.c
+++ b/src/proto_http.c
@@ -459,7 +459,6 @@ void init_proto_http()
 
 	/* memory allocations */
 	pool2_http_txn = create_pool("http_txn", sizeof(struct http_txn), MEM_F_SHARED);
-	pool2_requri = create_pool("requri", global.tune.requri_len , MEM_F_SHARED);
 	pool2_uniqueid = create_pool("uniqueid", UNIQUEID_LEN, MEM_F_SHARED);
 }
 
-- 
2.7.4

Re: ssl: crashing since 8d85aa (BUG/MAJOR: map: fix segfault ...)

2017-07-04 Thread Lukas Tribus 

Am 04.07.2017 um 23:18 schrieb Willy Tarreau:
> On Tue, Jul 04, 2017 at 10:57:08PM +0200, Lukas Tribus wrote:
>> The call trace doesn't really look different when I used -dM or 
>> -DDEBUG_MEMORY.
>>
>> I was able to get a different trace by actually connecting to a backend 
>> however,
>> (instead of showing an haproxy internal 403 error):
> (...)
>
> Thank you Lukas, let's hope this will help.
>
>

Another bisect (this time with -dM or -DDEBUG_MEMORY), another commit...
Now it points to 23e9e931 (MINOR: log: Add logurilen tunable).


(gdb) bt
#0  0x77179428 in __GI_raise (sig=sig@entry=6) at 
../sysdeps/unix/sysv/linux/raise.c:54
#1  0x7717b02a in __GI_abort () at abort.c:89
#2  0x771bb7ea in __libc_message (do_abort=do_abort@entry=2, 
fmt=fmt@entry=0x772d4e98 "*** Error in `%s': %s: 0x%s ***\n") at 
../sysdeps/posix/libc_fatal.c:175
#3  0x771c437a in malloc_printerr (ar_ptr=, 
ptr=, str=0x772d4fc8 "double free or corruption (!prev)", 
action=3) at malloc.c:5006
#4  _int_free (av=, p=, have_lock=0) at 
malloc.c:3867
#5  0x771c853c in __GI___libc_free (mem=) at 
malloc.c:2968
#6  0x0053758e in SSL_SESSION_free ()
#7  0x0053324b in SSL_free ()
#8  0x00412055 in ssl_sock_close (conn=0xa56a10) at src/ssl_sock.c:4971
#9  0x004d6a90 in conn_xprt_close (conn=0xa56a10) at 
include/proto/connection.h:96
#10 0x004d6b01 in conn_full_close (conn=0xa56a10) at 
include/proto/connection.h:140
#11 0x004d927f in stream_int_shutw_conn (si=0xaaad08) at 
src/stream_interface.c:883
#12 0x004d7cd7 in si_shutw (si=0xaaad08) at 
include/proto/stream_interface.h:322
#13 0x004d866c in stream_int_notify (si=0xaaad08) at 
src/stream_interface.c:459
#14 0x004d8ad9 in si_conn_wake_cb (conn=0xa56a10) at 
src/stream_interface.c:581
#15 0x004f7fad in conn_fd_handler (fd=5) at src/connection.c:158
#16 0x0050f1cb in fd_process_cached_events () at src/fd.c:240
#17 0x004d4ddd in run_poll_loop () at src/haproxy.c:2193
#18 0x004d6092 in main (argc=5, argv=0x7fffe648) at 
src/haproxy.c:2700
(gdb) quit

and

(gdb) bt
#0  0x77179428 in __GI_raise (sig=sig@entry=6) at 
../sysdeps/unix/sysv/linux/raise.c:54
#1  0x7717b02a in __GI_abort () at abort.c:89
#2  0x771bb7ea in __libc_message (do_abort=2, 
fmt=fmt@entry=0x772d4e98 "*** Error in `%s': %s: 0x%s ***\n") at 
../sysdeps/posix/libc_fatal.c:175
#3  0x771c613e in malloc_printerr (ar_ptr=0x77508b20 , 
ptr=0xa3f410, str=0x772d1cff "malloc(): memory corruption", 
action=) at malloc.c:5006
#4  _int_malloc (av=av@entry=0x77508b20 , bytes=bytes@entry=64) 
at malloc.c:3474
#5  0x771c8184 in __GI___libc_malloc (bytes=64) at malloc.c:2913
#6  0x00503755 in pool_refill_alloc (pool=0xa30cd0, avail=1) at 
src/memory.c:117
#7  0x004eb3be in pool_alloc_dirty (pool=0xa30cd0) at 
include/common/memory.h:151
#8  0x004eb3e0 in pool_alloc2 (pool=0xa30cd0) at 
include/common/memory.h:165
#9  0x004ec10a in flt_stream_add_filter (s=0xaaa650, fconf=0xa3d5b0, 
flags=1) at src/filters.c:324
#10 0x004ec646 in flt_set_stream_backend (s=0xaaa650, be=0xa490e0) at 
src/filters.c:448
#11 0x004e1d63 in stream_set_backend (s=0xaaa650, be=0xa490e0) at 
src/proxy.c:1256
#12 0x00484a8e in process_switching_rules (s=0xaaa650, req=0xaaa660, 
an_bit=32) at src/stream.c:1140
#13 0x00486243 in process_stream (t=0xa4f710) at src/stream.c:1795
#14 0x005063b6 in process_runnable_tasks () at src/task.c:238
#15 0x004d4d6e in run_poll_loop () at src/haproxy.c:2175
#16 0x004d6092 in main (argc=5, argv=0x7fffe648) at 
src/haproxy.c:2700
(gdb)

Re: ssl: crashing since 8d85aa (BUG/MAJOR: map: fix segfault ...)

2017-07-04 Thread Willy Tarreau 
On Tue, Jul 04, 2017 at 10:57:08PM +0200, Lukas Tribus wrote:
> The call trace doesn't really look different when I used -dM or 
> -DDEBUG_MEMORY.
> 
> I was able to get a different trace by actually connecting to a backend 
> however,
> (instead of showing an haproxy internal 403 error):
(...)

Thank you Lukas, let's hope this will help.

Willy

Re: ssl: crashing since 8d85aa (BUG/MAJOR: map: fix segfault ...)

2017-07-04 Thread Lukas Tribus 
Hi,


Am 04.07.2017 um 22:35 schrieb Willy Tarreau:
>
> This one should theorically not be caused by an issue in the task scheduler,
> unless we're reusing something already freed. We could retry it with -dM
> and/or -DDEBUG_MEMORY to force earlier corruption to pop up.

The call trace doesn't really look different when I used -dM or -DDEBUG_MEMORY.

I was able to get a different trace by actually connecting to a backend however,
(instead of showing an haproxy internal 403 error):

(gdb) bt
#0  0x77179428 in __GI_raise (sig=sig@entry=6) at 
../sysdeps/unix/sysv/linux/raise.c:54
#1  0x7717b02a in __GI_abort () at abort.c:89
#2  0x771bb7ea in __libc_message (do_abort=2, 
fmt=fmt@entry=0x772d4e98 "*** Error in `%s': %s: 0x%s ***\n") at 
../sysdeps/posix/libc_fatal.c:175
#3  0x771c2913 in malloc_printerr (ar_ptr=0x77508b20 , 
ptr=0xa83220, str=0x772d1c35 "corrupted size vs. prev_size", 
action=) at malloc.c:5006
#4  malloc_consolidate (av=av@entry=0x77508b20 ) at 
malloc.c:4175
#5  0x771c5cde in _int_malloc (av=av@entry=0x77508b20 , 
bytes=bytes@entry=4448) at malloc.c:3450
#6  0x771c8184 in __GI___libc_malloc (bytes=4448) at malloc.c:2913
#7  0x005d658e in CRYPTO_zalloc ()
#8  0x00536172 in SSL_new ()
#9  0x0041143a in ssl_sock_init (conn=0xa3f9a0) at src/ssl_sock.c:4515
#10 0x004fcc58 in conn_xprt_init (conn=0xa3f9a0) at 
include/proto/connection.h:79
#11 0x004fde02 in session_accept_fd (l=0xa432f0, cfd=5, 
addr=0x7fffe320) at src/session.c:152
#12 0x004e44c6 in listener_accept (fd=4) at src/listener.c:493
#13 0x005116a2 in fd_process_cached_events () at src/fd.c:240
#14 0x004d4a75 in run_poll_loop () at src/haproxy.c:2186
#15 0x004d5d67 in main (argc=7, argv=0x7fffe638) at 
src/haproxy.c:2701
(gdb)

Re: ssl: crashing since 8d85aa (BUG/MAJOR: map: fix segfault ...)

2017-07-04 Thread Willy Tarreau 
On Tue, Jul 04, 2017 at 10:29:27PM +0200, Lukas Tribus wrote:
> > On Tue, Jul 04, 2017 at 09:56:09PM +0200, Lukas Tribus wrote:
> >> Hi Emeric,
> >>
> >>
> >> since 8d85aa4 ("BUG/MAJOR: map: fix segfault during 'show
> >> map/acl' on cli") my setup crashes when a request comes in
> >> going through SSL termination.
> >>
> >> memory corruption, invalid pointers, double free is what haproxy
> >> randomly crashes with.
> > Hmmm bad! Do you want me to revert it now or can this wait for
> > Emeric to try to spot the issue ? William, I've seen you've already
> > backported it into 1.7, be careful not to release the next version
> > before this one is fixed!
> 
> No, I got it wrong, its a different commit that is 1.8-only, sorry.

Ah cool! Emeric already spent a few days trying to sort out this
really painful one, I feared to find him hung in the office after
discovering he has to do it again :-)  So William that's OK for 1.7.

> The commit is 019489 (MAJOR: task: task scheduler rework).

It could very well make sense especially on certain corner cases where
tasks don't quit cleanly. I insisted that this one was merged early so
that potential issues emerge. The other sensitive one is the scheduler
applet rework (no crash expected but possibly unexpected freezes in
bogus applets).

> I hope I got the right one this time (I don't know why, but I bisected to the
> wrong commit twice now).

It happens to me all the time. You press up arrow enter and realize too
late you got "good" or "bad" wrong.

> root@www:/usr/sbin# haproxy -vv
> HA-Proxy version 1.8-dev2-019489-36 2017/06/27
> Copyright 2000-2017 Willy Tarreau 
> 
> Build options :
>   TARGET  = linux2628
>   CPU = generic
>   CC  = gcc
>   CFLAGS  = -O0 -g -fno-strict-aliasing -Wdeclaration-after-statement -fwrapv
>   OPTIONS = USE_GETADDRINFO=1 USE_SLZ=1 USE_OPENSSL=1 USE_PCRE=1 
> USE_PCRE_JIT=1
> 
> Default settings :
>   maxconn = 2000, bufsize = 16384, maxrewrite = 1024, maxpollevents = 200
> 
> Built with OpenSSL version : OpenSSL 1.1.0g-dev  xx XXX 
> Running on OpenSSL version : OpenSSL 1.1.0g-dev  xx XXX 
> OpenSSL library supports TLS extensions : yes
> OpenSSL library supports SNI : yes
> OpenSSL library supports : SSLv3 TLSv1.0 TLSv1.1 TLSv1.2
> Built with transparent proxy support using: IP_TRANSPARENT IPV6_TRANSPARENT 
> IP_FREEBIND
> Built with network namespace support.
> Built with libslz for stateless compression.
> Compression algorithms supported : identity("identity"), deflate("deflate"), 
> raw-deflate("deflate"), gzip("gzip")
> Encrypted password support via crypt(3): yes
> Built with PCRE version : 8.38 2015-11-23
> Running on PCRE version : 8.38 2015-11-23
> PCRE library supports JIT : yes
> 
> Available polling systems :
>   epoll : pref=300,  test result OK
>poll : pref=200,  test result OK
>  select : pref=150,  test result OK
> Total: 3 (3 usable), will use epoll.
> 
> Available filters :
> [SPOE] spoe
> [COMP] compression
> [TRACE] trace
> 
> root@www:/usr/sbin# gdb -ex=r --args haproxy -f /etc/haproxy/haproxy-slim.cfg 
> -d
> GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.04) 7.11.1
> Copyright (C) 2016 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-linux-gnu".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> .
> Find the GDB manual and other documentation resources online at:
> .
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from haproxy...done.
> Starting program: /usr/sbin/haproxy -f /etc/haproxy/haproxy-slim.cfg -d
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> [WARNING] 184/22 (30237) : config : log format ignored for frontend 
> 'tls-termination' since it has no log address.
> [WARNING] 184/22 (30237) : Proxy 'tls-termination': no-sslv3/no-tlsv1x 
> are ignored for bind ':443' at [/etc/haproxy/haproxy-slim.cfg:18]. Use only 
> 'ssl-min-ver' and 'ssl-max-ver' to fix.
> Note: setting global.maxconn to 2000.
> Available polling systems :
>   epoll : pref=300,  test result OK
>poll : pref=200,  test result OK
>  select : pref=150,  test result FAILED
> Total: 3 (2 usable), will use epoll.
> 
> Available filters :
> [SPOE] spoe
> [COMP] compression
> [TRACE] trace
> Using epoll() as the polling mechanism.
> :tls-termination.accept(0004)=0005 from [10.0.0.4:56156]
> :tls-termination.clireq[0005:]: GET /robots.txx HTTP/1.1
>

Re: ssl: crashing since 8d85aa (BUG/MAJOR: map: fix segfault ...)

2017-07-04 Thread Lukas Tribus 
Hi Willy,


Am 04.07.2017 um 22:24 schrieb Willy Tarreau:
> Hi Lukas,
>
> On Tue, Jul 04, 2017 at 09:56:09PM +0200, Lukas Tribus wrote:
>> Hi Emeric,
>>
>>
>> since 8d85aa4 ("BUG/MAJOR: map: fix segfault during 'show
>> map/acl' on cli") my setup crashes when a request comes in
>> going through SSL termination.
>>
>> memory corruption, invalid pointers, double free is what haproxy
>> randomly crashes with.
> Hmmm bad! Do you want me to revert it now or can this wait for
> Emeric to try to spot the issue ? William, I've seen you've already
> backported it into 1.7, be careful not to release the next version
> before this one is fixed!

No, I got it wrong, its a different commit that is 1.8-only, sorry.


The commit is 019489 (MAJOR: task: task scheduler rework).
I hope I got the right one this time (I don't know why, but I bisected to the
wrong commit twice now).



root@www:/usr/sbin# haproxy -vv
HA-Proxy version 1.8-dev2-019489-36 2017/06/27
Copyright 2000-2017 Willy Tarreau 

Build options :
  TARGET  = linux2628
  CPU = generic
  CC  = gcc
  CFLAGS  = -O0 -g -fno-strict-aliasing -Wdeclaration-after-statement -fwrapv
  OPTIONS = USE_GETADDRINFO=1 USE_SLZ=1 USE_OPENSSL=1 USE_PCRE=1 USE_PCRE_JIT=1

Default settings :
  maxconn = 2000, bufsize = 16384, maxrewrite = 1024, maxpollevents = 200

Built with OpenSSL version : OpenSSL 1.1.0g-dev  xx XXX 
Running on OpenSSL version : OpenSSL 1.1.0g-dev  xx XXX 
OpenSSL library supports TLS extensions : yes
OpenSSL library supports SNI : yes
OpenSSL library supports : SSLv3 TLSv1.0 TLSv1.1 TLSv1.2
Built with transparent proxy support using: IP_TRANSPARENT IPV6_TRANSPARENT 
IP_FREEBIND
Built with network namespace support.
Built with libslz for stateless compression.
Compression algorithms supported : identity("identity"), deflate("deflate"), 
raw-deflate("deflate"), gzip("gzip")
Encrypted password support via crypt(3): yes
Built with PCRE version : 8.38 2015-11-23
Running on PCRE version : 8.38 2015-11-23
PCRE library supports JIT : yes

Available polling systems :
  epoll : pref=300,  test result OK
   poll : pref=200,  test result OK
 select : pref=150,  test result OK
Total: 3 (3 usable), will use epoll.

Available filters :
[SPOE] spoe
[COMP] compression
[TRACE] trace

root@www:/usr/sbin# gdb -ex=r --args haproxy -f /etc/haproxy/haproxy-slim.cfg -d
GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.04) 7.11.1
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from haproxy...done.
Starting program: /usr/sbin/haproxy -f /etc/haproxy/haproxy-slim.cfg -d
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[WARNING] 184/22 (30237) : config : log format ignored for frontend 
'tls-termination' since it has no log address.
[WARNING] 184/22 (30237) : Proxy 'tls-termination': no-sslv3/no-tlsv1x are 
ignored for bind ':443' at [/etc/haproxy/haproxy-slim.cfg:18]. Use only 
'ssl-min-ver' and 'ssl-max-ver' to fix.
Note: setting global.maxconn to 2000.
Available polling systems :
  epoll : pref=300,  test result OK
   poll : pref=200,  test result OK
 select : pref=150,  test result FAILED
Total: 3 (2 usable), will use epoll.

Available filters :
[SPOE] spoe
[COMP] compression
[TRACE] trace
Using epoll() as the polling mechanism.
:tls-termination.accept(0004)=0005 from [10.0.0.4:56156]
:tls-termination.clireq[0005:]: GET /robots.txx HTTP/1.1
:tls-termination.clihdr[0005:]: Host: temp.lan.ltri.eu
:tls-termination.clihdr[0005:]: User-Agent: curl/7.48.0
:tls-termination.clihdr[0005:]: Accept: */*
*** Error in `/usr/sbin/haproxy': malloc(): memory corruption: 
0x00a419c0 ***
=== Backtrace: =
/lib/x86_64-linux-gnu/libc.so.6(+0x777e5)[0x771bb7e5]
/lib/x86_64-linux-gnu/libc.so.6(+0x8213e)[0x771c613e]
/lib/x86_64-linux-gnu/libc.so.6(__libc_malloc+0x54)[0x771c8184]
/usr/sbin/haproxy[0x523d66]
/usr/sbin/haproxy[0x522154]
/usr/sbin/haproxy[0x522732]
/usr/sbin/haproxy[0x532480]
/usr/sbin/haproxy[0x4120b6]
/usr/sbin/haproxy[0x4d89dd]
/usr/sbin/haproxy[0x4d9a95]
/usr/sbin/haproxy[0x4fa433]
/usr/sbin/haproxy[0x5116a2]
/usr/sbin/haproxy[0x4d4a75]
/usr/sbin/haproxy[0x4d5d67]

Re: ssl: crashing since 8d85aa (BUG/MAJOR: map: fix segfault ...)

2017-07-04 Thread Willy Tarreau 
Hi Lukas,

On Tue, Jul 04, 2017 at 09:56:09PM +0200, Lukas Tribus wrote:
> Hi Emeric,
> 
> 
> since 8d85aa4 ("BUG/MAJOR: map: fix segfault during 'show
> map/acl' on cli") my setup crashes when a request comes in
> going through SSL termination.
> 
> memory corruption, invalid pointers, double free is what haproxy
> randomly crashes with.

Hmmm bad! Do you want me to revert it now or can this wait for
Emeric to try to spot the issue ? William, I've seen you've already
backported it into 1.7, be careful not to release the next version
before this one is fixed!

Thanks,
Willy

ssl: crashing since 8d85aa (BUG/MAJOR: map: fix segfault ...)

2017-07-04 Thread Lukas Tribus 
Hi Emeric,


since 8d85aa4 ("BUG/MAJOR: map: fix segfault during 'show
map/acl' on cli") my setup crashes when a request comes in
going through SSL termination.

memory corruption, invalid pointers, double free is what haproxy
randomly crashes with.


Here 2 crashes with full backtrace:

*** Error in `/usr/sbin/haproxy': double free or corruption (!prev): 
0x00a42590 ***
=== Backtrace: =
/lib/x86_64-linux-gnu/libc.so.6(+0x777e5)[0x771bb7e5]
/lib/x86_64-linux-gnu/libc.so.6(+0x8037a)[0x771c437a]
/lib/x86_64-linux-gnu/libc.so.6(cfree+0x4c)[0x771c853c]
/usr/sbin/haproxy[0x53a64e]
/usr/sbin/haproxy[0x53630b]
/usr/sbin/haproxy[0x4124de]
/usr/sbin/haproxy[0x48103a]
/usr/sbin/haproxy[0x482f09]
/usr/sbin/haproxy[0x4891af]
/usr/sbin/haproxy[0x50910f]
/usr/sbin/haproxy[0x4d5159]
/usr/sbin/haproxy[0x4d64ba]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x77164830]
/usr/sbin/haproxy[0x4055a9]
=== Memory map: 
0040-007af000 r-xp  ca:02 40972  
/usr/sbin/haproxy
009af000-009cf000 r--p 003af000 ca:02 40972  
/usr/sbin/haproxy
009cf000-009eb000 rw-p 003cf000 ca:02 40972  
/usr/sbin/haproxy
009eb000-00ac5000 rw-p  00:00 0  [heap]
7000-70021000 rw-p  00:00 0
70021000-7400 ---p  00:00 0
76b0e000-76b24000 r-xp  ca:02 24641  
/lib/x86_64-linux-gnu/libgcc_s.so.1
76b24000-76d23000 ---p 00016000 ca:02 24641  
/lib/x86_64-linux-gnu/libgcc_s.so.1
76d23000-76d24000 rw-p 00015000 ca:02 24641  
/lib/x86_64-linux-gnu/libgcc_s.so.1
76d24000-77144000 rw-p  00:00 0
77144000-77304000 r-xp  ca:02 26350  
/lib/x86_64-linux-gnu/libc-2.23.so
77304000-77504000 ---p 001c ca:02 26350  
/lib/x86_64-linux-gnu/libc-2.23.so
77504000-77508000 r--p 001c ca:02 26350  
/lib/x86_64-linux-gnu/libc-2.23.so
77508000-7750a000 rw-p 001c4000 ca:02 26350  
/lib/x86_64-linux-gnu/libc-2.23.so
7750a000-7750e000 rw-p  00:00 0
7750e000-77526000 r-xp  ca:02 24805  
/lib/x86_64-linux-gnu/libpthread-2.23.so
77526000-77725000 ---p 00018000 ca:02 24805  
/lib/x86_64-linux-gnu/libpthread-2.23.so
77725000-77726000 r--p 00017000 ca:02 24805  
/lib/x86_64-linux-gnu/libpthread-2.23.so
77726000-77727000 rw-p 00018000 ca:02 24805  
/lib/x86_64-linux-gnu/libpthread-2.23.so
77727000-7772b000 rw-p  00:00 0
7772b000-77799000 r-xp  ca:02 24672  
/lib/x86_64-linux-gnu/libpcre.so.3.13.2
77799000-77999000 ---p 0006e000 ca:02 24672  
/lib/x86_64-linux-gnu/libpcre.so.3.13.2
77999000-7799a000 r--p 0006e000 ca:02 24672  
/lib/x86_64-linux-gnu/libpcre.so.3.13.2
7799a000-7799b000 rw-p 0006f000 ca:02 24672  
/lib/x86_64-linux-gnu/libpcre.so.3.13.2
7799b000-7799e000 r-xp  ca:02 26330  
/lib/x86_64-linux-gnu/libdl-2.23.so
7799e000-77b9d000 ---p 3000 ca:02 26330  
/lib/x86_64-linux-gnu/libdl-2.23.so
77b9d000-77b9e000 r--p 2000 ca:02 26330  
/lib/x86_64-linux-gnu/libdl-2.23.so
77b9e000-77b9f000 rw-p 3000 ca:02 26330  
/lib/x86_64-linux-gnu/libdl-2.23.so
77b9f000-77ba8000 r-xp  ca:02 24741  
/lib/x86_64-linux-gnu/libcrypt-2.23.so
77ba8000-77da7000 ---p 9000 ca:02 24741  
/lib/x86_64-linux-gnu/libcrypt-2.23.so
77da7000-77da8000 r--p 8000 ca:02 24741  
/lib/x86_64-linux-gnu/libcrypt-2.23.so
77da8000-77da9000 rw-p 9000 ca:02 24741  
/lib/x86_64-linux-gnu/libcrypt-2.23.so
77da9000-77dd7000 rw-p  00:00 0
77dd7000-77dfd000 r-xp  ca:02 24651  
/lib/x86_64-linux-gnu/ld-2.23.so
77fec000-77ff rw-p  00:00 0
77ff5000-77ff8000 rw-p  00:00 0
77ff8000-77ffa000 r--p  00:00 0  [vvar]
77ffa000-77ffc000 r-xp  00:00 0  [vdso]
77ffc000-77ffd000 r--p 00025000 ca:02 24651  
/lib/x86_64-linux-gnu/ld-2.23.so
77ffd000-77ffe000 rw-p 00026000 ca:02 24651  
/lib/x86_64-linux-gnu/ld-2.23.so
77ffe000-77fff000 rw-p  00:00 0
7fede000-7000 rw-p  00:00 0  [stack]
ff60-ff601000 r-xp  00:00 0  
[vsyscall]

Program received