date:20200221

haproxy 2.1.2 and 2.1.3

2020-02-21 Thread marcel.kloosterman

Hi all,

At this moment we’re using  HA-Proxy version 2.0.0 2019/06/16 - 
https://haproxy.org/
And we’re running solaris 11.4 sru 950 for SPARC and I used developer studio 
version 12.6 to compile the newer versions and 12.5 to compile the 2.0.0 
version.

And because of a known bug in haproxy, we wanted to upgrade to: HA-Proxy 
version 2.1.2 2019/12/21 - https://haproxy.org/
On our test-server we had no problems but on the production server it kept 
crashing.
The problem is somehow related to ssl, because as soon as we add “ssl crt 
/etc/certs/self.pem” to the bind it crashes also on the test-server.
So then I checked and version 2.1.3 is already available, solving lots of ssl 
bugs. So I tried that one also…but without any luck ☹

Starting haproxy now gives a Bus Error (with both versons, 2.1.2 and 2.1.3):

root@sz4203:~ # /usr/local/sbin/haproxy -p /tmp/haproxy.pid -f 
/usr/local/etc/haproxy.cfg
Bus Error (core dumped)

Can you please help me solving this issue ?

This is the stack-dump of the 2.1.3 version I compiled:
root@s00501:/var/core# pstack core_sz4203_haproxy_0_0_1582273479_18461
core 'core_sz4203_haproxy_0_0_1582273479_18461' of 18461:   
/usr/local/sbin/haproxy -p /tmp/haproxy.pid -f /usr/local/etc/haproxy.
000100240c30 shctx_init (100366170, 4e20, c4, , 7ec00144, 
0) + b0 (shctx.c:368)
000100086e7c ssl_sock_prepare_bind_conf (1005bbb80, , 
fffefffc, 29729948, , 100366000) + 1bc
000100135278 check_config_validity (fffefffc, 1400, 1005bbb80, 
1005bb750, 100357238, 0) + 25b8 (cfgparse.c:3753)
000100173450 init (100357468, 1000596a0, 10005a940, 100357238, 10003aa90, 
0) + 610 (haproxy.c:1884)
000100178058 main (5, 7688, 76b8, 10, 
10046d680, 0) + 178 (haproxy.c:2858)
00010006caa4 _start (0, 0, 0, 0, 0, 0) + 64

And this is how I compiled the 2.1.3 version:

PATH=/usr/gnu/bin:${PATH}:/opt/developerstudio12.6/bin/
cd ~bhr_kloos605/haproxy-2.1.3/
vi Makefile
Just to make sure that I can compile…changes:
root@sz4203:/export/home/bhr_kloos605# diff haproxy-2.1.3/Makefile 
haproxy-2.1.3.compiled/Makefile
137c137
< DESTDIR =
---
> DESTDIR = /tmp/haproxy
662c662,663
< OPTIONS_LDFLAGS += $(if $(PCRE_LIB),-L$(PCRE_LIB)) -Wl,-Bstatic -lpcreposix 
-lpcre -Wl,-Bdynamic
---
> #OPTIONS_LDFLAGS += $(if $(PCRE_LIB),-L$(PCRE_LIB)) -Wl,-Bstatic -lpcreposix 
> -lpcre -Wl,-Bdynamic
> OPTIONS_LDFLAGS += $(if $(PCRE_LIB),-L$(PCRE_LIB)) -Bstatic -lpcreposix -lpcre
make TARGET=solaris CPU=ultrasparc PCRE_LIB=/usr/lib PCRE_INC=/usr/include/pcre 
USE_STATIC_PCRE=1 USE_OPENSSL=1
make install

Can you please help ?


Met vriendelijke groet/Kind regards,

[cid:image001.png@01D5E898.D6935330]
Marcel Kloosterman
Specialist Technisch Beheer


KPN
N&I ACN P&TDC DC Cloud 1

Phone: +31612413284
Email: marcel.klooster...@kpn.com
TeamWiki (with spoc planning): 
https://confluence.kpn.org/display/KDU/KPN+DCLOUD+SOLARIS+CLOUD+TEAM+HOMEPAGE
(JIRA access is required and can be requested using IAM portal)
BTW nr.: NL0092.92.056B01
KvK: 27124701

The information transmitted is intended only for use by the addressee and may 
contain confidential and/or privileged material. Any review, re-transmission, 
dissemination or other use of it, or the taking of any action in reliance upon 
this information by persons and/or entities other than the intended recipient 
is prohibited. If you received this in error, please inform the sender and/or 
addressee immediately and delete the material. Thank you.

Re: haproxy 2.1.2 and 2.1.3

2020-02-21 Thread Илья Шипицин

useful things to debug would be

1) haorpxy -vv
2) config
3) bt full


can you please open a github issue at
https://github.com/haproxy/haproxy/issues  ?

пт, 21 февр. 2020 г. в 13:55, :

