date:20180615

Re: remaining process after (seamless) reload

2018-06-15 Thread William Dauchy

Hello,

Thanks for your answer. Here are the information requested.

On Fri, Jun 15, 2018 at 11:22 AM William Lallemand
 wrote:
> - haproxy -vv

HA-Proxy version 1.8.9-83616ec 2018/05/18
Copyright 2000-2018 Willy Tarreau 

Build options :
  TARGET  = linux2628
  CPU = generic
  CC  = gcc
  CFLAGS  = -O2 -g -fno-strict-aliasing -Wdeclaration-after-statement
-fwrapv -fno-strict-overflow -Wno-unused-label -DTCP_USER_TIMEOUT=18
  OPTIONS = USE_LINUX_TPROXY=1 USE_GETADDRINFO=1 USE_ZLIB=1
USE_REGPARM=1 USE_OPENSSL=1 USE_SYSTEMD=1 USE_PCRE=1 USE_PCRE_JIT=1
USE_TFO=1 USE_NS=1

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

Built with OpenSSL version : OpenSSL 1.0.2k-fips  26 Jan 2017
Running on OpenSSL version : OpenSSL 1.0.2k-fips  26 Jan 2017
OpenSSL library supports TLS extensions : yes
OpenSSL library supports SNI : yes
OpenSSL library supports : SSLv3 TLSv1.0 TLSv1.1 TLSv1.2
Built with transparent proxy support using: IP_TRANSPARENT
IPV6_TRANSPARENT IP_FREEBIND
Encrypted password support via crypt(3): yes
Built with multi-threading support.
Built with PCRE version : 8.32 2012-11-30
Running on PCRE version : 8.32 2012-11-30
PCRE library supports JIT : yes
Built with zlib version : 1.2.7
Running on zlib version : 1.2.7
Compression algorithms supported : identity("identity"),
deflate("deflate"), raw-deflate("deflate"), gzip("gzip")
Built with network namespace 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 filters :
[SPOE] spoe
[COMP] compression
[TRACE] trace

> - distribution  w/ glibc version and kernel

CentOS Linux release 7.4.1708 (Core)
glibc:  2.17-196.el7_4.2
kernel: 4.13.16 (I know it is out of support as of today :/)

> - compiler version

gcc centos package: 4.8.5-16.el7_4.2

I will try to come up with more information or reproducer if I can find one.
-- 
William

Re: [PATCH] BUG/MINOR: lua: Segfaults with wrong usage of types.

2018-06-15 Thread Patrick Hemmer



On 2018/6/15 09:06, Frederic Lecaille wrote:
> On 06/15/2018 02:28 PM, Frederic Lecaille wrote:
>> On 06/15/2018 02:15 PM, Frederic Lecaille wrote:
>>> On 06/14/2018 11:05 PM, Patrick Hemmer wrote:
 Haproxy segfaults if you pass the wrong argument type to a converter.
 Example:

 haproxy.cfg:
  global
  lua-load /tmp/haproxy.lua

  frontend f1
  mode http
  bind :8000
  default_backend b1

  http-request lua.foo

  backend b1
  mode http
  server s1 127.0.0.1:8080

 haproxy.lua:
  core.register_action("foo", { "http-req" }, function(txn)
  txn.sc:ipmask(txn.f:src(), 24, 112)
  end)

 Result:
  * thread #1, queue = 'com.apple.main-thread', stop reason =
 EXC_BAD_ACCESS (code=1, address=0x18)
  frame #0: 0x7fffc9fcbf56
 libsystem_platform.dylib`_platform_memmove$VARIANT$Haswell + 182
 libsystem_platform.dylib`_platform_memmove$VARIANT$Haswell:
  ->  0x7fffc9fcbf56 <+182>: movb   (%rsi,%r8), %cl
  0x7fffc9fcbf5a <+186>: movb   %cl, (%rdi,%r8)
  0x7fffc9fcbf5e <+190>: subq   $0x1, %rdx
  0x7fffc9fcbf62 <+194>: je 0x7fffc9fcbf78; <+216>
  Target 0: (haproxy) stopped.
  (lldb) bt
  * thread #1, queue = 'com.apple.main-thread', stop reason =
 EXC_BAD_ACCESS (code=1, address=0x18)
