Hi Cyril, On Thu, Oct 02, 2014 at 06:56:09PM +0200, Cyril Bonté wrote: > Then we're facing several segfault issues, because I still reproduce > segfaults with a dynamic use_backend. > > #0 propagate_processes (from=from@entry=0x1c44160, > to=0x655f656863616367) at src/cfgparse.c:5996 > 5996 (from->bind_proc & to->bind_proc) == > from->bind_proc) > (gdb) bt > #0 propagate_processes (from=from@entry=0x1c44160, > to=0x655f656863616367) at src/cfgparse.c:5996 > #1 0x0000000000422196 in propagate_processes (from=0x1c44160, > from@entry=0x1c44320, to=<optimized out>) at src/cfgparse.c:6014 > #2 0x00000000004221bc in propagate_processes (from=0x1c44320, > to=<optimized out>) at src/cfgparse.c:6019 > #3 0x0000000000423a8c in check_config_validity () at src/cfgparse.c:7121 > #4 0x0000000000408064 in init (argc=<optimized out>, argv=<optimized > out>, argv@entry=0x7fff00c1ece8) at src/haproxy.c:713 > #5 0x00000000004066c9 in main (argc=<optimized out>, > argv=0x7fff00c1ece8) at src/haproxy.c:1355 > > 0x655f656863616367 is the hex value of the backend name, not a pointer > to a proxy. > > The patch I provided looks to solve this specific case.
Hmmm you're right, I conflated the two cases. In your case, for sure, haproxy cannot propagate the binds through the dynamic rules since there's no way to know which ones are in use, so you're absolutely right, we must proceed as you did. And I think that with both patches we cover all cases (static which failed to resolve and dynamic which we must not attempt to resolve). Please send me a git patch, I'll merge it immediately. Thanks! Willy
