#3399: Init memleak fixes -------------------------+------------------------------------------------- Reporter: T_X | Type: patch (an actual patch, not a Status: new | request for one) Milestone: | Priority: normal unspecified | Component: other Version: | Keywords: memleak,init,startup,valgrind git/master | Blocking: Blocked By: | Operating System: All | /Non-Specific | -------------------------+------------------------------------------------- Copy and Pasta from: https://github.com/Warzone2100/warzone2100/pull/30
---- These should fix some non critical memory leaks which were caused by memory allocated during startup but Not being properly freed during shutdown. They are shown when starting warzone2100 with "valgrind --leak- check=full" and hitting "Quit Game" right afterwards. Refs #3395 (http://developer.wz2100.net/ticket/3395). After those four patches, the following two valgrind errors are still left during this minimal startup phase for me: {{{ ==12304== 40 bytes in 1 blocks are still reachable in loss record 209 of 642 ==12304== at 0x402894D: malloc (in /usr/lib/valgrind/vgpreload_memcheck- amd64-linux.so) ==12304== by 0x781916: __glcGetThreadArea (in /mnt/dev/warzone2100/src/warzone2100) ==12304== by 0x77EDF0: __glcLock (in /mnt/dev/warzone2100/src/warzone2100) ==12304== by 0x78487A: __glcContextCreate (in /mnt/dev/warzone2100/src/warzone2100) ==12304== by 0x77F3FE: glcGenContext (in /mnt/dev/warzone2100/src/warzone2100) ==12304== by 0x756AFC: iV_initializeGLC() (textdraw.cpp:123) ==12304== by 0x756DFC: iV_TextInit() (textdraw.cpp:205) ==12304== by 0x5A89FF: systemInitialise() (init.cpp:521) ==12304== by 0x5D115B: realmain(int, char**) (main.cpp:1278) ==12304== by 0x792183: main (main_sdl.cpp:24) ==12304== ==12304== 84 bytes in 2 blocks are still reachable in loss record 381 of 642 ==12304== at 0x402894D: malloc (in /usr/lib/valgrind/vgpreload_memcheck- amd64-linux.so) ==12304== by 0x400AA85: _dl_new_object (dl-object.c:161) ==12304== by 0x4005FB5: _dl_map_object_from_fd (dl-load.c:957) ==12304== by 0x40076B7: _dl_map_object (dl-load.c:2468) ==12304== by 0x400CF61: openaux (dl-deps.c:65) ==12304== by 0x400D925: _dl_catch_error (dl-error.c:178) ==12304== by 0x400C02B: _dl_map_object_deps (dl-deps.c:247) ==12304== by 0x4011EB7: dl_open_worker (dl-open.c:263) ==12304== by 0x400D925: _dl_catch_error (dl-error.c:178) ==12304== by 0x4011899: _dl_open (dl-open.c:633) ==12304== by 0x8E1DF65: dlopen_doit (dlopen.c:67) ==12304== by 0x400D925: _dl_catch_error (dl-error.c:178) ==12304== }}} But I can't tell yet, whether they are warzone2100's fault or external issues. For the former, looking at the QuesoGLC 0.7.2 documentation and source code as well as some printf'ing in the Warzone2100 code it looked more like a bug in the external glcDeleteContext() function which as far as I can tell is properly called from the warzone2100 side. For the latter - no idea where that comes from. -- Ticket URL: <http://developer.wz2100.net/ticket/3399> Warzone 2100 Trac <http://developer.wz2100.net/> The Warzone 2100 Project ------------------------------------------------------------------------------ Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev _______________________________________________ Warzone2100-project mailing list Warzone2100-project@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/warzone2100-project