* frame #0: 0x7fffc9fcbf56
 libsystem_platform.dylib`_platform_memmove$VARIANT$Haswell + 182
  frame #1: 0x7fffc9e7442e
 libsystem_c.dylib`__memcpy_chk + 22
  frame #2: 0x00010002ec46
 haproxy`hlua_lua2arg_check(L=0x00010120d298, first=3,
 argp=0x7fff5fbfe690, mask=196, p=0x000101817000) at hlua.c:749
  frame #3: 0x00010001fa00
 haproxy`hlua_run_sample_conv(L=0x00010120d298) at hlua.c:3393
  frame #4: 0x00010032400b haproxy`luaD_precall + 747
  frame #5: 0x0001003343c6 haproxy`luaV_execute + 3158
  frame #6: 0x000100323429 haproxy`luaD_rawrunprotected
 + 89
  frame #7: 0x000100324516 haproxy`lua_resume + 278
  frame #8: 0x00010001b199
 haproxy`hlua_ctx_resume(lua=0x000101205080, yield_allowed=1) at
 hlua.c:1080
  frame #9: 0x000100027de8
 haproxy`hlua_action(rule=0x00010101b180, px=0x000101817000,
 sess=0x00010120cb70, s=0x00010120cc00, flags=2) at hlua.c:6198
  frame #10: 0x000100044bcd
 haproxy`http_req_get_intercept_rule(px=0x000101817000,
 rules=0x000101817048, s=0x00010120cc00,
 deny_status=0x7fff5fbfee78) at proto_http.c:2760
  frame #11: 0x000100046182
 haproxy`http_process_req_common(s=0x00010120cc00,
 req=0x00010120cc10, an_bit=16, px=0x000101817000) at
 proto_http.c:3461
  frame #12: 0x000100094c50
 haproxy`process_stream(t=0x00010120cf40,
 context=0x00010120cc00, state=9) at stream.c:1905
  frame #13: 0x00010016179f
 haproxy`process_runnable_tasks at task.c:362
  frame #14: 0x0001000ea0eb haproxy`run_poll_loop at
 haproxy.c:2403
  frame #15: 0x0001000e7c74
 haproxy`run_thread_poll_loop(data=0x7fff5fbff3a4) at
 haproxy.c:2464
  frame #16: 0x0001000e4a49 haproxy`main(argc=3,
 argv=0x7fff5fbff590) at haproxy.c:3082
  frame #17: 0x7fffc9db9235 libdyld.dylib`start + 1

 Issue goes away if you change the lua txn.sc:ipmask() line to:
  txn.sc:ipmask(txn.f:src(), '24', '112')

 Reproduced with current master (9db0fed) and lua version 5.3.4.

 -Patrick
>>>
>>> It seems the patch attached to this mail fixes this issue. It at
>>> least make the varnishtest test file pass.
>>>
>>> Must be checked by Thierry.
>>
>> Should have mentionned that I could not reproduce this issue without
>> compiling the thread support (USE_THREAD=1).
>
> There is potentially the same issue in hlua_run_sample_conv(). See the
> updated patch attached to this mail.
>
>
I can confirm this patch addresses the segfault for my use case.

Thanks

-Patrick

[PATCH] BUG/MINOR: lua: Segfaults with wrong usage of types.

2018-06-15 Thread Frederic Lecaille


On 06/15/2018 02:28 PM, Frederic Lecaille wrote:

On 06/15/2018 02:15 PM, Frederic Lecaille wrote:

On 06/14/2018 11:05 PM, Patrick Hemmer wrote:

Haproxy segfaults if you pass the wrong argument type to a converter.
Example:

haproxy.cfg:
 global
     lua-load /tmp/haproxy.lua

 frontend f1
     mode http
     bind :8000
     default_backend b1

     http-request lua.foo

 backend b1
     mode http
     server s1 127.0.0.1:8080

haproxy.lua:
 core.register_action("foo", { "http-req" }, function(txn)
     txn.sc:ipmask(txn.f:src(), 24, 112)
 end)

Result:
 * thread #1, queue = 'com.apple.main-thread', stop reason = 
EXC_BAD_ACCESS (code=1, address=0x18)
 frame #0: 0x7fffc9fcbf56 
