Re: [PATCH 3/3] BUG/MINOR: haproxy: Free rule->arg.vars.expr during deinit_act_rules

Hi Tim, On Sun, Jun 14, 2020 at 12:37:43AM +0200, Tim Duesterhus wrote: > Willy, > > careful with this one: I don't know whether it's safe to simply free the > expression there or whether I need to somehow check whether there actually > is some expression. > > It does not crash with my stupid ex

[PATCH 3/3] BUG/MINOR: haproxy: Free rule->arg.vars.expr during deinit_act_rules

Willy, careful with this one: I don't know whether it's safe to simply free the expression there or whether I need to somehow check whether there actually is some expression. It does not crash with my stupid example configuration showcasing the leak, but of course real world configurations might

[PATCH 1/3] MINOR: haproxy: Add void deinit_and_exit(int)

This helper function calls deinit() and then exit() with the given status. --- include/haproxy/global.h | 1 + src/haproxy.c| 5 + 2 files changed, 6 insertions(+) diff --git a/include/haproxy/global.h b/include/haproxy/global.h index 4cf537403..1028c1b2a 100644 --- a/include/hapr

[PATCH 2/3] MINOR: haproxy: Make use of deinit_and_exit() for clean exits

Particularly cleanly deinit() after a configuration check to clean up the output of valgrind which reports "possible losses" without a deinit() and does not with a deinit(), converting actual losses into proper hard losses which makes the whole stuff easier to analyze. As an example, given an exam

Re: [PATCH] switch to clang-9 in Linux/travis-ci builds

On Sun, Jun 14, 2020 at 01:20:43AM +0500, ??? wrote: > I added "-O1" to travis builds. > Can we apply it until a better solution will be found ? Applied, thank you Ilya. Willy

Re: [PATCH] switch to clang-9 in Linux/travis-ci builds

I added "-O1" to travis builds. Can we apply it until a better solution will be found ? пт, 12 июн. 2020 г. в 21:40, Илья Шипицин : > > > пт, 12 июн. 2020 г. в 21:09, Willy Tarreau : > >> On Fri, Jun 12, 2020 at 08:57:44PM +0500, ??? wrote: >> > ??, 12 ???. 2020 ?. ? 20:46, Willy Tarreau

Re: No access to git.haproxy.org from Travis CI

Hi William, On Sat, Jun 13, 2020 at 03:13:06PM +0200, William Dauchy wrote: > Hi, > > On Thu, Jun 11, 2020 at 1:10 PM Willy Tarreau wrote: > > Sure but what I wanted to say was that travis seems to be the only > > point experiencing such difficulties and we don't know how it works > > nor what a

Re: Broken SNI with crt-list for HAProxy 2.1.x after upgrade from Stretch to Buster

William, Am 13.06.20 um 16:46 schrieb Tim Düsterhus: > tune.ssl.default-dh-param 2048 solved the issue for me. > > I'd argue that this is a bug in HAProxy nonetheless, because apparently > the crt-list file is not fully parsed in case of DH parameter warnings > (not errors). In fact I can remembe

Re: Broken SNI with crt-list for HAProxy 2.1.x after upgrade from Stretch to Buster

Dear List, Am 13.06.20 um 16:11 schrieb Tim Düsterhus: > Any ideas? > Looking at the startup warnings is always a good idea: > Jun 13 14:40:52 *snip* haproxy[15815]: [WARNING] 164/144052 (15815) : > Reexecuting Master process > Jun 13 14:40:52 *snip* haproxy[15815]: [WARNING] 164/144052 (15815

Broken SNI with crt-list for HAProxy 2.1.x after upgrade from Stretch to Buster

Dear List, I finally got around to upgrading my personal box from Debian Stretch to Debian Buster. Unfortunately after the upgrade all my HTTP hosts failed to work, because I use `strict-sni` as well as a strict `crt-list`. Software versions before the upgrade: HAProxy 2.1.7-1~bpo9+1 lib

Re: No access to git.haproxy.org from Travis CI

Hi, On Thu, Jun 11, 2020 at 1:10 PM Willy Tarreau wrote: > Sure but what I wanted to say was that travis seems to be the only > point experiencing such difficulties and we don't know how it works > nor what are the rules in place. I don't know whether this is related to the issue described here