bird-1.5.0 ipv4 segfaults on configure - is it safe to change bgp protocol names runtime?

[Ondrej Zajicek]

On Fri, Mar 18, 2016 at 08:36:53AM +0100, Bartosz Radwan wrote:
> Hi bird users,
> 
> General question is: is it safe to change bgp protocol name runtime?

It is expected to be safe. Although because protocol names are used as
keys to identify/match protocols, you cannot really rename a protocol -
with a different name, a new one is created and an old one is removed.


> I can reproduce error that occurs at configure time in local envoroment,
> hovever there's no any established sessions at all in ths env, not sure if
> errors are the same.
> 
> Here's backtrace:
> 
> 
> bird: F_1_0901_NEW_NAME: Initializing
> bird: F_1_0901_NEW_NAME: Starting
> bird: F_1_0901_NEW_NAME: State changed to start
> bird: F_1_0901_OLD_NAME: State changed to down
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x0000000000455bfb in ?? ()
> (gdb) bt
> #0  0x0000000000455bfb in ?? ()
> #1  0x000000000040e4ee in olock_run_event (unused=<optimized out>) at
> ../../nest/locks.c:177
> #2  0x000000000043b76e in ev_run (e=0x66c010) at event.c:85
> #3  ev_run_list (l=0x66b2e0 <global_event_list>) at event.c:142
> #4  0x000000000043de3c in io_loop () at io.c:2061
> #5  0x00000000004031d3 in main (argc=<optimized out>, argv=<optimized out>)
> at main.c:833
> 
> 
> Then i've used much simplier config (just 1 bgp session) in my local
> enviroment, after 3rd protocol name change and reconfiguration another error
> occurred:
> 
> bird: Removing protocol one_SOME_LONGER
> bird: one_SOME_LONGER: Shutting down
> bird: one_SOME_LONGER: Shutdown requested
> bird: one_SOME_LONGER: State changed to stop
> bird: Adding protocol one_SOME_LONGER_NAME
> bird: one_SOME_LONGER_NAME: Initializing
> bird: one_SOME_LONGER_NAME: Starting
> bird: one_SOME_LONGER_NAME: State changed to start
> bird: one_SOME_LONGER: Down
> 
> Program received signal SIGSEGV, Segmentation fault.
> olock_free (r=0x6751b0) at ../../nest/locks.c:72
> 72                rem_node(n);
> (gdb) bt
> #0  olock_free (r=0x6751b0) at ../../nest/locks.c:72
> #1  0x0000000000445752 in pool_free (P=<optimized out>) at resource.c:81
> #2  0x00000000004457c3 in rfree (res=0x674830) at resource.c:165
> #3  0x000000000040ae8f in proto_notify_state (p=0x674da0, ps=<optimized
> out>) at ../../nest/proto.c:1387
> #4  0x000000000043b76e in ev_run (e=0x675120) at event.c:85
> #5  ev_run_list (l=0x66b2e0 <global_event_list>) at event.c:142
> #6  0x000000000043de3c in io_loop () at io.c:2061
> #7  0x00000000004031d3 in main (argc=<optimized out>, argv=<optimized out>)
> at main.c:833
> 
> Another protocol name change triggered another error:
> 
> bird: Removing protocol one_SOME_LONGER_NAME_2
> bird: one_SOME_LONGER_NAME_2: Shutting down
> bird: one_SOME_LONGER_NAME_2: Shutdown requested
> bird: one_SOME_LONGER_NAME_2: State changed to stop
> bird: Adding protocol one_SOME_LONGER_NAME_2_3
> bird: one_SOME_LONGER_NAME_2_3: Initializing
> bird: one_SOME_LONGER_NAME_2_3: Starting
> bird: one_SOME_LONGER_NAME_2_3: State changed to start
> bird: one_SOME_LONGER_NAME_2: Down
> bird: one_SOME_LONGER_NAME_2: State changed to down
> bird: Reconfigured
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x000000000044574f in pool_free (P=<optimized out>) at resource.c:81
> 81            r->class->free(r);
> (gdb) bt
> #0  0x000000000044574f in pool_free (P=<optimized out>) at resource.c:81
> #1  0x00000000004457c3 in rfree (res=0x6807c0) at resource.c:165
> #2  0x000000000043d94b in sk_read (s=s at entry=0x680660) at io.c:1786
> #3  0x000000000043e23c in io_loop () at io.c:2158
> #4  0x00000000004031d3 in main (argc=<optimized out>, argv=<optimized out>)
> at main.c:833
> 
> 
> Further details including core files from gdb may be provided if needed.
> 
> -- 
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
> Z poważaniem
> Bartosz Radwan

-- 
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santiago at crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20160318/752738d3/attachment.asc>