libsystem_platform.dylib`_platform_memmove$VARIANT$Haswell + 182

libsystem_platform.dylib`_platform_memmove$VARIANT$Haswell:
 ->  0x7fffc9fcbf56 <+182>: movb   (%rsi,%r8), %cl
 0x7fffc9fcbf5a <+186>: movb   %cl, (%rdi,%r8)
 0x7fffc9fcbf5e <+190>: subq   $0x1, %rdx
 0x7fffc9fcbf62 <+194>: je 0x7fffc9fcbf78    ; <+216>
 Target 0: (haproxy) stopped.
 (lldb) bt
 * thread #1, queue = 'com.apple.main-thread', stop reason = 
EXC_BAD_ACCESS (code=1, address=0x18)
   * frame #0: 0x7fffc9fcbf56 
libsystem_platform.dylib`_platform_memmove$VARIANT$Haswell + 182
 frame #1: 0x7fffc9e7442e libsystem_c.dylib`__memcpy_chk 
+ 22
 frame #2: 0x00010002ec46 
haproxy`hlua_lua2arg_check(L=0x00010120d298, first=3, 
argp=0x7fff5fbfe690, mask=196, p=0x000101817000) at hlua.c:749
 frame #3: 0x00010001fa00 
haproxy`hlua_run_sample_conv(L=0x00010120d298) at hlua.c:3393

 frame #4: 0x00010032400b haproxy`luaD_precall + 747
 frame #5: 0x0001003343c6 haproxy`luaV_execute + 3158
 frame #6: 0x000100323429 haproxy`luaD_rawrunprotected + 89
 frame #7: 0x000100324516 haproxy`lua_resume + 278
 frame #8: 0x00010001b199 
haproxy`hlua_ctx_resume(lua=0x000101205080, yield_allowed=1) at 
hlua.c:1080
 frame #9: 0x000100027de8 
haproxy`hlua_action(rule=0x00010101b180, px=0x000101817000, 
sess=0x00010120cb70, s=0x00010120cc00, flags=2) at hlua.c:6198
 frame #10: 0x000100044bcd 
haproxy`http_req_get_intercept_rule(px=0x000101817000, 
rules=0x000101817048, s=0x00010120cc00, 
deny_status=0x7fff5fbfee78) at proto_http.c:2760
 frame #11: 0x000100046182 
haproxy`http_process_req_common(s=0x00010120cc00, 
req=0x00010120cc10, an_bit=16, px=0x000101817000) at 
proto_http.c:3461
 frame #12: 0x000100094c50 
haproxy`process_stream(t=0x00010120cf40, 
context=0x00010120cc00, state=9) at stream.c:1905
 frame #13: 0x00010016179f haproxy`process_runnable_tasks 
at task.c:362
 frame #14: 0x0001000ea0eb haproxy`run_poll_loop at 
haproxy.c:2403
 frame #15: 0x0001000e7c74 
haproxy`run_thread_poll_loop(data=0x7fff5fbff3a4) at haproxy.c:2464
 frame #16: 0x0001000e4a49 haproxy`main(argc=3, 
argv=0x7fff5fbff590) at haproxy.c:3082

 frame #17: 0x7fffc9db9235 libdyld.dylib`start + 1

Issue goes away if you change the lua txn.sc:ipmask() line to:
 txn.sc:ipmask(txn.f:src(), '24', '112')

Reproduced with current master (9db0fed) and lua version 5.3.4.

-Patrick


It seems the patch attached to this mail fixes this issue. It at least 
make the varnishtest test file pass.


Must be checked by Thierry.


Should have mentionned that I could not reproduce this issue without 
compiling the thread support (USE_THREAD=1).


There is potentially the same issue in hlua_run_sample_conv(). See the 
updated patch attached to this mail.





>From e3efb02b48098aad6d4694d06bb4c3193f29e312 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Fr=C3=A9d=C3=A9ric=20L=C3=A9caille?= 
Date: Fri, 15 Jun 2018 13:56:04 +0200
Subject: [PATCH] BUG/MINOR: lua: Segfaults with wrong usage of types.

Patrick reported that this simple configuration made haproxy segfaults:

global
lua-load /tmp/haproxy.lua

frontend f1
mode http
bind :8000
default_backend b1

http-request lua.foo

backend b1
mode http
server s1 127.0.0.1:8080

with this '/tmp/haproxy.lua' script:

core.register_action("foo", { "http-req" }, function(txn)
txn.sc:ipmask(txn.f:src(), 24, 112)
end)

This is due to missing initialization of the array of arguments
passed to hlua_lua2arg_check() which makes it enter code with
corrupted arguments.

Thanks a lot to Patrick Hemmer for having reported this issue.

