Segmentation fault when tying to use a file cluster

[GuillaumeConnan]

Hi,

I'm encountering a problem with the latest version of carbon-c-relay when I try to use a file cluster.

• Version: pre-3.2 ; commit 00b6828 (Apr 30, 2017)
• OS: CentOS Linux release 7.3.1611 (Core)
• What I did: tried to configure a file cluster to log all incoming traffic to a file
• Expected result: a running relay that log all the incoming traffic to a file and forward it to another relay
• Happened instead: segmentation fault while parsing my config file

Configuration used:

statistics
    submit every 60 seconds
    reset counters after interval
    ;

cluster log-file
    file
        /tmp/carbon-c-relay-metrics.log
    ;
cluster next-hop
    forward
        xxx.xxx.xxx.xxx:2003
    ;

match *
    send to log-file
    ;
match *
    send to next-hop
    stop
    ;

Output when starting the relay:

# /opt/carbon-c-relay/relay -f /opt/carbon-c-relay/relay.conf
[2017-05-04 09:26:12] starting carbon-c-relay v3.1 (2017-05-04), pid=12862
configuration:
    relay hostname = 6e9295b4fc1e
    listen port = 2003
    workers = 3
    send batch size = 2500
    server queue size = 25000
    server max stalls = 4
    listen backlog = 32
    server connection IO timeout = 600ms
    configuration = /opt/carbon-c-relay/relay.conf

Segmentation fault (core dumped)

This configuration worked well before the 3.0 release, and is working when I withdraw the lignes concerning the file cluster.

Could this be due to your new implementation of configuration file parsing?

Thanks for your help!

[piotr1212]

I can reproduce, attached gdb backtrace:

Core was generated by `./relay -f /etc/carbon-c-relay.conf'. Program terminated with signal SIGSEGV, Segmentation fault.

0 server_cmp (s=0xfe8000, saddr=saddr@entry=0xfe8160) at server.c:612

612 s->saddr->ai_family == saddr->ai_family && (gdb) bt

0 server_cmp (s=0xfe8000, saddr=saddr@entry=0xfe8160) at server.c:612

1 0x0000000000410b50 in router_add_server (ret=ret@entry=0xfe7520,

ip=0xfe945b "127.0.0.1", port=2003, inst=0x0, proto=CON_TCP, saddrs=0xfe8160, 
hint=0x0, useall=0 '\000', cl=0x7fe4a87f90a8) at router.c:541

2 0x000000000040909c in router_yyparse (yyscanner=,

rtr=rtr@entry=0xfe7520, ralloc=<optimized out>, palloc=palloc@entry=0xfe7eb0)
at conffile.y:164

3 0x000000000041364f in router_readconfig (orig=,

path=0x7fff8c2d75c6 "/etc/carbon-c-relay.conf", queuesize=25000, 
batchsize=<optimized out>, maxstalls=<optimized out>, iotimeout=<optimized out>, 
sockbufsize=0) at router.c:1068

4 0x0000000000402f46 in main (argc=, argv=)

at relay.c:735

[grobian]

hmmm, bah, a test should have covered this.