Memory leaks in unit tests

[pasis]

There are a lot of memory leaks in unit tests:

==7219== LEAK SUMMARY:
==7219==    definitely lost: 6,995 bytes in 235 blocks
==7219==    indirectly lost: 6,123 bytes in 231 blocks
==7219==      possibly lost: 14,492 bytes in 100 blocks
==7219==    still reachable: 889,807 bytes in 2,609 blocks
==7219==         suppressed: 0 bytes in 0 blocks

Steps to reproduce:

1. Build unittests: make tests/unittests/unittests
2. Run valgrind: valgrind --leak-check=full --show-leak-kinds=definite tests/unittests/unittests

[jubalh]

I see some warnings that seem to be invalid like in complete_accented_with_accented(). So far I didn't see ones were I think it's right. Maybe closing this issue soon.

[jubalh]

Valgrind output now:

==23744== LEAK SUMMARY:
==23744==    definitely lost: 0 bytes in 0 blocks
==23744==    indirectly lost: 0 bytes in 0 blocks
==23744==      possibly lost: 2,424 bytes in 20 blocks
==23744==    still reachable: 576,191 bytes in 2,153 blocks
==23744==                       of which reachable via heuristic:
==23744==                         newarray           : 1,536 bytes in 16 blocks
==23744==         suppressed: 0 bytes in 0 blocks

So all leaks in unit tests should be fixed. Some of the issues even brought general memleaks to daylight.

@pasis valgrind gives some more output. Mostly Invalid reads and jumps depending on uninit. values. The latter might be not true becaues it's mostly things from glib lists, and I suspect maybe valgrind can't detect that properly.

However I would be happy if you could take a look at some of the invalid reads as I don't quite understand them. Especially the Python related stuff.

[jubalh]

1746f5f was actually not a fix.

I reverted it in 7684cf6.

So we still have:

=4548== 16 bytes in 1 blocks are definitely lost in loss record 550 of 1,441
==4548==    at 0x4838D7B: realloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==4548==    by 0x55D2AC7: g_realloc (in /usr/lib64/libglib-2.0.so.0.6000.6)
==4548==    by 0x55B2823: ??? (in /usr/lib64/libglib-2.0.so.0.6000.6)
==4548==    by 0x55B30B2: g_string_insert_len (in /usr/lib64/libglib-2.0.so.0.6000.6)
==4548==    by 0x437125: cmd_join (cmd_funcs.c:3612)
==4548==    by 0x47DBAD: cmd_join_uses_password_when_supplied (test_cmd_join.c:167)
==4548==    by 0x487E9E1: _run_test (in /usr/lib64/libcmocka.so.0.7.0)
==4548==    by 0x487ECCC: _run_tests (in /usr/lib64/libcmocka.so.0.7.0)
==4548==    by 0x47F1E5: main (unittests.c:629)
==4548== 
==4548== 32 bytes in 1 blocks are definitely lost in loss record 1,138 of 1,441
==4548==    at 0x4838D7B: realloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==4548==    by 0x55D2AC7: g_realloc (in /usr/lib64/libglib-2.0.so.0.6000.6)
==4548==    by 0x55B2823: ??? (in /usr/lib64/libglib-2.0.so.0.6000.6)
==4548==    by 0x55B30B2: g_string_insert_len (in /usr/lib64/libglib-2.0.so.0.6000.6)
==4548==    by 0x437125: cmd_join (cmd_funcs.c:3612)
==4548==    by 0x47D5F8: cmd_join_uses_account_mucservice_when_no_service_specified (test_cmd_join.c:82)
==4548==    by 0x487E9E1: _run_test (in /usr/lib64/libcmocka.so.0.7.0)
==4548==    by 0x487ECCC: _run_tests (in /usr/lib64/libcmocka.so.0.7.0)
==4548==    by 0x47F1E5: main (unittests.c:629)

I thought we might need something like g_strfreev(args); in cmd_join_uses_password_when_supplied() and cmd_join_uses_account_mucservice_when_no_service_specified() but seems not to help.

Any idea here @pasis?

[jubalh]

These commits also regard this issue:
6d11cd2
0499c4e