#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
[email protected]
https://lists.sourceforge.net/lists/listinfo/warzone2100-project
