2.0-dev5-ea8dd94 - conn_fd_handler() - dumps core - Program terminated with signal 11, Segmentation fault.

[PiBa-NL]

Hi Olivier,

It seems this commit ea8dd94  broke something for my FreeBSD11 system. 
Before that commit (almost) all vtest's succeed. After it several cause 
core-dumps. (and keep doing that including the current HEAD: 03abf2d )


Can you take a look at the issue?

Below in this mail are the following:
- gdb# bt full  of one of the crashed tests..
- summary of failed tests

Regards,
PiBa-NL (Pieter)

gdb --core 
/tmp/haregtests-2019-06-05_20-40-20.7ZSvbo/vtc.65353.510907b0/h1/haproxy.core 
./work/haproxy-ea8dd94/haproxy

GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain 
conditions.

Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...
Core was generated by 
`/usr/ports/net/haproxy-devel/work/haproxy-ea8dd94/haproxy -d -f 
/tmp/haregtests-'.

Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libcrypt.so.5...done.
Loaded symbols for /lib/libcrypt.so.5
Reading symbols from /lib/libz.so.6...done.
Loaded symbols for /lib/libz.so.6
Reading symbols from /lib/libthr.so.3...done.
Loaded symbols for /lib/libthr.so.3
Reading symbols from /usr/lib/libssl.so.8...done.
Loaded symbols for /usr/lib/libssl.so.8
Reading symbols from /lib/libcrypto.so.8...done.
Loaded symbols for /lib/libcrypto.so.8
Reading symbols from /usr/local/lib/liblua-5.3.so...done.
Loaded symbols for /usr/local/lib/liblua-5.3.so
Reading symbols from /lib/libm.so.5...done.
Loaded symbols for /lib/libm.so.5
Reading symbols from /lib/libc.so.7...done.
Loaded symbols for /lib/libc.so.7
Reading symbols from /libexec/ld-elf.so.1...done.
Loaded symbols for /libexec/ld-elf.so.1
#0  conn_fd_handler (fd=55) at src/connection.c:201
201 conn->mux->wake && conn->mux->wake(conn) < 0)
(gdb) bt full
#0  conn_fd_handler (fd=55) at src/connection.c:201
    conn = (struct connection *) 0x8027e7000
    flags = 0
    io_available = 1
#1  0x005fe3f2 in fdlist_process_cached_events (fdlist=0xa66ac0) 
at src/fd.c:452

    fd = 55
    old_fd = 55
    e = 39
    locked = 0
#2  0x005fdefc in fd_process_cached_events () at src/fd.c:470
No locals.
#3  0x0051c15d in run_poll_loop () at src/haproxy.c:2553
    next = 0
    wake = 0
#4  0x00519ba7 in run_thread_poll_loop (data=0x0) at 
src/haproxy.c:2607

    ptaf = (struct per_thread_alloc_fct *) 0x94f158
    ptif = (struct per_thread_init_fct *) 0x94f168
    ptdf = (struct per_thread_deinit_fct *) 0x7fffe640
    ptff = (struct per_thread_free_fct *) 0x610596
#5  0x0051620d in main (argc=4, argv=0x7fffe648) at 
src/haproxy.c:3286

    blocked_sig = {__bits = 0x7fffe398}
    old_sig = {__bits = 0x7fffe388}
    i = 16
    err = 0
    retry = 200
    limit = {rlim_cur = 234908, rlim_max = 234909}
    errmsg = 0x7fffe550 ""
    pidfd = -1
Current language:  auto; currently minimal


## Starting vtest ##
Testing with haproxy version: 2.0-dev5-ea8dd94
#    top  TEST reg-tests/lua/txn_get_priv.vtc FAILED (0.308) exit=2
#    top  TEST reg-tests/ssl/wrong_ctx_storage.vtc FAILED (0.308) exit=2
#    top  TEST reg-tests/compression/lua_validation.vtc FAILED (0.433) 
exit=2

#    top  TEST reg-tests/checks/tls_health_checks.vtc TIMED OUT (kill -9)
#    top  TEST reg-tests/checks/tls_health_checks.vtc FAILED (20.153) 
signal=9
#    top  TEST reg-tests/peers/tls_basic_sync_wo_stkt_backend.vtc TIMED 
OUT (kill -9)
#    top  TEST reg-tests/peers/tls_basic_sync_wo_stkt_backend.vtc FAILED 
(20.137) signal=9

#    top  TEST reg-tests/peers/tls_basic_sync.vtc TIMED OUT (kill -9)
#    top  TEST reg-tests/peers/tls_basic_sync.vtc FAILED (20.095) signal=9
#    top  TEST reg-tests/connection/proxy_protocol_random_fail.vtc TIMED 
OUT (kill -9)
#    top  TEST reg-tests/connection/proxy_protocol_random_fail.vtc 
FAILED (20.195) signal=9

7 tests failed, 0 tests skipped, 29 tests passed
## Gathering results ##
## Test case: reg-tests/compression/lua_validation.vtc ##
## test results in: 
"/tmp/haregtests-2019-06-05_20-40-20.7ZSvbo/vtc.65353.510907b0"

 top   0.4 shell_exit not as expected: got 0x0001 wanted 0x
 h1    0.4 Bad exit status: 0x008b exit 0x0 signal 11 core 128
## Test case: reg-tests/peers/tls_basic_sync.vtc ##
## test results in: 
"/tmp/haregtests-2019-06-05_20-40-20.7ZSvbo/vtc.65353.5e9ca234"


## Test case: reg-tests/connection/proxy_protocol_random_fail.vtc ##
## test results in: 
"/tmp/haregtests-2019-06-05_20-40-20.7ZSvbo/vtc.65353.19403d36"


## Test case: reg-tests/lua/txn_get_priv.vtc ##
## test results in: 

RE: cygwin compilation error

[Zakharychev, Bob]

>On Tue, Jun 04, 2019 at 09:46:04PM +, Zakharychev, Bob wrote:
>> I mean it returns 0. What happens is that as soon as the other side 
>> (haproxy) terminates, poll() starts returning immediately with 
>> positive return value and POLLIN being the only flag set in 
>> fd->revents as if there's something to read and descriptor is still open. 
>> read() then returns 0. Rinse, repeat.
>
>OK so this is a valid detection of end of response.
>
>> Since original VTest code only breaks the poll/read loop if either 
>> POLLHUP or POLLERR are also set in revents, which doesn't happen here 
>> for some reason,
>
> You should see POLLHUP and POLLERR as optimizations : when the system already 
> knows there will be such events it may place them, but similarly they could 
> also 
> happen between the moment you check the events and the moment you decide
> to read, so really a read() should always check for error and for zero.

Thanks for the explanation. I was under impression I'm missing something 
obvious here, but if this is expected behavior then I guess my workaround is 
not really a workaround. 

>> the loop never breaks until the thread itself times out (10 seconds) 
>> and gets killed. This, however, results in a "failed" test from VTest 
>> perspective. I think I can #ifdef __CYGWIN__ my changes to keep 
>> original behavior intact where it's known to work.

> I'd say "s/is known to work/happens to work/" :-) Probably that an issue 
> should be
> filed on this specific point for vtest to improve it (and its portability). 
> After all, nothing
> prevents poll() from being implemented using select() and it should work in 
> this situation.

Looking at Cygwin poll() source code it's actually the way it's implemented: 
using cygwin_select(), which seems to be a wrapper around pselect(). I'll 
suggest my patch to vtest.

Bob

Re: [BUG] memory leak with treads and stick-table/peers

[Emmanuel Hocdet]

> Le 5 juin 2019 à 16:07, Emmanuel Hocdet  a écrit :
> 
> Hi Frederic
> 
>> Le 5 juin 2019 à 15:44, Frederic Lecaille > > a écrit :
>> 
>> On 6/5/19 3:06 PM, Emmanuel Hocdet wrote:
>>> Hi,
>> 
>> Hi Emmanuel,
>> 
>>> After switched to haproxy 1.9 with threads activated, i noticed a 
>>> significant memory leak.
>> 
>> Is valgrind able to expose this memory leak?
>> 
>>> With threads disable (and bind process omitted) leak disappear.
>>> This seems to be related to stick-table/peers with regard to the 
>>> (simplified) configuration.
>> 
>> Has this been revealed by a git bisect?
>> 
> 
> Report is from production, i need to reproduce this on dev platform to debug 
> more.
> 

As a reminder, the leak was detected after thread enable, on 1.9.5.

Re: [BUG] memory leak with treads and stick-table/peers

[Emmanuel Hocdet]

Hi Frederic

> Le 5 juin 2019 à 15:44, Frederic Lecaille  a écrit :
> 
> On 6/5/19 3:06 PM, Emmanuel Hocdet wrote:
>> Hi,
> 
> Hi Emmanuel,
> 
>> After switched to haproxy 1.9 with threads activated, i noticed a 
>> significant memory leak.
> 
> Is valgrind able to expose this memory leak?
> 
>> With threads disable (and bind process omitted) leak disappear.
>> This seems to be related to stick-table/peers with regard to the 
>> (simplified) configuration.
> 
> Has this been revealed by a git bisect?
> 

Report is from production, i need to reproduce this on dev platform to debug 
more.

> I am trying to understand the impact of the peers configuration 
> simplification on your configuration because as far as I see you do not use 
> this feature.
> 
> This feature is used only if you have "table" lines in "peers" sections.
> 
> Furthermore this feature has not been backported to 1.9. This is a 2.0 
> specific feature. Or perhaps I have missed something.
> 
> This feature comes with at least this commit:
> 
>MEDIUM: stick-table: Stop handling stick-tables as proxies.
> 

It’s legacy stick-table/peers configuration:

backend ssl-back
...
stick-table type binary len 32 size 1m expire 5m peers front-peers

++
Manu

Re: [BUG] memory leak with treads and stick-table/peers

[Frederic Lecaille]

On 6/5/19 3:06 PM, Emmanuel Hocdet wrote:


Hi,


Hi Emmanuel,

After switched to haproxy 1.9 with threads activated, i noticed a 
significant memory leak.


Is valgrind able to expose this memory leak?


With threads disable (and bind process omitted) leak disappear.

This seems to be related to stick-table/peers with regard to the 
(simplified) configuration.


Has this been revealed by a git bisect?

I am trying to understand the impact of the peers configuration 
simplification on your configuration because as far as I see you do not 
use this feature.


This feature is used only if you have "table" lines in "peers" sections.

Furthermore this feature has not been backported to 1.9. This is a 2.0 
specific feature. Or perhaps I have missed something.


This feature comes with at least this commit:

MEDIUM: stick-table: Stop handling stick-tables as proxies.


Fred.

[BUG] memory leak with treads and stick-table/peers

[Emmanuel Hocdet]

Hi,

After switched to haproxy 1.9 with threads activated, i noticed a significant 
memory leak.
With threads disable (and bind process omitted) leak disappear.

This seems to be related to stick-table/peers with regard to the (simplified) 
configuration.

++
Manu


ENV:
HA-Proxy version 1.9.8-1 2019/05/15 - https://haproxy.org/
Build options :
  TARGET  = linux2628
  CPU = generic
  CC  = gcc
  CFLAGS  = -g -O2 -fPIE -fstack-protector-strong -Wformat 
-Werror=format-security -D_FORTIFY_SOURCE=2
  OPTIONS = USE_ZLIB=1 USE_REGPARM=1 USE_OPENSSL=1 USE_SYSTEMD=1 USE_PCRE=1 
USE_NS=1

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

Built with OpenSSL version : BoringSSL 7f4f41fa
OpenSSL library supports TLS extensions : yes
OpenSSL library supports SNI : yes
OpenSSL library supports : TLSv1.0 TLSv1.1 TLSv1.2 TLSv1.3
Built with network namespace support.
Built with transparent proxy support using: IP_TRANSPARENT IPV6_TRANSPARENT 
IP_FREEBIND
Built with zlib version : 1.2.8
Running on zlib version : 1.2.8
Compression algorithms supported : identity("identity"), deflate("deflate"), 
raw-deflate("deflate"), gzip("gzip")
Built with PCRE version : 8.35 2014-04-04
Running on PCRE version : 8.35 2014-04-04
PCRE library supports JIT : no (USE_PCRE_JIT not set)
Encrypted password support via crypt(3): yes
Built with multi-threading support.

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 multiplexer protocols :
(protocols marked as  cannot be specified using 'proto' keyword)
  h2 : mode=HTXside=FE|BE
  h2 : mode=HTTP   side=FE
: mode=HTXside=FE|BE
: mode=TCP|HTTP   side=FE|BE

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

minimal configuration to reproduce the leak:
global
user haproxy
group haproxy
daemon

# ssl(odd) http(even)
nbthread 2

stats socket /var/run/haproxy_L6.sock mode 660 level admin expose-fd 
listeners

log /dev/log daemon warning

# hard limit
hard-stop-after 2h
maxconn 262144

defaults
log global
log-tag "haproxy_L6"
option dontlognull
mode tcp
maxconn 10
timeout connect 500ms


timeout client 610s
retries 3
timeout server 610s

peers front-peers

peer L6_1 x.y.z.1:943

peer L6_2 x.y.z.2:943

peer L6_3 x.y.z.3:943


frontend ssl-front

bind :443  process 1/odd
bind :::443 v6only process 1/odd


tcp-request inspect-delay 5s
tcp-request content reject if !{ req_ssl_sni -m found }
default_backend ssl-back

backend ssl-back
balance roundrobin
option ssl-hello-chk

stick-table type binary len 32 size 1m expire 5m peers front-peers

acl clienthello req_ssl_hello_type 1
acl serverhello rep_ssl_hello_type 2

tcp-request inspect-delay 5s
tcp-request content accept if clienthello

tcp-response content accept if serverhello

stick on payload_lv(43,1) if clienthello
stick store-response payload_lv(43,1) if serverhello


server ssl_1 a.b.c.1:463 check send-proxy 

server ssl_2 a.b.c.2:463 check send-proxy 

server ssl_3 a.b.c.3:463 check send-proxy 

frontend http-front
bind :80  process 1/even
bind :::80 v6only process 1/even


default_backend http-back


backend http-back
balance roundrobin


server L7_1 a.b.c.1:480 check send-proxy 

server L7_2 a.b.c.1:480 check send-proxy 

server L7_3 a.b.c.3:480 check send-proxy 

Re: Discussion about "Upstream socks proxy support #82"

[Ciprian Dorin Craciun]

On Mon, Jun 3, 2019 at 3:49 AM Aleksandar Lazic  wrote:
> nutinshell have another use case which is a `socks4-redirect`
> https://github.com/haproxy/haproxy/issues/82#issuecomment-498007739


Is there such a specification for `socks4-redirect`?  (I've looked in
the original SOCKS4 specification and didn't find any mention about
it:  https://www.openssh.com/txt/socks4.protocol .)




> I see at least this use cases from this thread.
>
> * client with explicit SOCKS support -> HAProxy SOCKS frontend -> normal 
> backend
> / servers -- useful for routing only specific domains through HAProxy
>
> The suggestion here is to handle socks in the same way as proxy protocol. As
> mentioned above I don't think that's that easy as the socks protocol is a
> request response system which proxy protocol isn't.


Based on the SOCKS4 specification, the protocol is "request-reply"
only in the first interaction (one request / one reply), and after
that it goes into tunnel mode:

https://www.openssh.com/txt/socks4.protocol
For a successful request,
the SOCKS server gets ready to relay traffic on both directions. This
enables the client to do I/O on its connection as if it were directly
connected to the application server.



> There are also not only "the" socks protocol as there is socks4,socks4a and
> socks5 with different feature sets and requirements. From what I seen in the
> thread is only socks4 with command **connect** expected. This means that the
> client sends the destination ip and port therefore haproxy does not need to
> resolve the destination.


Yes, that is the way I've proposed it:  SOCKS4 plain-and-simple, IPv4
only, no DNS, no other extensions.  (At least not in the first
iteration, although perhaps IPv6, without DNS resolutions, might also
be useful, as per https://tools.ietf.org/html/rfc3089 )




> From my point of view it is at least a similar option like `accept-proxy`
> required for example `accept-socks(4|4a|5)`
>
> One of the question which is open is make `accept-proxy` and
> `accept-socks(4|4a|5)` sense?
>
> @cipriancraciun and others opinions?


I think `accept-socks` would be enough (for the frontend), because
from what I gather the protocol version can be decoded from the actual
headers.  (Perhaps a new sample might be added to determine that SOCKS
is used, and which version, to then force certain versions.)

However, just like in case of `accept-proxy`, on the backend (better
said server) side an `send-socks(4|5)` would be needed to allow the
administrator to choose the downstream protocol.  (SOCKS4a from what I
gather added support for DNS resolution, which we don't actually
need.)




> * client (with / without) SOCKS support -> HAProxy frontend -> SOCKS enabled
> server -- useful for traffic filtering, and redirection to a proper SOCKS 
> proxy;
>
> The reason why the patch from alec isn't enough is that answer
>
> 
> From what I read @alec-liu implemented SOCKS4 in the backend only as a way to
> submit requests for to a "fixed" server IP through a "fixed" SOCKS4 proxy 
> server.
> 


Exactly, I underline once more, that the main difference with the
other proposed patch, is that in my proposal the server IP is the IP
of the SOCKS gateway, and that the sent IP in the SOCKS4 header is the
one in `src`, just as it happens in case of the (HA)PROXY protocol.)




> I think this feature would be nice in HAProxy but I also think it's a huge
> amount of work and increases the complexity to debug any errors.


In case of only supporting SOCKS4 as an alternative to the (HA)PROXY
header, the amount of work should be minimal, except that one also has
to read the initial reply from the SOCKS gateway.

Unfortunately I'm not that acquainted with the HAProxy internals, but
if one could pin-point me where in the "reply" path I should include
the response handling I could take a stab at it if I can find some
time.  Some time ago Willy provided me some pointers, but I bet given
the recent work to support HTTP/2, a lot has changed in the interim.

Ciprian.

Re: cygwin compilation error

[Илья Шипицин]

Bob,

we have added very basic cygwin CI

https://travis-ci.com/haproxy/haproxy/jobs/205561046

it is "build only". feel free to improve it :)

ср, 5 июн. 2019 г. в 02:49, Zakharychev, Bob :

> Willy,
>
> On Tue, Jun 04, 2019 at 05:52:12PM +, Zakharychev, Bob wrote:
> >> Finally got VTest compiling and working as expected (I think) under
> Cygwin.
> >> config.h had to be adjusted and vtc_syslog.c needed 
> >> included, but nothing big. However, there's some weird poll() behavior
> >> where it never raises POLLHUP or POLLERR and returns immediately with
> >> POLLIN flag raised when the other side disconnects but read()
> >> consistently returns no error and no data,
>
> > Note, by "no error and no data", do you mean "-1, EAGAIN" or "0" ?
> Because
> > the only case read() should return zero is when the end was reached.
> POLLHUP
> > is not even guaranteed to be presented at all. That's why most of the
> time you
> > see POLLHUP|POLLIN registered for the same handler.
>
> I mean it returns 0. What happens is that as soon as the other side
> (haproxy) terminates, poll() starts returning immediately with positive
> return value and POLLIN being the only flag set in fd->revents as if
> there's something to read and descriptor is still open. read() then returns
> 0. Rinse, repeat. Since original VTest code only breaks the poll/read loop
> if either POLLHUP or POLLERR are also set in revents, which doesn't happen
> here for some reason, the loop never breaks until the thread itself times
> out (10 seconds) and gets killed. This, however, results in a "failed" test
> from VTest perspective. I think I can #ifdef __CYGWIN__ my changes to keep
> original behavior intact where it's known to work.
>
> >> so when haproxy gets killed vtc_record() keeps polling its STDOUT
> >> until the thread itself times out because poll() doesn't seem to
> >> return correct flags.
> >>
> >> I hacked vtc_record() to exit the loop when poll() returns with POLLIN
> >> raised, but read() returns 0 bytes two times in a row. This got most
> >> of the reg-tests running successfully. Now some of them fail because
> >> the expected syslog format doesn't match what HA-Proxy actually logs:
> >>
> >>  Slog_1  0.2 syslog|<6>127.0.0.1:61336 [04/Jun/2019:12:56:28.053]
> ssl-offload-http~ ssl-offload-http/http 0/0/-1/-1/0 503 220 - - SC--
> 1/1/0/0/3 0/0 "POST#20#2F#31#20HTTP#2F#31#2E#31"
> >> **   Slog_1  0.2 === expect ~ "ssl-offload-http/http .* \"POST /[1-8]
> HTTP/(2\\.0...
> >>  Slog_1  0.2 EXPECT FAILED ~ "ssl-offload-http/http .* "POST /[1-8]
> HTTP/(2\.0|1\.1)""
>
> > Looks like it decided that non-letter characters had to be encoded.
> We're using FD_ISSET()
> > to look up the characters in the character encoding map because this was
> convenient in
> > the past, but maybe it's time to have a native implementation of a bit
> address lookup and
> > get rid of this now.
>
> > Good job!
> > Willy
>
> Thanks 
> Bob
>

Re: cygwin compilation error

[Willy Tarreau]

On Tue, Jun 04, 2019 at 09:46:04PM +, Zakharychev, Bob wrote:
> I mean it returns 0. What happens is that as soon as the other side (haproxy)
> terminates, poll() starts returning immediately with positive return value
> and POLLIN being the only flag set in fd->revents as if there's something to
> read and descriptor is still open. read() then returns 0. Rinse, repeat.

OK so this is a valid detection of end of response.

> Since original VTest code only breaks the poll/read loop if either POLLHUP or
> POLLERR are also set in revents, which doesn't happen here for some reason,

You should see POLLHUP and POLLERR as optimizations : when the system already
knows there will be such events it may place them, but similarly they could
also happen between the moment you check the events and the moment you decide
to read, so really a read() should always check for error and for zero.

> the loop never breaks until the thread itself times out (10 seconds) and gets
> killed. This, however, results in a "failed" test from VTest perspective. I
> think I can #ifdef __CYGWIN__ my changes to keep original behavior intact
> where it's known to work.

I'd say "s/is known to work/happens to work/" :-)
Probably that an issue should be filed on this specific point for vtest
to improve it (and its portability). After all, nothing prevents poll()
from being implemented using select() and it should work in this situation.

> > Looks like it decided that non-letter characters had to be encoded. We're 
> > using FD_ISSET() 
> > to look up the characters in the character encoding map because this was 
> > convenient in 
> > the past, but maybe it's time to have a native implementation of a bit 
> > address lookup and
> > get rid of this now.

I've just created an issue about this one so we don't forget it.

Willy

Re: [PATCH] improve travis-ci builds

[Willy Tarreau]

On Wed, Jun 05, 2019 at 02:21:48AM +0500,  ??? wrote:
> update LibreSSL to 2.9.2
> speed up build by using "make -j3"
> cache BoringSSL checkout
> build prometeus exporter
> add basic cygwin build
> add USE_TFO=1, USE_SYSTEMD=1 to linux builds

Merged, thanks Ilya!
Willy

Re: [PATCH] MINOR: SSL: add client/server random sample fetches

[Willy Tarreau]

On Tue, Jun 04, 2019 at 07:56:21PM -0400, Patrick Hemmer wrote:
> The updated patch fixes the documentation to be in alphabetical order. Got
> carried away with putting the doc in the same order the code is in.

Now merged, thank you Patrick!
willy

Re: [PATCH] CLEANUP: ssl: remove unneeded defined(OPENSSL_IS_BORINGSSL)

[Willy Tarreau]

On Wed, Jun 05, 2019 at 12:55:17PM +0500,  ??? wrote:
> something went wrong ?
> 
> I do not see this commit

Bah I should stop merging patches late at night, it turns out it's not
the first time I forget to push and they rot on my other machine :-(

Thanks for notifying me,
Willy

Re: SD-termination cause

[Willy Tarreau]

Hi Maksim,

On Tue, Jun 04, 2019 at 07:55:09AM +0300, ?? ? wrote:
> Sorry for bothering you, but do you have any news about this case?

I just wanted to send you a quick update on this to let you know
that it's not forgotten, it is that while taking a look at the
connection setup parts, I opened a huge can of worms which explains
a large number of the recent issues with looping tasks met by Pieter,
your problem and others some of the guys here have been facing for a
while delaying the finishing of some features.

I'm still trying to fix this mess, it's not trivial at all and may
even require an extra -dev. So expect some updates later.

Cheers,
Willy

Re: [PATCH] CLEANUP: ssl: remove unneeded defined(OPENSSL_IS_BORINGSSL)

[Илья Шипицин]

something went wrong ?

I do not see this commit

ср, 5 июн. 2019 г. в 01:35, Willy Tarreau :

> On Tue, Jun 04, 2019 at 05:04:03PM +0200, Emmanuel Hocdet wrote:
> > Hi,
> >
> > Simple cleanup to limit #defined inflation.
>
> Merged, thanks Manu.
>
> Willy
>
>