jonas/tig — pull request #156 by matthiasbeyer (2013-06-06 13:03:50+00:00)
Title: Fixed memory leak

Please read carefully and test my changes if possible. This is my first submit to open source software, so please be kind and tell me what I can do better!

---

Found memory leak (using valgrind):

./configure
make all
valgrind --leak-check ./tig

[...]
==2234== HEAP SUMMARY:
==2234== in use at exit: 1,749,649 bytes in 3,411 blocks
==2234== total heap usage: 6,333 allocs, 2,922 frees, 4,000,732 bytes allocated
==2234==
==2234== 9 bytes in 1 blocks are definitely lost in loss record 7 of 81
==2234== at 0x4C2C04B: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==2234== by 0x416553: set_environment_variable (tig.c:8181)
==2234== by 0x41661F: set_int_environment_variable (tig.c:8197)
==2234== by 0x4082D2: resize_display (tig.c:2503)
==2234== by 0x40B298: maximize_view (tig.c:3475)
==2234== by 0x40B3E7: load_view (tig.c:3508)
==2234== by 0x40B59A: open_view (tig.c:3549)
==2234== by 0x40BCB2: view_driver (tig.c:3753)
==2234== by 0x417D79: main (tig.c:8702)
[...]

And fixed.

As I'm not used to the code, let me assume:

The 'env' variable is supposed to be local. As I cannot see any
return or arguments which interact with this variable, I think
this variable is supposed to be local only.

I removed the malloc() call, as if the variable is local, we don't need
it. It was replaced with

char env[len]

which gets allocated on stack. Then, I removed the check in the if

if (env && ...

as we don't need to check if it gets allocated. Afterwards we need to
pass it to string_nformat(), which must be done with the address of the
variable, therefor I changed it (and the putenv() call).

Last but not least, I removed the

free(env)
return ...

lines as we can easily return the

string_nformat(...) && putenv(env) == 0

which was the condition of the check before.

Recompiled and checked with

make tig.o
make all
valgrind --leak-check=full ./tig

gives

[...]
==13247== HEAP SUMMARY:
==13247== in use at exit: 1,749,856 bytes in 3,411 blocks
==13247== total heap usage: 6,335 allocs, 2,924 frees, 4,002,371 bytes
allocated
==13247==
==13247== LEAK SUMMARY:
==13247== definitely lost: 0 bytes in 0 blocks
==13247== indirectly lost: 0 bytes in 0 blocks
==13247== possibly lost: 0 bytes in 0 blocks
==13247== still reachable: 1,749,856 bytes in 3,411 blocks
==13247== suppressed: 0 bytes in 0 blocks
[...]

Issues seem to be fixed now!