Must be backported to 1.8, 1.7 and 1.6.
---
 src/hlua.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/hlua.c b/src/hlua.c
index 716bd29..93ec44c 100644
--- a/src/hlua.c
+++ b/src/hlua.c
@@ -3256,7 +3256,7 @@ __LJMP static int hlua_run_sample_fetch(lua_State *L)
 {

Re: BUG: segfault with lua sample converters & wrong arg types

2018-06-15 Thread Frederic Lecaille


On 06/15/2018 02:15 PM, Frederic Lecaille wrote:

On 06/14/2018 11:05 PM, Patrick Hemmer wrote:

Haproxy segfaults if you pass the wrong argument type to a converter.
Example:

haproxy.cfg:
 global
     lua-load /tmp/haproxy.lua

 frontend f1
     mode http
     bind :8000
     default_backend b1

     http-request lua.foo

 backend b1
     mode http
     server s1 127.0.0.1:8080

haproxy.lua:
 core.register_action("foo", { "http-req" }, function(txn)
     txn.sc:ipmask(txn.f:src(), 24, 112)
 end)

Result:
 * thread #1, queue = 'com.apple.main-thread', stop reason = 
EXC_BAD_ACCESS (code=1, address=0x18)
 frame #0: 0x7fffc9fcbf56 
libsystem_platform.dylib`_platform_memmove$VARIANT$Haswell + 182

libsystem_platform.dylib`_platform_memmove$VARIANT$Haswell:
 ->  0x7fffc9fcbf56 <+182>: movb   (%rsi,%r8), %cl
 0x7fffc9fcbf5a <+186>: movb   %cl, (%rdi,%r8)
 0x7fffc9fcbf5e <+190>: subq   $0x1, %rdx
 0x7fffc9fcbf62 <+194>: je 0x7fffc9fcbf78    ; <+216>
 Target 0: (haproxy) stopped.
 (lldb) bt
 * thread #1, queue = 'com.apple.main-thread', stop reason = 
EXC_BAD_ACCESS (code=1, address=0x18)
   * frame #0: 0x7fffc9fcbf56 
libsystem_platform.dylib`_platform_memmove$VARIANT$Haswell + 182

 frame #1: 0x7fffc9e7442e libsystem_c.dylib`__memcpy_chk + 22
 frame #2: 0x00010002ec46 
haproxy`hlua_lua2arg_check(L=0x00010120d298, first=3, 
argp=0x7fff5fbfe690, mask=196, p=0x000101817000) at hlua.c:749
 frame #3: 0x00010001fa00 
haproxy`hlua_run_sample_conv(L=0x00010120d298) at hlua.c:3393

 frame #4: 0x00010032400b haproxy`luaD_precall + 747
 frame #5: 0x0001003343c6 haproxy`luaV_execute + 3158
 frame #6: 0x000100323429 haproxy`luaD_rawrunprotected + 89
 frame #7: 0x000100324516 haproxy`lua_resume + 278
 frame #8: 0x00010001b199 
haproxy`hlua_ctx_resume(lua=0x000101205080, yield_allowed=1) at 
hlua.c:1080
 frame #9: 0x000100027de8 
haproxy`hlua_action(rule=0x00010101b180, px=0x000101817000, 
sess=0x00010120cb70, s=0x00010120cc00, flags=2) at hlua.c:6198
 frame #10: 0x000100044bcd 
haproxy`http_req_get_intercept_rule(px=0x000101817000, 
rules=0x000101817048, s=0x00010120cc00, 
deny_status=0x7fff5fbfee78) at proto_http.c:2760
 frame #11: 0x000100046182 
haproxy`http_process_req_common(s=0x00010120cc00, 
req=0x00010120cc10, an_bit=16, px=0x000101817000) at 
proto_http.c:3461
 frame #12: 0x000100094c50 
haproxy`process_stream(t=0x00010120cf40, 
context=0x00010120cc00, state=9) at stream.c:1905
 frame #13: 0x00010016179f haproxy`process_runnable_tasks 
at task.c:362
 frame #14: 0x0001000ea0eb haproxy`run_poll_loop at 
haproxy.c:2403
 frame #15: 0x0001000e7c74 
haproxy`run_thread_poll_loop(data=0x7fff5fbff3a4) at haproxy.c:2464
 frame #16: 0x0001000e4a49 haproxy`main(argc=3, 
argv=0x7fff5fbff590) at haproxy.c:3082

 frame #17: 0x7fffc9db9235 libdyld.dylib`start + 1

Issue goes away if you change the lua txn.sc:ipmask() line to:
 txn.sc:ipmask(txn.f:src(), '24', '112')

Reproduced with current master (9db0fed) and lua version 5.3.4.

-Patrick


It seems the patch attached to this mail fixes this issue. It at least 
make the varnishtest test file pass.


Must be checked by Thierry.


Should have mentionned that I could not reproduce this issue without 
compiling the thread support (USE_THREAD=1).

Re: BUG: segfault with lua sample converters & wrong arg types

2018-06-15 Thread Frederic Lecaille


On 06/14/2018 11:05 PM, Patrick Hemmer wrote:

Haproxy segfaults if you pass the wrong argument type to a converter.
Example:

haproxy.cfg:
     global
         lua-load /tmp/haproxy.lua

     frontend f1
         mode http
         bind :8000
         default_backend b1

         http-request lua.foo

     backend b1
         mode http
         server s1 127.0.0.1:8080

haproxy.lua:
     core.register_action("foo", { "http-req" }, function(txn)
         txn.sc:ipmask(txn.f:src(), 24, 112)
     end)

Result:
     * thread #1, queue = 'com.apple.main-thread', stop reason = 
EXC_BAD_ACCESS (code=1, address=0x18)
     frame #0: 0x7fffc9fcbf56 
libsystem_platform.dylib`_platform_memmove$VARIANT$Haswell + 182

libsystem_platform.dylib`_platform_memmove$VARIANT$Haswell:
     ->  0x7fffc9fcbf56 <+182>: movb   (%rsi,%r8), %cl
     0x7fffc9fcbf5a <+186>: movb   %cl, (%rdi,%r8)
     0x7fffc9fcbf5e <+190>: subq   $0x1, %rdx
     0x7fffc9fcbf62 <+194>: je 0x7fffc9fcbf78    ; <+216>
     Target 0: (haproxy) stopped.
     (lldb) bt
     * thread #1, queue = 'com.apple.main-thread', stop reason = 
EXC_BAD_ACCESS (code=1, address=0x18)
   * frame #0: 0x7fffc9fcbf56 
libsystem_platform.dylib`_platform_memmove$VARIANT$Haswell + 182

     frame #1: 0x7fffc9e7442e libsystem_c.dylib`__memcpy_chk + 22
     frame #2: 0x00010002ec46 
haproxy`hlua_lua2arg_check(L=0x00010120d298, first=3, 
argp=0x7fff5fbfe690, mask=196, p=0x000101817000) at hlua.c:749
     frame #3: 0x00010001fa00 
haproxy`hlua_run_sample_conv(L=0x00010120d298) at hlua.c:3393

     frame #4: 0x00010032400b haproxy`luaD_precall + 747
     frame #5: 0x0001003343c6 haproxy`luaV_execute + 3158
     frame #6: 0x000100323429 haproxy`luaD_rawrunprotected + 89
     frame #7: 0x000100324516 haproxy`lua_resume + 278
     frame #8: 0x00010001b199 
haproxy`hlua_ctx_resume(lua=0x000101205080, yield_allowed=1) at 
hlua.c:1080
     frame #9: 0x000100027de8 
haproxy`hlua_action(rule=0x00010101b180, px=0x000101817000, 
sess=0x00010120cb70, s=0x00010120cc00, flags=2) at hlua.c:6198
     frame #10: 0x000100044bcd 
haproxy`http_req_get_intercept_rule(px=0x000101817000, 
rules=0x000101817048, s=0x00010120cc00, 
deny_status=0x7fff5fbfee78) at proto_http.c:2760
     frame #11: 0x000100046182 
haproxy`http_process_req_common(s=0x00010120cc00, 
req=0x00010120cc10, an_bit=16, px=0x000101817000) at 
proto_http.c:3461
     frame #12: 0x000100094c50 
haproxy`process_stream(t=0x00010120cf40, context=0x00010120cc00, 
state=9) at stream.c:1905
     frame #13: 0x00010016179f haproxy`process_runnable_tasks at 
task.c:362
     frame #14: 0x0001000ea0eb haproxy`run_poll_loop at 
haproxy.c:2403
     frame #15: 0x0001000e7c74 
haproxy`run_thread_poll_loop(data=0x7fff5fbff3a4) at haproxy.c:2464
     frame #16: 0x0001000e4a49 haproxy`main(argc=3, 
argv=0x7fff5fbff590) at haproxy.c:3082

     frame #17: 0x7fffc9db9235 libdyld.dylib`start + 1

Issue goes away if you change the lua txn.sc:ipmask() line to:
     txn.sc:ipmask(txn.f:src(), '24', '112')

Reproduced with current master (9db0fed) and lua version 5.3.4.

-Patrick


It seems the patch attached to this mail fixes this issue. It at least 
make the varnishtest test file pass.


Must be checked by Thierry.


Fred.
>From 245592382b46458082be1cd440603dd4b92c500b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Fr=C3=A9d=C3=A9ric=20L=C3=A9caille?= 
Date: Fri, 15 Jun 2018 13:56:04 +0200
Subject: [PATCH] BUG/MINOR: lua: Segfaults with wrong usage of types.

Patrick reported that this simple configuration made haproxy segfaults:

global
lua-load /tmp/haproxy.lua

frontend f1
mode http
bind :8000
default_backend b1

http-request lua.foo

backend b1
mode http
server s1 127.0.0.1:8080

with this '/tmp/haproxy.lua' script:

core.register_action("foo", { "http-req" }, function(txn)
txn.sc:ipmask(txn.f:src(), 24, 112)
end)

This is due to missing initialization of the array of arguments
passed to hlua_lua2arg_check() which makes it enter code with
corrupted arguments.

Thanks a lot to Patrick Hemmer for having reported this issue.

Must be backported to 1.8, 1.7 and 1.6.
---
 src/hlua.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/hlua.c b/src/hlua.c
index 716bd29..84debaf 100644
--- a/src/hlua.c
+++ b/src/hlua.c
@@ -3256,7 +3256,7 @@ __LJMP static int hlua_run_sample_fetch(lua_State *L)
 {
 	struct hlua_smp *hsmp;
 	struct sample_fetch *f;
-	struct arg args[ARGM_NBARGS + 1];
+	struct arg args[ARGM_NBARGS + 1] = {{0}};
 	int i;
 	struct sample smp;
 
-- 
2.1.4

Re: BUG: segfault with lua sample converters & wrong arg types

2018-06-15 Thread Frederic Lecaille


Hello Patrick,

On 06/14/2018 11:05 PM, Patrick Hemmer wrote:

Haproxy segfaults if you pass the wrong argument type to a converter.
Example:

haproxy.cfg:
     global
         lua-load /tmp/haproxy.lua

     frontend f1
         mode http
         bind :8000
         default_backend b1

         http-request lua.foo

     backend b1
         mode http
         server s1 127.0.0.1:8080

haproxy.lua:
     core.register_action("foo", { "http-req" }, function(txn)
         txn.sc:ipmask(txn.f:src(), 24, 112)
     end)

Result:
     * thread #1, queue = 'com.apple.main-thread', stop reason = 
EXC_BAD_ACCESS (code=1, address=0x18)
     frame #0: 0x7fffc9fcbf56 
libsystem_platform.dylib`_platform_memmove$VARIANT$Haswell + 182

libsystem_platform.dylib`_platform_memmove$VARIANT$Haswell:
     ->  0x7fffc9fcbf56 <+182>: movb   (%rsi,%r8), %cl
     0x7fffc9fcbf5a <+186>: movb   %cl, (%rdi,%r8)
     0x7fffc9fcbf5e <+190>: subq   $0x1, %rdx
     0x7fffc9fcbf62 <+194>: je 0x7fffc9fcbf78    ; <+216>
     Target 0: (haproxy) stopped.
     (lldb) bt
     * thread #1, queue = 'com.apple.main-thread', stop reason = 
EXC_BAD_ACCESS (code=1, address=0x18)
   * frame #0: 0x7fffc9fcbf56 
libsystem_platform.dylib`_platform_memmove$VARIANT$Haswell + 182

     frame #1: 0x7fffc9e7442e libsystem_c.dylib`__memcpy_chk + 22
     frame #2: 0x00010002ec46 
haproxy`hlua_lua2arg_check(L=0x00010120d298, first=3, 
argp=0x7fff5fbfe690, mask=196, p=0x000101817000) at hlua.c:749
     frame #3: 0x00010001fa00 
haproxy`hlua_run_sample_conv(L=0x00010120d298) at hlua.c:3393

     frame #4: 0x00010032400b haproxy`luaD_precall + 747
     frame #5: 0x0001003343c6 haproxy`luaV_execute + 3158
     frame #6: 0x000100323429 haproxy`luaD_rawrunprotected + 89
     frame #7: 0x000100324516 haproxy`lua_resume + 278
     frame #8: 0x00010001b199 
haproxy`hlua_ctx_resume(lua=0x000101205080, yield_allowed=1) at 
hlua.c:1080
     frame #9: 0x000100027de8 
haproxy`hlua_action(rule=0x00010101b180, px=0x000101817000, 
sess=0x00010120cb70, s=0x00010120cc00, flags=2) at hlua.c:6198
     frame #10: 0x000100044bcd 
haproxy`http_req_get_intercept_rule(px=0x000101817000, 
rules=0x000101817048, s=0x00010120cc00, 
deny_status=0x7fff5fbfee78) at proto_http.c:2760
     frame #11: 0x000100046182 
haproxy`http_process_req_common(s=0x00010120cc00, 
req=0x00010120cc10, an_bit=16, px=0x000101817000) at 
proto_http.c:3461
     frame #12: 0x000100094c50 
haproxy`process_stream(t=0x00010120cf40, context=0x00010120cc00, 
state=9) at stream.c:1905
     frame #13: 0x00010016179f haproxy`process_runnable_tasks at 
task.c:362
     frame #14: 0x0001000ea0eb haproxy`run_poll_loop at 
haproxy.c:2403
     frame #15: 0x0001000e7c74 
haproxy`run_thread_poll_loop(data=0x7fff5fbff3a4) at haproxy.c:2464
     frame #16: 0x0001000e4a49 haproxy`main(argc=3, 
argv=0x7fff5fbff590) at haproxy.c:3082

     frame #17: 0x7fffc9db9235 libdyld.dylib`start + 1

Issue goes away if you change the lua txn.sc:ipmask() line to:
     txn.sc:ipmask(txn.f:src(), '24', '112')

Reproduced with current master (9db0fed) and lua version 5.3.4.

-Patrick


I have reproduced the same issue with varnishtest.

Here is a linux backtrace:


Program terminated with signal SIGSEGV, Segmentation fault.
#0  __memcpy_sse2_unaligned ()
at ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S:33
33  ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S: No such 
file or directory.

(gdb) bt
#0  __memcpy_sse2_unaligned ()
at ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S:33
#1  0x0041b428 in hlua_lua2arg_check (L=L@entry=0xf1b528,
first=first@entry=3, argp=argp@entry=0x7fffa27a2790, mask=196, 
p=0xee3600)

at src/hlua.c:749
#2  0x0041c6ae in hlua_run_sample_conv (L=0xf1b528) at 
src/hlua.c:3393

#3  0x00508664 in luaD_precall ()
#4  0x0051350d in luaV_execute ()
#5  0x00507ebc in luaD_rawrunprotected ()
#6  0x00508af0 in lua_resume ()
#7  0x00423dec in hlua_ctx_resume (lua=0xf1b490,
yield_allowed=yield_allowed@entry=1) at src/hlua.c:1080
#8  0x00428bb7 in hlua_action (rule=0xee51c0, px=0xee3600,
sess=, s=0xf15690, flags=2) at src/hlua.c:6198
#9  0x00438a9c in http_req_get_intercept_rule (px=0xeb8d20,
px@entry=0xee3600, rules=0xee3648, s=0xf15690, deny_status=0x726a606e,
deny_status@entry=0x7fffa27a2d6c) at src/proto_http.c:2760
#10 0x0043e216 in http_process_req_common (s=s@entry=0xf15690,
req=req@entry=0xf156a0, an_bit=an_bit@entry=16, px=0xee3600)
at src/proto_http.c:3461
#11 0x0046fcb0 in process_stream (t=, 
context=0xf15690,

