Never mind, I found the problem. It was a patch on my local branch.
Sorry for the inconveniences.
On 7/22/19 6:16 PM, Fernando Fernandez Mancera wrote:
> Hi,
>
> I have found a memleak when using "nft -f".
>
> Example file (test-memleak):
>
> add table ip foo
> add chain ip foo bar {type filter hook input priority filter;}
>
> # valgrind --leak-check=full nft -f test-memleak
>
> ==12624== Memcheck, a memory error detector
> ==12624== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
> ==12624== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
> ==12624== Command: nft -f policy_test
> ==12624==
> ==12624==
> ==12624== HEAP SUMMARY:
> ==12624== in use at exit: 7 bytes in 1 blocks
> ==12624== total heap usage: 59 allocs, 58 frees, 242,068 bytes allocated
> ==12624==
> ==12624== 7 bytes in 1 blocks are definitely lost in loss record 1 of 1
> ==12624== at 0x483577F: malloc (vg_replace_malloc.c:299)
> ==12624== by 0x4C4FDB9: strdup (strdup.c:42)
> ==12624== by 0x488403D: xstrdup (utils.c:75)
> ==12624== by 0x48A7C0F: nft_lex (scanner.l:641)
> ==12624== by 0x489827B: nft_parse (parser_bison.c:5482)
> ==12624== by 0x4889797: nft_parse_bison_filename (libnftables.c:395)
> ==12624== by 0x4889797: nft_run_cmd_from_filename (libnftables.c:498)
> ==12624== by 0x10A616: main (main.c:318)
> ==12624==
> ==12624== LEAK SUMMARY:
> ==12624== definitely lost: 7 bytes in 1 blocks
> ==12624== indirectly lost: 0 bytes in 0 blocks
> ==12624== possibly lost: 0 bytes in 0 blocks
> ==12624== still reachable: 0 bytes in 0 blocks
> ==12624== suppressed: 0 bytes in 0 blocks
> ==12624==
> ==12624== For counts of detected and suppressed errors, rerun with: -v
> ==12624== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
>
> I have been trying to debug this but I was not able to find where is the
> problem.
>
