Where master == f22758d12af5e9f3919f24bf913b883a62df7d93, the following
config fails on both linux-glibc and osx:
global
maxconn 1024
defaults
timeout client 9s
timeout server 9s
timeout connect 1s
frontend test_fe
mode http
bind :::9999
use_backend test_be
backend test_be
mode http
server localhost 127.0.0.1:10000
Every request crashes immediately before connecting to the backend.
Backtrace:
Program received signal SIGSEGV, Segmentation fault.
back_handle_st_con (s=0x94abd0) at src/backend.c:1937
1937 if (!conn->mux && !(conn->flags & CO_FL_WAIT_XPRT)) {
(gdb) bt
#0 back_handle_st_con (s=0x94abd0) at src/backend.c:1937
#1 0x000000000042ae75 in process_stream (t=0x94b020, context=0x94abd0,
state=<value optimized out>) at src/stream.c:1662
#2 0x00000000005083c2 in process_runnable_tasks () at src/task.c:461
#3 0x00000000004bb36b in run_poll_loop (data=<value optimized out>) at
src/haproxy.c:2630
#4 run_thread_poll_loop (data=<value optimized out>) at src/haproxy.c:2783
#5 0x00000000004bdba5 in main (argc=<value optimized out>, argv=<value
optimized out>) at src/haproxy.c:3483
Segfault is on the same line on OS X and Linux.
On Thu, Jan 23, 2020 at 11:49 AM Willy Tarreau <w...@1wt.eu> wrote:
> On Thu, Jan 23, 2020 at 11:05:57AM -0800, James Brown wrote:
> > Update: I rebased back to the last non-segfaulting commit and this
> patch's
> > functionality appears to work in very limited testing.
>
> Cool, thanks for doing it. I've quickly read it and I'm also convinced it
> must work. I'll take more time tomorrow doing a more in-depth review and
> suggesting some parts to split into different patches.
>
> I'm also interested in knowing more about this segfault in master, because
> for me all reg-tests were OK before I pushed last update, thus if you have
> a reproducer I'm very interested :-)
>
> Thanks,
> Willy
>
--
James Brown
Engineer
