Hello BIRD maintainers,

I would like to report a memory leak in BIRD3. After uplifting from v2 we can see a persistent memory consumption increase in bird daemon. Running bird daemon by Valgrind turned out that the leak is in BIRD3's 'domain_new' called from 'cli_command'. Every birdc interaction leaks one 80-byte domain object.

==53== 248,160 bytes in 3,102 blocks are definitely lost in loss record 204 of 204

==53==    at 0x48419B4: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)

==53==    by 0x4990D1: bird_xmalloc (xmalloc.c:46)

==53==    by 0x584514: domain_new (domain.c:72)

==53==    by 0x499438: obstacle_target_init (obstacle.h:57)

==53==    by 0x499BCD: cli_command (cli.c:258)

==53==    by 0x499D48: cli_event (cli.c:294)

==53==    by 0x47CCEE: ev_run_list_limited (event.c:336)

==53==    by 0x572FFE: io_loop (io.c:2641)

==53==    by 0x5843CF: main (main.c:1114)

==53== 

==53== LEAK SUMMARY:

==53==    definitely lost: 248,160 bytes in 3,102 blocks

==53==    indirectly lost: 0 bytes in 0 blocks

==53==      possibly lost: 576 bytes in 2 blocks

==53==    still reachable: 481,941 bytes in 3,818 blocks

==53==         suppressed: 0 bytes in 0 blocks

==53== 

==53== For lists of detected and suppressed errors, rerun with: -s

Not familiar with BIRD source code, just guessing that domain_free() needs to be called when the CLI command's obstacle target completes.

BGP+BFD routing was configured and'birdc configure/birdc show'commands are called frequently by our monitor application and the leak is proportional to CLI invocation count. Let me know if any additional detail is needed. 

---

Additionally, 'use-after-free errors' can be seen in the log:

Invalid read of size 8 at bgp_listen_free (bgp.c:416)
  Address is inside a block that was already free'd by pool_free

This happens during BGP protocol shutdown (proto_cleanup > proto_loop_stopped > pool_free > bgp_listen_free). The BGP listen socket structure is accessed after its containing pool is freed. This is a BIRD3 bug in protocol teardown ordering, not related to the memory leak but indicates a use-after-free that could cause crashes.

Best Regards,

Laszlo Kiraly