#3398: Init memleak fixes
-------------------------------+-------------------------------------------
        Reporter:  T_X         |       Type:  bug
          Status:  new         |   Priority:  normal
       Milestone:              |  Component:  other
  unspecified                  |   Keywords:  memleak,init,startup,valgrind
         Version:  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/3398>
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

Reply via email to