BIRD crashing when --enable-debug is set
Toke Høiland-Jørgensen
toke at toke.dk
Sun Nov 22 18:21:00 CET 2020
andreas at rammhold.de writes:
> Hi,
>
> I've been playing with the BIRD source code and implementing a new
> extension to Babel but that is not what this mail is about.
Still curious - which extension? :)
[..]
> Breakpoint 1, add_tail (n=0x234ac30, l=0x241f620) at ./lib/lists.c:82
> #0 add_tail (n=0x234ac30, l=0x241f620) at ./lib/lists.c:82
> #1 sl_alloc (s=0x21bd7d0) at lib/slab.c:264
This is that call to add_tail in slab.c, with a few lines of context:
full_partial:
rem_node(&h->n);
add_tail(&s->full_heads, &h->n);
goto redo;
Since add_tail is being called immediately after rem_node(), and they I
both inlines, my guess would be that this comes from the compiler
optimising out the clearing of n->prev and n->next in rem_node() since
they are immediately being reset.
> Are these all false positives or should there be more cleanup code on
> these list entries?
Speaking for the backtraces you saw in the Babel code, these all come
from variants of the following pattern:
struct babel_msg_node *msgn = sl_alloc(p->msg_slab);
/* initialise msgn->msg */
add_tail(&queue, NODE msgn);
where babel_msg_node is just:
struct babel_msg_node {
node n;
union babel_msg msg;
};
Since add_tail sets n->next and n->prev right after those asserts, no
harm is actually done and the memory ends up fully initialised, so I'm
not sure if there's any reason to do anything about it: It's really
only a problem because of the debug asserts.
-Toke
More information about the Bird-users
mailing list