Task #43

Test the code with valgrind/enable memory debug macros - find memory leaks

Added by IR4T4 over 7 years ago. Updated about 4 years ago.

Status:In Progress% Done:

30%

Priority:NormalSpent time:-
Assignee:-
Category:General
Target version:2.78
OS: Arch:

Description

valgrind.log (1.81 MB) IR4T4, 14.09.2013 14:34

History

#1 Updated by IR4T4 about 7 years ago

  • Target version changed from 2.70rc1 to 2.75

#2 Updated by boutetnico almost 7 years ago

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

#3 Updated by IR4T4 almost 7 years ago

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

#4 Updated by IR4T4 about 6 years ago

#5 Updated by IR4T4 about 6 years ago

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

#6 Updated by Radegast over 5 years ago

  • Status changed from New to Feedback

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

#7 Updated by IR4T4 over 5 years ago

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

#8 Updated by swillits over 5 years ago

(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.

#9 Updated by IR4T4 over 5 years ago

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

#10 Updated by IR4T4 over 5 years ago

  • Subject changed from Test the code with valgrind to Test the code with valgrind/enable memory debug macros - find memory leaks
  • Status changed from Feedback to In Progress
  • % Done changed from 0 to 30

#11 Updated by IR4T4 about 4 years ago

  • Target version changed from 2.75 to 2.78

Also available in: Atom PDF