Hello Willy,
On Sat, Jul 4, 2020 at 8:11 AM Willy Tarreau wrote:
> HAProxy 2.2-dev12 was released on 2020/07/04. It added 72 new commits
> after version 2.2-dev11.
maybe the package is being uploaded but I can't find it on
http://www.haproxy.org/download/2.2/src/devel/
> - for developers, bui
Willy,
Am 04.07.20 um 08:10 schrieb Willy Tarreau:
> Tim also had some post-2.2 fixes pending to improve free() calls and
> remove some valgrind complaints on exit.
>
Good you mention it, because I forgot to give a heads up: The series
grew a little bit further. My 'deinit' branch as of now is 1
Hi Tim,
On Sat, Jul 04, 2020 at 10:58:12AM +0200, Tim Düsterhus wrote:
> Willy,
>
> Am 04.07.20 um 08:10 schrieb Willy Tarreau:
> > Tim also had some post-2.2 fixes pending to improve free() calls and
> > remove some valgrind complaints on exit.
> >
>
> Good you mention it, because I forgot to
On Sat, Jul 04, 2020 at 10:17:50AM +0200, William Dauchy wrote:
> Hello Willy,
>
> On Sat, Jul 4, 2020 at 8:11 AM Willy Tarreau wrote:
> > HAProxy 2.2-dev12 was released on 2020/07/04. It added 72 new commits
> > after version 2.2-dev11.
>
> maybe the package is being uploaded but I can't find i
Instead of simply calling free() in expr->smp->arg_p in certain cases
properly free the sample using release_sample_expr().
Given the following example configuration:
frontend foo
bind *:8080
mode http
http-request set-var(txn.foo) str(bar)
acl is_match str(foo
Given the following example configuration:
backend foo
mode http
use-server x if { always_true }
server x example.com:80
Running a configuration check with valgrind reports:
==18650== 14 bytes in 1 blocks are definitely lost in loss record 3 of 345
==18650==
Given the following example configuration:
backend foo
mode http
use-server %[str(x)] if { always_true }
server x example.com:80
Running a configuration check with valgrind reports:
==19376== 170 (40 direct, 130 indirect) bytes in 1 blocks are definitely
lost in
This allocation is technically always reachable and cannot leak, but so are
a few others that *are* freed.
---
src/haproxy.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/src/haproxy.c b/src/haproxy.c
index 53301c0be..64d7e0eea 100644
--- a/src/haproxy.c
+++ b/src/hapro
Given the following example configuration:
frontend foo
mode http
bind *:8080
unique-id-header x
Running a configuration check with valgrind reports:
==17621== 2 bytes in 1 blocks are definitely lost in loss record 1 of 341
==17621==at 0x4C2DB8F: malloc (i
This allocation is technically always reachable and cannot leak, but so are
a few others that *are* freed.
---
src/haproxy.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/haproxy.c b/src/haproxy.c
index 7f05d39a8..489a0ebe8 100644
--- a/src/haproxy.c
+++ b/src/haproxy.c
@@ -2606,6
This allocation is technically always reachable and cannot leak, but so are
a few others that *are* freed.
---
src/haproxy.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/src/haproxy.c b/src/haproxy.c
index 70d442c40..7f05d39a8 100644
--- a/src/haproxy.c
+++ b/src/hapro
Given the following example configuration:
resolvers test
nameserver test 127.0.0.1:53
listen foo
bind *:8080
server foo example.com resolvers test
Running a configuration check within valgrind reports:
==21995== 5 bytes in 1 blocks are definitely lost in loss
Given the following example configuration:
listen foo
mode http
bind *:8080
http-request set-var(txn.leak) meth(GET)
server x example.com:80
Running a configuration check with valgrind reports:
==25992== 4 bytes in 1 blocks are definitely lost in loss reco
Instead of just calling release_sample_arg(conv_expr->arg_p) we also must
free() the conv_expr itself (after removing it from the list).
Given the following example configuration:
frontend foo
bind *:8080
mode http
http-request set-var(txn.foo) str(bar)
acl is_
This allocation is technically always reachable and cannot leak, but so are
a few others that *are* freed.
---
src/haproxy.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/src/haproxy.c b/src/haproxy.c
index 64d7e0eea..70d442c40 100644
--- a/src/haproxy.c
+++ b/src/hapro
Given the following example configuration:
frontend foo
mode http
bind *:8080
unique-id-format x
Running a configuration check with valgrind reports:
==30712== 42 (40 direct, 2 indirect) bytes in 1 blocks are definitely lost
in loss record 18 of 39
==30712==
Willy,
Am 04.07.20 um 11:13 schrieb Willy Tarreau:
>> Or you tell me to send it now and apply it to 'next'.
>
> It's up to you. I personally like to keep my topic branch till the last
> moment because that leaves more more freedom to revisit my patches later,
> but when I'm certain patches are de
Given the following example configuration:
listen foo
mode http
bind *:8080
http-request set-var(txn.leak) bool(1)
server x example.com:80
Running a configuration check with valgrind reports:
==24233== 2 bytes in 1 blocks are definitely lost in loss record
vars_deinit() frees all var_names during deinit().
---
src/vars.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/src/vars.c b/src/vars.c
index fd95eed5d..c69a561fa 100644
--- a/src/vars.c
+++ b/src/vars.c
@@ -857,6 +857,15 @@ static int vars_max_size_check(char **args, int
section_t
Compiling HAProxy with USE_LUA=1 and running a configuration check within
valgrind with a very simple configuration such as:
listen foo
bind *:8080
Will report quite a few possible leaks afterwards:
==24048== LEAK SUMMARY:
==24048==definitely lost: 0 bytes in 0 blocks
Willy,
Am 04.07.20 um 11:13 schrieb Willy Tarreau:
>> Or you tell me to send it now and apply it to 'next'.
>
> It's up to you. I personally like to keep my topic branch till the last
> moment because that leaves more more freedom to revisit my patches later,
> but when I'm certain patches are de
On Sat, Jul 04, 2020 at 11:57:08AM +0200, Tim Düsterhus wrote:
> > It's up to you. I personally like to keep my topic branch till the last
> > moment because that leaves more more freedom to revisit my patches later,
> > but when I'm certain patches are definitive, I prefer to get them merged
> > a
Willy,
Am 04.07.20 um 12:11 schrieb Willy Tarreau:
> Thank you. I now rebased next and applied your series on top of it. I'm
> not going to review what goes into -next, or it defeats the purpose of
> using it as a pending queue. There's enough time so that anyone can
> suggest a change and even if
On Sat, Jul 04, 2020 at 02:42:53PM +0200, Tim Düsterhus wrote:
> Willy,
>
> Am 04.07.20 um 12:11 schrieb Willy Tarreau:
> > Thank you. I now rebased next and applied your series on top of it. I'm
> > not going to review what goes into -next, or it defeats the purpose of
> > using it as a pending q
From: Shimi Gersner
haproxy supports generating SSL certificates based on SNI using a provided
CA signing certificate. Because CA certificates may be signed by multiple
CAs, in some scenarios, it is neccesary for the server to attach the trust chain
in addition to the generated certificate.
The
From: Shimi Gersner
Hi folks,
The following patches add two enhancements to the certificate
generation feature.
- SAN extension on the generated certificate
- Chaining the full trust of the original CA certificate
While evaluating HAP for a new product we realized that these
two features ar
From: Shimi Gersner
The use of Common Name is fading out in favor of the RFC recommended
way of using SAN extensions. For example, Chrome from version 58
will only match server name against SAN.
The following patch adds an optional flag to attach SAN extension
of type DNS to the generated certif
27 matches
Mail list logo
