This commit changes how fko_new() deals with FKO context initialization
to not set ctx->initval back to zero (uninitialized) imediately after
calling each fko_set_... function and before checking the fko_set_... return
value. The reason for this change is that fko_destroy() checks for
context initialization via ctx->initval before calling free() against
any heap allocated context member. So, if fko_set_... returns an error,
fko_destroy() (previous to this commit) would have no opportunity to
free such members.
This bug was found with fault injection testing provided by libfiu
together with valgrind. Specifically the following test suite command
exposes the problem (from the test/ directory):
./test-fwknop.pl --enable-complete --include "fault injection.*libfko"
In the resulting output/2.test file valgrind reports the following:
==27941== LEAK SUMMARY:
==27941== definitely lost: 264 bytes in 1 blocks
==27941== indirectly lost: 28 bytes in 3 blocks
==27941== possibly lost: 0 bytes in 0 blocks
==27941== still reachable: 1,099 bytes in 12 blocks
==27941== suppressed: 0 bytes in 0 blocks
After this commit is applied, this changes to:
==7137== LEAK SUMMARY:
==7137== definitely lost: 0 bytes in 0 blocks
==7137== indirectly lost: 0 bytes in 0 blocks
==7137== possibly lost: 0 bytes in 0 blocks
==7137== still reachable: 1,099 bytes in 12 blocks
==7137== suppressed: 0 bytes in 0 blocks
Note that 'definitely lost' in valgrind output means there is a real
memory leak that needs to be fixed whereas 'still reachable' is most
likely not a real problem according to:
http://valgrind.org/docs/manual/faq.html#faq.deflost
82b05b9530