OSPF6d: memory allocated on interface create doesn't get freed, when interface gets deleted

[Jagadeeshnagaraju]

Description

When an instance id or a non-default parameter(for ex: ipv6 ospf6 hello-interval 20) is set for an interface ospf6_interface_create is called and memory gets allocated. But when the non-default parameters are reverted, the ospf6_interface_delete is not getting, thus it leaks the memory.

As ospf6d allows to create interface which are not physically present in the device(for interface m1 can also be created) everytime an interface is created with non-default values, then the new memory gets allocated. Thus somebody can create n number of interfaces and increase the leak.

It's notable that, the same memory gets used, the next time the same interface gets created, But still i think it's better to delete the memory, reallocate it next time when it's needed.

Version

OS Version: Custom build Linux
Kernel: 4.14.302
FRR Version: 8.4.2

How to reproduce

1. Create an interface with non-default parameter or set an instance id
2. remove the instance id or reset the parameter value to default value

Expected behavior

once the interface gets deleted from the config, the associated memory should be freed.

Actual behavior

when the interface gets deleted from the config, the associated memory isn't freed.

Additional context

This is the valgrind logs, when two interfaces are created and deleted.

==29386== HEAP SUMMARY: ==29386== in use at exit: 20,335 bytes in 48 blocks ==29386== total heap usage: 117,571 allocs, 117,523 frees, 10,016,713 bytes allocated ==29386== ==29386== 3,424 (800 direct, 2,624 indirect) bytes in 2 blocks are definitely lost in loss record 34 of 35 ==29386== at 0x4C30ACC: calloc (vg_replace_malloc.c:711) ==29386== by 0x5284347: qcalloc (in /lib/libfrr.so.0.0.0) ==29386== by 0x414C74: ospf6_interface_create (ospf6_interface.c:207) ==29386== by 0x42FF9F: ipv6_ospf6_area (ospf6_interface.c:1789) ==29386== by 0x526D6CC: cmd_execute_command_real.isra.10 (in /lib/libfrr.so.0.0.0) ==29386== by 0x526D80B: cmd_execute_command (in /lib/libfrr.so.0.0.0) ==29386== by 0x526E81D: cmd_execute (in /lib/libfrr.so.0.0.0) ==29386== by 0x52BFD39: vty_command (in /lib/libfrr.so.0.0.0) ==29386== by 0x52BFFD1: vty_execute (in /lib/libfrr.so.0.0.0) ==29386== by 0x52C01F2: vtysh_read (in /lib/libfrr.so.0.0.0) ==29386== by 0x52C0FD9: thread_call (in /lib/libfrr.so.0.0.0) ==29386== by 0x527A5DE: frr_run (in /lib/libfrr.so.0.0.0) ==29386== ==29386== LEAK SUMMARY: ==29386== definitely lost: 800 bytes in 2 blocks ==29386== indirectly lost: 2,624 bytes in 38 blocks ==29386== possibly lost: 0 bytes in 0 blocks ==29386== still reachable: 16,911 bytes in 8 blocks ==29386== suppressed: 0 bytes in 0 blocks ==29386== Reachable blocks (those to which a pointer was found) are not shown. ==29386== To see them, rerun with: --leak-check=full --show-leak-kinds=all ==29386==

Checklist

• [X] I have searched the open issues for this bug.
• [X] I have not included sensitive information in this report.

[donaldsharp]

Please try latest master, lots of bug fixes have happened since 8.4

[ghost]

I have been able to reproduce this bug on master @ commit d9775c690c (just an arbitrary commit; when I last rebased my development branch)

It's not obvious to me how the leak happens.

[github-actions[bot]]

This issue is stale because it has been open 180 days with no activity. Comment or remove the autoclose label in order to avoid having this issue closed.

[frrbot[bot]]

This issue will be automatically closed in the specified period unless there is further activity.