Where master == f22758d12af5e9f3919f24bf913b883a62df7d93, the following
config fails on both linux-glibc and osx:

    maxconn 1024

    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

Every request crashes immediately before connecting to the backend.


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
#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

Reply via email to