haproxy-1.8 build failure on FreeBSD/i386 (clang)
Hello, haproxy-1.8 does not build on FreeBSD/i386 (clang): src/proto_http.o: In function `http_perform_server_redirect': src/proto_http.c:(.text+0x1209): undefined reference to `__atomic_fetch_add_8' src/proto_http.o: In function `http_wait_for_request': src/proto_http.c:(.text+0x275a): undefined reference to `__atomic_fetch_add_8' src/proto_http.c:(.text+0x2e2c): undefined reference to `__atomic_fetch_add_8' src/proto_http.c:(.text+0x2e48): undefined reference to `__atomic_fetch_add_8' src/proto_http.c:(.text+0x30bb): undefined reference to `__atomic_fetch_add_8' src/proto_http.o:src/proto_http.c:(.text+0x3184): more undefined references to `__atomic_fetch_add_8' follow src/time.o: In function `tv_update_date': src/time.c:(.text+0x631): undefined reference to `__atomic_compare_exchange_8' In include/common/hathreads.h you have (line 107): #if defined(__GNUC__) && (__GNUC__ < 4 || __GNUC__ == 4 && __GNUC_MINOR__ < 7) & & !defined(__clang__) Why do you exclude clang here? If I remove !defined(__clang__), it builds fine but produces a number of similar warnings: In file included from src/compression.c:29: In file included from include/common/cfgparse.h:30: include/proto/proxy.h:116:2: warning: variable '__new' is uninitialized when used within its own initialization [-Wuninitialized] HA_ATOMIC_UPDATE_MAX(>fe_counters.cps_max, ^~ include/common/hathreads.h:172:55: note: expanded from macro 'HA_ATOMIC_UPDATE_MAX' while (__old < __new && !HA_ATOMIC_CAS(val, &__old, __new)); \ ~~~^~ include/common/hathreads.h:128:26: note: expanded from macro 'HA_ATOMIC_CAS' typeof((new)) __new = (new); \ ~^~~ What is the proper fix for that? May be remove !defined(__clang__) ? Thanks!
Re: haproxy 1.8 ssl backend server leads to server session aborts
Hi Mateusz, I'm CCing Emeric (SSL maintainer) and Olivier (who added early-data support), and responding to some points below. On Sat, Feb 10, 2018 at 06:26:42PM +0100, Mateusz Malek wrote: > Hi everyone, > > I've narrowed down my problem down to the same commit as Tomek Gacek - > c2aae74f010f97a3415542fe649198a5d3be1ea8 (MEDIUM: ssl: Handle early data > with OpenSSL 1.1.1), so I guess it may be related. In my case, since upgrade > to 1.8, some responses from some backends (not sure what exactly triggers > the bug) do not have their headers modified (despite http-response > add-header and http-response del-header being set). > > Applying patch part-by-part, I got to a point where it seems that that was > caused by changes to ssl_sock_to_buf function in src/ssl_sock.c (lines > 396-431): > https://gist.github.com/mkwm/13dd32fe2b5ec21182f8a06a304228df#file-break-patch-L396-L431 > > Code at out_error label behave a bit differently from part removed in this > commit - namely, it sets conn->flags |= CO_FL_ERROR unconditionally, while > previously there was an additional check (skipping error flag setting if > errno was set to EAGAIN). My problems went straight away when I've changed > out_error to match old code. Interesting, it would be possible that sometimes an SSL error remains on the stack, and that it randomly gets trapped here. It used to happen in the past and we went through a great pain trying to always clean all of them. I have no idea why this specific condition was removed. It's not mentionned at all in Olivier's commit message and suspiciously looks like an accident. Olivier, do you have an idea on this one ? It's commit c2aae74f. It may be related to an issue Emeric was chasing recently where some server-side connections would occasionally fail if my memory serves me right. > There is also another issue with this commit - it seems that one "1" got > lost in OPENSSL_VERSION_NUMBER comparison (line 267): > https://gist.github.com/mkwm/13dd32fe2b5ec21182f8a06a304228df#file-break-patch-L267 > > Throughout this commit all additions of similar ifdefs use 0x10101000L, > which translates to OpenSSL 1.1.1 - and this one oddly translates to version > 0.1.1. Yes but this one was fixed in 1.8-rc3 by commit cfdef2e3 so it cannot be this one. But the removed part above definitely is an interesting one. > Hope this helps! Sure it does! Thanks! Willy
Re: haproxy 1.8 ssl backend server leads to server session aborts
Hi everyone, I've narrowed down my problem down to the same commit as Tomek Gacek - c2aae74f010f97a3415542fe649198a5d3be1ea8 (MEDIUM: ssl: Handle early data with OpenSSL 1.1.1), so I guess it may be related. In my case, since upgrade to 1.8, some responses from some backends (not sure what exactly triggers the bug) do not have their headers modified (despite http-response add-header and http-response del-header being set). Applying patch part-by-part, I got to a point where it seems that that was caused by changes to ssl_sock_to_buf function in src/ssl_sock.c (lines 396-431): https://gist.github.com/mkwm/13dd32fe2b5ec21182f8a06a304228df#file-break-patch-L396-L431 Code at out_error label behave a bit differently from part removed in this commit - namely, it sets conn->flags |= CO_FL_ERROR unconditionally, while previously there was an additional check (skipping error flag setting if errno was set to EAGAIN). My problems went straight away when I've changed out_error to match old code. There is also another issue with this commit - it seems that one "1" got lost in OPENSSL_VERSION_NUMBER comparison (line 267): https://gist.github.com/mkwm/13dd32fe2b5ec21182f8a06a304228df#file-break-patch-L267 Throughout this commit all additions of similar ifdefs use 0x10101000L, which translates to OpenSSL 1.1.1 - and this one oddly translates to version 0.1.1. Hope this helps! Best regards Mateusz Malek