> Hi all,
>
>
>
> At this moment we’re using  HA-Proxy version 2.0.0 2019/06/16 -
> https://haproxy.org/
>
> And we’re running solaris 11.4 sru 950 for SPARC and I used developer
> studio version 12.6 to compile the newer versions and 12.5 to compile the
> 2.0.0 version.
>
>
>
> And because of a known bug in haproxy, we wanted to upgrade to: HA-Proxy
> version 2.1.2 2019/12/21 - https://haproxy.org/
>
> On our test-server we had no problems but on the production server it kept
> crashing.
>
> The problem is somehow related to ssl, because as soon as we add “ssl crt
> /etc/certs/self.pem” to the bind it crashes also on the test-server.
>
> So then I checked and version 2.1.3 is already available, solving lots of
> ssl bugs. So I tried that one also…but without any luck ☹
>
>
>
> Starting haproxy now gives a Bus Error (with both versons, 2.1.2 and
> 2.1.3):
>
>
>
> root@sz4203:~ # /usr/local/sbin/haproxy -p /tmp/haproxy.pid -f
> /usr/local/etc/haproxy.cfg
>
> Bus Error (core dumped)
>
>
>
> Can you please help me solving this issue ?
>
>
>
> This is the stack-dump of the 2.1.3 version I compiled:
>
> root@s00501:/var/core# pstack core_sz4203_haproxy_0_0_1582273479_18461
>
> core 'core_sz4203_haproxy_0_0_1582273479_18461' of 18461:
> /usr/local/sbin/haproxy -p /tmp/haproxy.pid -f /usr/local/etc/haproxy.
>
> 000100240c30 shctx_init (100366170, 4e20, c4, ,
> 7ec00144, 0) + b0 (shctx.c:368)
>
> 000100086e7c ssl_sock_prepare_bind_conf (1005bbb80, ,
> fffefffc, 29729948, , 100366000) + 1bc
>
> 000100135278 check_config_validity (fffefffc, 1400, 1005bbb80,
> 1005bb750, 100357238, 0) + 25b8 (cfgparse.c:3753)
>
> 000100173450 init (100357468, 1000596a0, 10005a940, 100357238,
> 10003aa90, 0) + 610 (haproxy.c:1884)
>
> 000100178058 main (5, 7688, 76b8, 10,
> 10046d680, 0) + 178 (haproxy.c:2858)
>
> 00010006caa4 _start (0, 0, 0, 0, 0, 0) + 64
>
>
>
> And this is how I compiled the 2.1.3 version:
>
>
>
> PATH=/usr/gnu/bin:${PATH}:/opt/developerstudio12.6/bin/
>
> cd ~bhr_kloos605/haproxy-2.1.3/
>
> vi Makefile
>
> Just to make sure that I can compile…changes:
>
> root@sz4203:/export/home/bhr_kloos605# diff haproxy-2.1.3/Makefile
> haproxy-2.1.3.compiled/Makefile
>
> 137c137
>
> < DESTDIR =
>
> ---
>
> > DESTDIR = /tmp/haproxy
>
> 662c662,663
>
> < OPTIONS_LDFLAGS += $(if $(PCRE_LIB),-L$(PCRE_LIB)) -Wl,-Bstatic
> -lpcreposix -lpcre -Wl,-Bdynamic
>
> ---
>
> > #OPTIONS_LDFLAGS += $(if $(PCRE_LIB),-L$(PCRE_LIB)) -Wl,-Bstatic
> -lpcreposix -lpcre -Wl,-Bdynamic
>
> > OPTIONS_LDFLAGS += $(if $(PCRE_LIB),-L$(PCRE_LIB)) -Bstatic -lpcreposix
> -lpcre
>
> make TARGET=solaris CPU=ultrasparc PCRE_LIB=/usr/lib
> PCRE_INC=/usr/include/pcre USE_STATIC_PCRE=1 USE_OPENSSL=1
>
> make install
>
>
>
> Can you please help ?
>
>
>
>
>
> Met vriendelijke groet/Kind regards,
>
>
>
> *Marcel Kloosterman*
>
> *Specialist Technisch Beheer*
>
>
>
>
>
> *KPN*
>
> N&I ACN P&TDC DC Cloud 1
>
> Phone: +31612413284
>
> Email: marcel.klooster...@kpn.com
>
> TeamWiki (with spoc planning):
> https://confluence.kpn.org/display/KDU/KPN+DCLOUD+SOLARIS+CLOUD+TEAM+HOMEPAGE
>
> (JIRA access is required and can be requested using IAM portal)
>
> *BTW nr.: NL0092.92.056B01*
>
> *KvK: 27124701*
>
>
>
> *The information transmitted is intended only for use by the addressee and
> may contain confidential and/or privileged material. Any review,
> re-transmission, dissemination or other use of it, or the taking of any
> action in reliance upon this information by persons and/or entities other
> than the intended recipient is prohibited. If you received this in error,
> please inform the sender and/or addressee immediately and delete the
> material. Thank you.*
>
>
>

Re: haproxy 2.1.2 and 2.1.3

2020-02-21 Thread William Lallemand

Hello,