state=) at src/stream.c:1905
#12 0x004efeca in process_runnable_tasks () at src/task.c:362
#13 0x004a25f4 i

Re: Connections stuck in CLOSE_WAIT state with h2

2018-06-15 Thread Janusz Dziemidowicz

2018-06-15 11:21 GMT+02:00 Willy Tarreau :
>> I've tried with all three patches, still no luck. I had to revert
>> native h2 shortly because I've started getting ERR_SPDY_PROTOCOL_ERROR
>> in Chrome. The error was always on POST request.
>
> Too bad, have to dig again then :-/.
> Thank you Janusz!

That's a bit weird, but I've reverted back to clean 1.8.9 and I still
get ERR_SPDY_PROTOCOL_ERROR, so this seems like a unrelated problem.
Chrome net-internals shows only:

t= 10312 [st=  4042]  HTTP2_SESSION_RECV_RST_STREAM
  --> error_code = "5 (STREAM_CLOSED)"
  --> stream_id = 129

However I'm pretty sure I was doing exactly the same yesterday and had
no such problem.

Anyway, I'm reverting back to clean 1.8.9 and h2 handled by nghttpx.
I'd prefer not to do any more tests before Monday ;)

-- 
Janusz Dziemidowicz

Re: Connections stuck in CLOSE_WAIT state with h2

