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