On Fri, Feb 21, 2020 at 08:52:05AM +, marcel.klooster...@kpn.com wrote:
> Hi all,
> 
> At this moment we’re using  HA-Proxy version 2.0.0 2019/06/16 - 
> https://haproxy.org/
> And we’re running solaris 11.4 sru 950 for SPARC and I used developer studio 
> version 12.6 to compile the newer versions and 12.5 to compile the 2.0.0 
> version.
> 
> And because of a known bug in haproxy, we wanted to upgrade to: HA-Proxy 
> version 2.1.2 2019/12/21 - https://haproxy.org/
> On our test-server we had no problems but on the production server it kept 
> crashing.
> The problem is somehow related to ssl, because as soon as we add “ssl crt 
> /etc/certs/self.pem” to the bind it crashes also on the test-server.
> So then I checked and version 2.1.3 is already available, solving lots of ssl 
> bugs. So I tried that one also…but without any luck ☹
> 
> Starting haproxy now gives a Bus Error (with both versons, 2.1.2 and 2.1.3):
> 
> root@sz4203:~ # /usr/local/sbin/haproxy -p /tmp/haproxy.pid -f 
> /usr/local/etc/haproxy.cfg
> Bus Error (core dumped)
> 
> Can you please help me solving this issue ?
> 
> This is the stack-dump of the 2.1.3 version I compiled:
> root@s00501:/var/core# pstack core_sz4203_haproxy_0_0_1582273479_18461
> core 'core_sz4203_haproxy_0_0_1582273479_18461' of 18461:   
> /usr/local/sbin/haproxy -p /tmp/haproxy.pid -f /usr/local/etc/haproxy.
> 000100240c30 shctx_init (100366170, 4e20, c4, , 7ec00144, 
> 0) + b0 (shctx.c:368)
> 000100086e7c ssl_sock_prepare_bind_conf (1005bbb80, , 
> fffefffc, 29729948, , 100366000) + 1bc
> 000100135278 check_config_validity (fffefffc, 1400, 1005bbb80, 
> 1005bb750, 100357238, 0) + 25b8 (cfgparse.c:3753)
> 000100173450 init (100357468, 1000596a0, 10005a940, 100357238, 10003aa90, 
> 0) + 610 (haproxy.c:1884)
> 000100178058 main (5, 7688, 76b8, 10, 
> 10046d680, 0) + 178 (haproxy.c:2858)
> 00010006caa4 _start (0, 0, 0, 0, 0, 0) + 64
> 

That's really odd, what is crashing is the shctx_init(), which is the
initialization of the shared memory used by the SSL, it didn't changed
much in 2 years so I'm surprised that you didn't have this problem with
haproxy 2.0.

Since its running on SPARC and that the Bus Error appears in the the
shctx block access that could be an alignment issue.
But if it's working on your test server it might be something
else. Do the test server and the production one share the same hardware?
(CPU, RAM etc.)

Could you display the stacktrace with gdb? The arguments looks weird to
me, (too much arguments and weird values) and I don't know how reliable
is pstack about this.

Did you try to build haproxy 2.0 with your new compiler and do the same
tests? Do you have the same issue?


-- 
William Lallemand

RE: haproxy 2.1.2 and 2.1.3

2020-02-21 Thread marcel.kloosterman

Hi,

I created issue:  haproxy 2.1.3 issue with ssl on solaris 11 sru 950 #512

Nut really sure about gdb and bt full.
First time using it… had to install it first.
Is this what you need:

root@SYSTEM:/var/core# gdb --core=core_sz4203_haproxy_0_0_1582279635_18282
GNU gdb (GDB) 8.0
Copyright (C) 2017 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 "sparc-sun-solaris2.11".
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".
[New LWP 1]
[New LWP 1]
Core was generated by `/usr/local/sbin/haproxy -p /tmp/haproxy.pid -f 
/usr/local/etc/haproxy.cfg'.
Program terminated with signal SIGBUS, Bus error.
#0  0x000100242c90 in ?? ()
(gdb) bt full
#0  0x000100242c90 in ?? ()
No symbol table info available.
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Can you please guide me…

Met vriendelijke groet/Kind regards,

[cid:image001.png@01D5E8AA.6AD7A760]
Marcel Kloosterman
Specialist Technisch Beheer


KPN
N&I ACN P&TDC DC Cloud 1

Phone: +31612413284
Email: marcel.klooster...@kpn.com
TeamWiki (with spoc planning): 
https://confluence.kpn.org/display/KDU/KPN+DCLOUD+SOLARIS+CLOUD+TEAM+HOMEPAGE
(JIRA access is required and can be requested using IAM portal)
BTW nr.: NL0092.92.056B01
KvK: 27124701

The information transmitted is intended only for use by the addressee and may 
contain confidential and/or privileged material. Any review, re-transmission, 
dissemination or other use of it, or the taking of any action in reliance upon 
this information by persons and/or entities other than the intended recipient 
is prohibited. If you received this in error, please inform the sender and/or 
addressee immediately and delete the material. Thank you.

Van: Илья Шипицин 
Verzonden: vrijdag 21 februari 2020 10:24
Aan: Kloosterman, Marcel 
CC: HAProxy 
Onderwerp: Re: haproxy 2.1.2 and 2.1.3

useful things to debug would be

1) haorpxy -vv
2) config
3) bt full


can you please open a github issue at https://github.com/haproxy/haproxy/issues 
 ?

пт, 21 февр. 2020 г. в 13:55, 
mailto:marcel.klooster...@kpn.com>>:
Hi all,

At this moment we’re using  HA-Proxy version 2.0.0 2019/06/16 - 
https://haproxy.org/
And we’re running solaris 11.4 sru 950 for SPARC and I used developer studio 
version 12.6 to compile the newer versions and 12.5 to compile the 2.0.0 
version.

And because of a known bug in haproxy, we wanted to upgrade to: HA-Proxy 
version 2.1.2 2019/12/21 - https://haproxy.org/
On our test-server we had no problems but on the production server it kept 
crashing.
The problem is somehow related to ssl, because as soon as we add “ssl crt 
/etc/certs/self.pem” to the bind it crashes also on the test-server.
So then I checked and version 2.1.3 is already available, solving lots of ssl 
bugs. So I tried that one also…but without any luck ☹

Starting haproxy now gives a Bus Error (with both versons, 2.1.2 and 2.1.3):

root@sz4203:~ # /usr/local/sbin/haproxy -p /tmp/haproxy.pid -f 
/usr/local/etc/haproxy.cfg
Bus Error (core dumped)

Can you please help me solving this issue ?

This is the stack-dump of the 2.1.3 version I compiled:
root@s00501:/var/core# pstack core_sz4203_haproxy_0_0_1582273479_18461
core 'core_sz4203_haproxy_0_0_1582273479_18461' of 18461:   
/usr/local/sbin/haproxy -p /tmp/haproxy.pid -f /usr/local/etc/haproxy.
000100240c30 shctx_init (100366170, 4e20, c4, , 7ec00144, 
0) + b0 (shctx.c:368)
000100086e7c ssl_sock_prepare_bind_conf (1005bbb80, , 
fffefffc, 29729948, , 100366000) + 1bc
000100135278 check_config_validity (fffefffc, 1400, 1005bbb80, 
1005bb750, 100357238, 0) + 25b8 (cfgparse.c:3753)
000100173450 init (100357468, 1000596a0, 10005a940, 100357238, 10003aa90, 
0) + 610 (haproxy.c:1884)
000100178058 main (5, 7688, 76b8, 10, 
10046d680, 0) + 178 (haproxy.c:2858)
00010006caa4 _start (0, 0, 0, 0, 0, 0) + 64

And this is how I compiled the 2.1.3 version:

PATH=/usr/gnu/bin:${PATH}:/opt/developerstudio12.6/bin/
cd ~bhr_kloos605/haproxy-2.1.3/
vi Makefile
Just to make sure that I can compile…changes:
root@sz4203:/export/home/bhr_kloos605# diff haproxy-2.1.3/Makefile 
haproxy-2.1.3.compiled/Makefile
137c137
< DESTDIR =
---
> DESTDIR = /tmp/haproxy
662c662,663
< OPTIONS_LDFLAGS += $(if $(PCRE_LIB),-L$(PCRE_LIB)) -Wl,-Bstatic -lpcreposix 
-lpcre -Wl,-Bdynamic
---
> #OPTIONS_LDFLAGS += $(if $(PC

Unique ID for PROXYv2: Get 'struct stream' from 'struct connection'

2020-02-21 Thread Tim Düsterhus

Hi List

I'm currently attempting to extend Proxy Protocol v2 by a new TLV to
send a unique ID for TCP connections, similar to the unique-id-header
for HTTP.

I'm currently struggling to get the `struct stream` within
`make_proxy_line_v2`. I could find out that I can get the `struct
session` via `remote->owner`, but from there I have no idea how to get a
`struct stream`. By printing the allocations it appears that a stream
should already exist by the time the proxy line is sent.

So questions:
1. Would it generally work to send a unique ID within the proxy line or
will that cause issues?
2. How can I grab the `struct stream` from the `struct connection
remote` or more general: How can I get the correct `struct stream` from
within `make_proxy_line_v2`?

Best regards
Tim Düsterhus

RE: haproxy 2.1.2 and 2.1.3

2020-02-21 Thread marcel.kloosterman

Hi,

It's not working on test-server also.
Test-server is a solaris zone on T7 with 11.4 sru 950, production is a solaris 
zone on T8 with 11.4 sru 950.

What I also tried is:

root@SYSTEM:~# gdb
GNU gdb (GDB) 8.0
Copyright (C) 2017 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 "sparc-sun-solaris2.11".
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".
(gdb) exec-file
No executable file now.
(gdb) exec-file /usr/local/sbin/haproxy
(gdb) run -p /tmp/haproxy.pid -f /usr/local/etc/haproxy.cfg
Starting program: /usr/local/sbin/haproxy -p /tmp/haproxy.pid -f 
/usr/local/etc/haproxy.cfg
[Thread debugging using libthread_db enabled]
[New Thread 1 (LWP 1)]

Thread 2 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1 (LWP 1)]
0x000100242c90 in ?? ()
(gdb) bt full
#0  0x000100242c90 in ?? ()
No symbol table info available.
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

As already stated in the other mail. I'm not really familiar with gdb. 
Can you guide me.

Met vriendelijke groet/Kind regards,

Marcel Kloosterman
Specialist Technisch Beheer

KPN
N&I ACN P&TDC DC Cloud 1

Phone: +31612413284
Email: marcel.klooster...@kpn.com
TeamWiki (with spoc planning): 
https://confluence.kpn.org/display/KDU/KPN+DCLOUD+SOLARIS+CLOUD+TEAM+HOMEPAGE
(JIRA access is required and can be requested using IAM portal)
BTW nr.: NL0092.92.056B01
KvK: 27124701

The information transmitted is intended only for use by the addressee and may 
contain confidential and/or privileged material. Any review, re-transmission, 
dissemination or other use of it, or the taking of any action in reliance upon 
this information by persons and/or entities other than the intended recipient 
is prohibited. If you received this in error, please inform the sender and/or 
addressee immediately and delete the material. Thank you.

-Oorspronkelijk bericht-
Van: William Lallemand  
Verzonden: vrijdag 21 februari 2020 10:55
Aan: Kloosterman, Marcel 
CC: haproxy@formilux.org
Onderwerp: Re: haproxy 2.1.2 and 2.1.3

Hello,

On Fri, Feb 21, 2020 at 08:52:05AM +, marcel.klooster...@kpn.com wrote:
> Hi all,
> 
> At this moment we’re using  HA-Proxy version 2.0.0 2019/06/16 - 
> https://haproxy.org/ And we’re running solaris 11.4 sru 950 for SPARC and I 
> used developer studio version 12.6 to compile the newer versions and 12.5 to 
> compile the 2.0.0 version.
> 
> And because of a known bug in haproxy, we wanted to upgrade to: 
> HA-Proxy version 2.1.2 2019/12/21 - https://haproxy.org/ On our test-server 
> we had no problems but on the production server it kept crashing.
> The problem is somehow related to ssl, because as soon as we add “ssl crt 
> /etc/certs/self.pem” to the bind it crashes also on the test-server.
> So then I checked and version 2.1.3 is already available, solving lots 
> of ssl bugs. So I tried that one also…but without any luck ☹
> 
> Starting haproxy now gives a Bus Error (with both versons, 2.1.2 and 2.1.3):
> 
> root@sz4203:~ # /usr/local/sbin/haproxy -p /tmp/haproxy.pid -f 
> /usr/local/etc/haproxy.cfg Bus Error (core dumped)
> 
> Can you please help me solving this issue ?
> 
> This is the stack-dump of the 2.1.3 version I compiled:
> root@s00501:/var/core# pstack core_sz4203_haproxy_0_0_1582273479_18461
> core 'core_sz4203_haproxy_0_0_1582273479_18461' of 18461:   
> /usr/local/sbin/haproxy -p /tmp/haproxy.pid -f /usr/local/etc/haproxy.
> 000100240c30 shctx_init (100366170, 4e20, c4, , 
> 7ec00144, 0) + b0 (shctx.c:368) 000100086e7c 
> ssl_sock_prepare_bind_conf (1005bbb80, , fffefffc, 
> 29729948, , 100366000) + 1bc
> 000100135278 check_config_validity (fffefffc, 1400, 
> 1005bbb80, 1005bb750, 100357238, 0) + 25b8 (cfgparse.c:3753)
> 000100173450 init (100357468, 1000596a0, 10005a940, 100357238, 
> 10003aa90, 0) + 610 (haproxy.c:1884)
> 000100178058 main (5, 7688, 76b8, 10, 
> 10046d680, 0) + 178 (haproxy.c:2858)
> 00010006caa4 _start (0, 0, 0, 0, 0, 0) + 64
> 

That's really odd, what is crashing is the shctx_init(), which is the 
initialization of the shared memory used by the SSL, it didn't changed much in 
2 years so I'm surprised that you didn't have this problem with haproxy 2.0.

Since its running on SPARC and that the Bus Error appears in the the shctx 
block access that could be an alignment issue.
But if i

Re: haproxy 2.1.2 and 2.1.3

2020-02-21 Thread Miroslav Zagorac


On 02/21/2020 11:42 AM, marcel.klooster...@kpn.com wrote:

Hi,

It's not working on test-server also.
Test-server is a solaris zone on T7 with 11.4 sru 950, production is a solaris 
zone on T8 with 11.4 sru 950.



You can start gdb like this:

% gdb -core core-file program

, and in your case it would look like this:

% gdb -core core_sz4203_haproxy_0_0_1582273479_18461 /usr/local/sbin/haproxy

After that, in gdb program you write command 'where' (without quotes),
which will print backtrace of all stack frames.  It will work better if 
you have debug symbols included in the program you want to debug.  :)


--
Zaga

What can change the nature of a man?

Re: haproxy 2.1.2 and 2.1.3

2020-02-21 Thread Tim Düsterhus

Miroslav,

Am 21.02.20 um 12:22 schrieb Miroslav Zagorac:
> You can start gdb like this:
> 
> % gdb -core core-file program
> 
> , and in your case it would look like this:
> 
> % gdb -core core_sz4203_haproxy_0_0_1582273479_18461
> /usr/local/sbin/haproxy
> 
> After that, in gdb program you write command 'where' (without quotes),
> which will print backtrace of all stack frames.  It will work better if
> you have debug symbols included in the program you want to debug.  :)
> 

I order to save you duplicated effort in helping I'd like to let you
know that Marcel also created a GitHub issue upon request from Ilya:

https://github.com/haproxy/haproxy/issues/512

Best regards
Tim Düsterhus

RE: haproxy 2.1.2 and 2.1.3

2020-02-21 Thread marcel.kloosterman

Hi all,

I tried to recompile all previously compiled haproxy version.
All gave same output during compilation, but all newly compiled versions do not 
seem to work...

As far as I can see in my history I compiled haproxy 2.0.0 with gcc version 
4.8.2:

root@SYSTEM:/export/home/USER/haproxy-2.0.0# gcc --version
gcc (GCC) 4.8.2
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

And now it's using 7.3.0:
root@sz4203:/export/home/bhr_kloos605/haproxy-2.0.0# gcc --version
gcc (GCC) 7.3.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Not sure if that could be of any impact...

Met vriendelijke groet/Kind regards,

Marcel Kloosterman
Specialist Technisch Beheer

KPN
N&I ACN P&TDC DC Cloud 1

Phone: +31612413284
Email: marcel.klooster...@kpn.com
TeamWiki (with spoc planning): 
https://confluence.kpn.org/display/KDU/KPN+DCLOUD+SOLARIS+CLOUD+TEAM+HOMEPAGE
(JIRA access is required and can be requested using IAM portal)
BTW nr.: NL0092.92.056B01
KvK: 27124701

The information transmitted is intended only for use by the addressee and may 
contain confidential and/or privileged material. Any review, re-transmission, 
dissemination or other use of it, or the taking of any action in reliance upon 
this information by persons and/or entities other than the intended recipient 
is prohibited. If you received this in error, please inform the sender and/or 
addressee immediately and delete the material. Thank you.

-Oorspronkelijk bericht-
Van: William Lallemand  
Verzonden: vrijdag 21 februari 2020 10:55
Aan: Kloosterman, Marcel 
CC: haproxy@formilux.org
Onderwerp: Re: haproxy 2.1.2 and 2.1.3

Hello,

On Fri, Feb 21, 2020 at 08:52:05AM +, marcel.klooster...@kpn.com wrote:
> Hi all,
> 
> At this moment we’re using  HA-Proxy version 2.0.0 2019/06/16 - 
> https://haproxy.org/ And we’re running solaris 11.4 sru 950 for SPARC and I 
> used developer studio version 12.6 to compile the newer versions and 12.5 to 
> compile the 2.0.0 version.
> 
> And because of a known bug in haproxy, we wanted to upgrade to: 
> HA-Proxy version 2.1.2 2019/12/21 - https://haproxy.org/ On our test-server 
> we had no problems but on the production server it kept crashing.
> The problem is somehow related to ssl, because as soon as we add “ssl crt 
> /etc/certs/self.pem” to the bind it crashes also on the test-server.
> So then I checked and version 2.1.3 is already available, solving lots 
> of ssl bugs. So I tried that one also…but without any luck ☹
> 
> Starting haproxy now gives a Bus Error (with both versons, 2.1.2 and 2.1.3):
> 
> root@sz4203:~ # /usr/local/sbin/haproxy -p /tmp/haproxy.pid -f 
> /usr/local/etc/haproxy.cfg Bus Error (core dumped)
> 
> Can you please help me solving this issue ?
> 
> This is the stack-dump of the 2.1.3 version I compiled:
> root@s00501:/var/core# pstack core_sz4203_haproxy_0_0_1582273479_18461
> core 'core_sz4203_haproxy_0_0_1582273479_18461' of 18461:   
> /usr/local/sbin/haproxy -p /tmp/haproxy.pid -f /usr/local/etc/haproxy.
> 000100240c30 shctx_init (100366170, 4e20, c4, , 
> 7ec00144, 0) + b0 (shctx.c:368) 000100086e7c 
> ssl_sock_prepare_bind_conf (1005bbb80, , fffefffc, 
> 29729948, , 100366000) + 1bc
> 000100135278 check_config_validity (fffefffc, 1400, 
> 1005bbb80, 1005bb750, 100357238, 0) + 25b8 (cfgparse.c:3753)
> 000100173450 init (100357468, 1000596a0, 10005a940, 100357238, 
> 10003aa90, 0) + 610 (haproxy.c:1884)
> 000100178058 main (5, 7688, 76b8, 10, 
> 10046d680, 0) + 178 (haproxy.c:2858)
> 00010006caa4 _start (0, 0, 0, 0, 0, 0) + 64
> 

That's really odd, what is crashing is the shctx_init(), which is the 
initialization of the shared memory used by the SSL, it didn't changed much in 
2 years so I'm surprised that you didn't have this problem with haproxy 2.0.

Since its running on SPARC and that the Bus Error appears in the the shctx 
block access that could be an alignment issue.
But if it's working on your test server it might be something else. Do the test 
server and the production one share the same hardware?
(CPU, RAM etc.)

Could you display the stacktrace with gdb? The arguments looks weird to me, 
(too much arguments and weird values) and I don't know how reliable is pstack 
about this.

Did you try to build haproxy 2.0 with your new compiler and do the same tests? 
Do you have the same issue?

--
William Lallemand

Re: haproxy 2.1.2 and 2.1.3

2020-02-21 Thread Miroslav Zagorac


On 02/21/2020 12:32 PM, Tim Düsterhus wrote:

Miroslav,

I order to save you duplicated effort in helping I'd like to let you
know that Marcel also created a GitHub issue upon request from Ilya:

https://github.com/haproxy/haproxy/issues/512


Hello Tim,

ah.. okay, i missed that. Thank you.  :)


Best regards,

--
Zaga

What can change the nature of a man?

Re: [PATCH] BUG/MINOR: cfgparse: Fix type of second calloc() parameter

2020-02-21 Thread Tim Düsterhus

Willy,

Am 16.02.20 um 12:36 schrieb Tim Düsterhus:
>> instead of sizeof(*pointer) because these are hard to find the day the
>> type changes and can cause bugs later.
>>
>> So I'd rather tag it as cleanup and not backport it since it will not
>> change the output code.
> 
> I'm fine with that.

I expected you to simply adjust the commit message. Are you waiting for
an updated patch from me?

Best regards
Tim Düsterhus

[PATCH 0/2] Stop negating (un|)likely

2020-02-21 Thread Tim Duesterhus

Willy,

I'm not sure whether there is a deeper purpose behind the old versions, but
I found them hard to read when stumbling upon them in the code. Especially
the ones in net_helper.

Please carefully check that I did not break anything and that the intended
optimizations still apply.

Best regards

Tim Duesterhus (2):
  CLEANUP: conn: Do not pass a pointer to likely
  CLEANUP: net_helper: Do not negate the result of unlikely

 include/common/net_helper.h | 8 
 include/proto/connection.h  | 4 ++--
 2 files changed, 6 insertions(+), 6 deletions(-)

-- 
2.25.1

[PATCH 1/2] CLEANUP: conn: Do not pass a pointer to likely

2020-02-21 Thread Tim Duesterhus

Move the `!` inside the likely and negate it to unlikely.

The previous version should not have caused issues, because it is converted
to a boolean / integral value before being passed to __builtin_expect(), but
it's certainly unusual.
---
 include/proto/connection.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/proto/connection.h b/include/proto/connection.h
index c7caeea2b..fb264d2b5 100644
--- a/include/proto/connection.h
+++ b/include/proto/connection.h
@@ -400,12 +400,12 @@ static inline struct conn_stream *cs_new(struct 
connection *conn)
struct conn_stream *cs;
 
cs = pool_alloc(pool_head_connstream);
-   if (!likely(cs))
+   if (unlikely(!cs))
return NULL;
 
if (!conn) {
conn = conn_new();
-   if (!likely(conn)) {
+   if (unlikely(!conn)) {
cs_free(cs);
return NULL;
}
-- 
2.25.1

[PATCH 2/2] CLEANUP: net_helper: Do not negate the result of unlikely

2020-02-21 Thread Tim Duesterhus

This patch turns the double negation of 'not unlikely' into 'likely'
and then turns the negation of 'not smaller' into 'greater or equal'
in an attempt to improve readability of the condition.
---
 include/common/net_helper.h | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/include/common/net_helper.h b/include/common/net_helper.h
index 9b22d773f..0443fe1f9 100644
--- a/include/common/net_helper.h
+++ b/include/common/net_helper.h
@@ -172,7 +172,7 @@ static inline uint32_t readv_u32(const void *p1, size_t s1, 
const void *p2)
 {
uint32_t u32;
 
-   if (!unlikely(s1 < sizeof(u32)))
+   if (likely(s1 >= sizeof(u32)))
u32 = read_u32(p1);
else
readv_bytes(&u32, sizeof(u32), p1, s1, p2);
@@ -186,7 +186,7 @@ static inline uint32_t readv_u32(const void *p1, size_t s1, 
const void *p2)
  */
 static inline void writev_u32(void *p1, size_t s1, void *p2, const uint32_t 
u32)
 {
-   if (!unlikely(s1 < sizeof(u32)))
+   if (likely(s1 >= sizeof(u32)))
write_u32(p1, u32);
else
writev_bytes(&u32, sizeof(u32), p1, s1, p2);
@@ -201,7 +201,7 @@ static inline uint64_t readv_u64(const void *p1, size_t s1, 
const void *p2)
 {
uint64_t u64;
 
-   if (!unlikely(s1 < sizeof(u64)))
+   if (likely(s1 >= sizeof(u64)))
u64 = read_u64(p1);
else
readv_bytes(&u64, sizeof(u64), p1, s1, p2);
@@ -215,7 +215,7 @@ static inline uint64_t readv_u64(const void *p1, size_t s1, 
const void *p2)
  */
 static inline void writev_u64(void *p1, size_t s1, void *p2, const uint64_t 
u64)
 {
-   if (!unlikely(s1 < sizeof(u64)))
+   if (likely(s1 >= sizeof(u64)))
write_u64(p1, u64);
else
writev_bytes(&u64, sizeof(u64), p1, s1, p2);
-- 
2.25.1

Re: Segfault on HAProxy 2.0.11 on HTX mode

2020-02-21 Thread Christopher Faulet


Le 19/02/2020 à 11:35, Olivier D a écrit :

Hello,

I would like to report a segfault on HAProxy 2.0.11 ; this version has been 
running fine for two months, and this morning starting segfaulting over and over.

Mitigation was performed by adding "no option http-use-htx" on 'defaults' block.

I know it's not the latest version :) I'll update to 2.0.13 this evening.

Program terminated with signal 11, Segmentation fault.
#0  htx_sl_p2 (sl=) at include/common/htx.h:293
293     include/common/htx.h: No such file or directory.
(gdb) bt
#0  htx_sl_p2 (sl=) at include/common/htx.h:293
#1  htx_sl_req_uri (sl=) at include/common/htx.h:308
#2  assign_server (s=0xdc139f0) at src/backend.c:746
#3  0x00552114 in assign_server_and_queue (s=s@entry=0xdc139f0) at 
src/backend.c:977
#4  0x005556f8 in assign_server_and_queue (s=0xdc139f0) at 
src/backend.c:1772

#5  srv_redispatch_connect (s=s@entry=0xdc139f0) at src/backend.c:1705
#6  0x004c2cf8 in sess_prepare_conn_req (s=) at 
src/stream.c:1250
#7  process_stream (t=t@entry=0xd1db790, context=0xdc139f0, state=out>) at src/stream.c:2414

#8  0x00594865 in process_runnable_tasks () at src/task.c:412
#9  0x005038f7 in run_poll_loop () at src/haproxy.c:2520
#10 run_thread_poll_loop (data=data@entry=0x0) at src/haproxy.c:2641
#11 0x004653b0 in main (argc=, argv=0x7fff848ae498) at 
src/haproxy.c:3318




Hi all,

This bug was fixed (commit 9d9d64540) and backported as far as 1.9. The crash 
was happening when a client error was encountered for a tarpitted connection 
with an HTTP load-balancing algorithm configured on the backend (for instance, 
balance uri).


Thanks to Olivier for his help,

--
Christopher Faulet

Re: [PATCH 0/2] Stop negating (un|)likely

2020-02-21 Thread Willy Tarreau

Hi Tim,

On Fri, Feb 21, 2020 at 01:02:02PM +0100, Tim Duesterhus wrote:
> Willy,
> 
> I'm not sure whether there is a deeper purpose behind the old versions, but
> I found them hard to read when stumbling upon them in the code. Especially
> the ones in net_helper.

I agree. There was a reason for this, which is described in compiler.h.
Gcc 4.x (at least 4.0 to 4.2) used to do totally stupid things on this:

if (__builtin_expect((x) != 0, 1))
foo();
else
bar();

In short, they would compare x to 0, build an integer 0 or 1 based on this
and compare the result against 1 before doing the jump! So by doing

if (likely(a == NULL))

we were actually doubling the test! It was doing something like this:

  cmp %rdi, $1
  sbb %rax, %rax
  and %rax, $1
  cmp %rax, $1
  jne unlikely_branch
likely_branch:
  ...
unlikely_branch:
  ...

The 3 instructions from sbb to cmp were only needed to build the value
1 to compare against in __builtin_expect()! The unlikely code used to
only do this:

  test %rdi, %rdi
  je unlikely_branch
likely_branch:
  ...
unlikely_branch:
  ...

Worse, by inflating the code, it was clobbering more registers and
preventing some parts from being inlined. However for unlikely() it was
not a problem as the comparison to zero doesn't require an intermediate
result. I tried to make likely(x)=!unlikely(!x) but that also resulted
in emitting extra code. Thus I decided to simply make likely(x) do
nothing for such versions since in most cases it's not critical, but
there were still some places where I really wanted to optimize the path
after seeing the output code. This problem didn't exist for 3.x nor 5.x.
This was in 2008...

I have retested now with 4.4, 4.7, 4.8, 5.5, 7.4 and 8.2 and the
problem seems to be definitely gone. I even think that we could remove
the special case in the code, I'll do it.

> Please carefully check that I did not break anything and that the intended
> optimizations still apply.

At first glance, your change looks OK, I'll take it.

Thanks!
Willy

Re: [PATCH] BUG/MINOR: cfgparse: Fix type of second calloc() parameter

2020-02-21 Thread Willy Tarreau

On Fri, Feb 21, 2020 at 12:59:53PM +0100, Tim Düsterhus wrote:
> Willy,
> 
> Am 16.02.20 um 12:36 schrieb Tim Düsterhus:
> >> instead of sizeof(*pointer) because these are hard to find the day the
> >> type changes and can cause bugs later.
> >>
> >> So I'd rather tag it as cleanup and not backport it since it will not
> >> change the output code.
> > 
> > I'm fine with that.
> 
> I expected you to simply adjust the commit message. Are you waiting for
> an updated patch from me?

Well I don't know, I'd have to re-check, thus... as you prefer :-) That's
exactly the problem when I'm being assigned some work I cannot instantly
complete and that is not tracked anywhere, I leave it in my mailbox hoping
to find the time to work on it quickly, and if that does not happen, the
mail disappears from my visible window and I forget.

Willy

haproxy 2.1.2 and 2.1.3

Re: haproxy 2.1.2 and 2.1.3

Re: haproxy 2.1.2 and 2.1.3

RE: haproxy 2.1.2 and 2.1.3

Unique ID for PROXYv2: Get 'struct stream' from 'struct connection'

RE: haproxy 2.1.2 and 2.1.3

Re: haproxy 2.1.2 and 2.1.3

Re: haproxy 2.1.2 and 2.1.3

RE: haproxy 2.1.2 and 2.1.3

Re: haproxy 2.1.2 and 2.1.3

Re: [PATCH] BUG/MINOR: cfgparse: Fix type of second calloc() parameter

[PATCH 0/2] Stop negating (un|)likely

[PATCH 1/2] CLEANUP: conn: Do not pass a pointer to likely

[PATCH 2/2] CLEANUP: net_helper: Do not negate the result of unlikely

Re: Segfault on HAProxy 2.0.11 on HTX mode

Re: [PATCH 0/2] Stop negating (un|)likely

Re: [PATCH] BUG/MINOR: cfgparse: Fix type of second calloc() parameter

17 matches

Site Navigation

Mail list logo

Footer information