2018-06-15 Thread Willy Tarreau

On Fri, Jun 15, 2018 at 11:19:04AM +0200, Janusz Dziemidowicz wrote:
> 2018-06-14 19:49 GMT+02:00 Willy Tarreau :
> > On Thu, Jun 14, 2018 at 07:22:34PM +0200, Janusz Dziemidowicz wrote:
> >> 2018-06-14 18:56 GMT+02:00 Willy Tarreau :
> >>
> >> > If you'd like to run a test, I'm attaching the patch.
> >>
> >> Sure, but you forgot to attach it :)
> >
> > Ah, that's because I'm stupid :-)
> >
> > Here it comes this time.
> 
> I've tried with all three patches, still no luck. I had to revert
> native h2 shortly because I've started getting ERR_SPDY_PROTOCOL_ERROR
> in Chrome. The error was always on POST request.

Too bad, have to dig again then :-/.
Thank you Janusz!

Willy

Re: remaining process after (seamless) reload

2018-06-15 Thread William Lallemand

On Tue, Jun 12, 2018 at 04:56:24PM +0200, William Dauchy wrote:
> On Tue, Jun 12, 2018 at 04:33:43PM +0200, William Lallemand wrote:
> > Those processes are still using a lot of CPU...
> > Are they still delivering traffic?
> 
> they don't seem to handle any traffic (at least I can't see it through strace)
> but that's the main difference here, using lots of CPU.
> 
> > > strace: [ Process PID=14595 runs in x32 mode. ]
> >
> > This part is particularly interesting, I suppose you are not running in 
> > x32, right?
> > I had this problem at some point but was never able to reproduce it...
> 
> yup, I can't really understand where it is coming from. I have this
> issue until I do a complete restart.
> 
> Thanks for your help,

