Test the code with valgrind/enable memory debug macros - find memory leaks about etlegacy HOT 7 OPEN

From: @boutetnico (boutetnico)
Date: 2012-11-09T09:53:20Z

Some memory leaks on Linux 32-bit when running command:

$ valgrind --leak-check=full /usr/local/games/enemy-territory/etlded +set fs_basepath "/usr/local/games/enemy-territory" +set fs_game legacy +set dedicated 1 +map goldrush

==10550== HEAP SUMMARY:
==10550== in use at exit: 159,908,051 bytes in 15 blocks
==10550== total heap usage: 708 allocs, 693 frees, 168,673,869 bytes allocated
==10550==
==10550== 160 (40 direct, 120 indirect) bytes in 1 blocks are definitely lost in loss record 12 of 15
==10550== at 0x402BE68: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==10550== by 0x41959DE: nss_parse_service_list (nsswitch.c:678)
==10550== by 0x4196159: __nss_database_lookup (nsswitch.c:175)
==10550== by 0x403D168: ???
==10550== by 0x403EB5C: ???
==10550== by 0x414D126: getpwuid_r@@GLIBC_2.1.2 (getXXbyYY_r.c:256)
==10550== by 0x414CA6D: getpwuid (getXXbyYY.c:117)
==10550== by 0x8099E0F: Sys_GetCurrentUser (in /usr/local/games/enemy-territory/etlded)
==10550== by 0x8098EDE: Sys_Init (in /usr/local/games/enemy-territory/etlded)
==10550== by 0x80751E3: Com_Init (in /usr/local/games/enemy-territory/etlded)
==10550== by 0x80998AD: main (in /usr/local/games/enemy-territory/etlded)
==10550==
==10550== 134,217,759 bytes in 1 blocks are possibly lost in loss record 15 of 15
==10550== at 0x402A5E6: calloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==10550== by 0x80731BB: Com_InitHunkMemory (in /usr/local/games/enemy-territory/etlded)
==10550== by 0x8074DCF: Com_Init (in /usr/local/games/enemy-territory/etlded)
==10550== by 0x80998AD: main (in /usr/local/games/enemy-territory/etlded)
==10550==
==10550== LEAK SUMMARY:
==10550== definitely lost: 40 bytes in 1 blocks
==10550== indirectly lost: 120 bytes in 10 blocks
==10550== possibly lost: 134,217,759 bytes in 1 blocks
==10550== still reachable: 25,690,132 bytes in 3 blocks
==10550== suppressed: 0 bytes in 0 blocks

Update:

Memory leak from getpwuid seems to be a false positive from Valgrind. Source: http://stackoverflow.com/questions/4778244/what-does-one-do-about-buggy-posix-apis-which-leak-memory

from etlegacy.

From: @IR4T4 (IR4T4)
Date: 2012-11-09T14:11:27Z

I have nearly the same results as above.

Run omnibots with valgrind and you'll get tons of ouputs. We (crapshoot & myself) did test ET+mod+bots a long time ago and came to the conclusion that most results are false positves so I'm not really convinced anymore valgrind is 'our' tool to find memory issues. Maybe it's worth to start ETL & valgrind on a bigger server with real humans connected but that's really the last trial with valgrind :/

from etlegacy.

From: @IR4T4 (IR4T4)
Date: 2013-09-14T12:49:26Z

The attached log is from valgrind with current ETL & shipped OB version (quit after 2 min).

valgrind --leak-check=yes --track-origins=yes --log-file="valgrind.log"  ./etlded 

Worth to read:
http://stackoverflow.com/questions/14952637/valgrind-conditional-jump-or-move-depends-on-uninitialised-values-does-this

from etlegacy.

From: @JanSimek (Radegast)
Date: 2014-02-03T00:24:00Z

user:swillits ran Apple Instruments analysis on ET:L and the current code seems to be leak-free.

from etlegacy.

From: @IR4T4 (IR4T4)
Date: 2014-02-04T19:10:51Z

Valgrind still reports issues but it's no compare to the results we have had 2 years ago :D

from etlegacy.

From: @swillits (swillits)
Date: 2014-02-04T22:35:17Z

(Keeping in mind I don't have a great depth of experience with the custom allocation in Q3 etc…)

Because the engine uses custom allocators, there's two kinds of leaks: there's malloc-level leaks, and then there's leaking at the custom-allocator level. There was just one real malloc-level leak that I saw, but it was trivial, very infrequent, and existed in the official code with a comment that (IIRC) they someday should do something about it. Since most of the allocation is done through the custom zone allocator, standard leak testing just isn't going to be useful. You'd really need a custom leak checker to know whether there are leaks happening in the zone/hunk allocators at specific times.

from etlegacy.

From: @IR4T4 (IR4T4)
Date: 2014-02-05T14:24:51Z

Right. The 'custom leak checker' seems to be implemented - there are some macros to enable memory debugging. Gonna activate those by time ...

from etlegacy.