Hey William,

Unfortunately I was not able to reproduce the bug :/, it might be dependent on 
your environment.

Could you share:

- haproxy -vv
- distribution  w/ glibc version and kernel
- compiler version

Thanks,

-- 
William Lallemand

Re: Connections stuck in CLOSE_WAIT state with h2

2018-06-15 Thread Janusz Dziemidowicz

2018-06-14 19:49 GMT+02:00 Willy Tarreau :
> On Thu, Jun 14, 2018 at 07:22:34PM +0200, Janusz Dziemidowicz wrote:
>> 2018-06-14 18:56 GMT+02:00 Willy Tarreau :
>>
>> > If you'd like to run a test, I'm attaching the patch.
>>
>> Sure, but you forgot to attach it :)
>
> Ah, that's because I'm stupid :-)
>
> Here it comes this time.

I've tried with all three patches, still no luck. I had to revert
native h2 shortly because I've started getting ERR_SPDY_PROTOCOL_ERROR
in Chrome. The error was always on POST request.

-- 
Janusz Dziemidowicz

Re: remaining process after (seamless) reload

Re: [PATCH] BUG/MINOR: lua: Segfaults with wrong usage of types.

[PATCH] BUG/MINOR: lua: Segfaults with wrong usage of types.

Re: BUG: segfault with lua sample converters & wrong arg types

Re: BUG: segfault with lua sample converters & wrong arg types

Re: BUG: segfault with lua sample converters & wrong arg types

Re: Connections stuck in CLOSE_WAIT state with h2

Re: Connections stuck in CLOSE_WAIT state with h2

Re: remaining process after (seamless) reload

Re: Connections stuck in CLOSE_WAIT state with h2

10 matches

Site Navigation

Mail list logo

Footer information