title: valgrind | self-made garbage collection | bytes in 1 blocks are definitely lost in loss record
body: <p>I write a quite complex software (for > 10 years by now).</p>
  
  <p>You may want to checkout sources from:
  <a href="http://savannah.nongnu.org/svn/?group=cybop" rel="nofollow">http://savannah.nongnu.org/svn/?group=cybop</a></p>
  
  <p>Follow the instructions of the INSTALL file to compile and run.</p>
  
  <p>I've run memcheck using this command line:
  christian@deneb:/home/project/cybop/examples$ valgrind --tool=memcheck --log-file=memcheck.log --leak-check=full --track-origins=yes ../src/controller/cyboi exit/run.cybol</p>
  
  <p>Here is the memcheck output:</p>
  
  <pre><code>==28641== Memcheck, a memory error detector
  ==28641== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
  ==28641== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
  ==28641== Command: ../src/controller/cyboi exit/run.cybol
  ==28641== Parent PID: 22974
  ==28641== 
  ==28641== 
  ==28641== HEAP SUMMARY:
  ==28641==     in use at exit: 5,174 bytes in 407 blocks
  ==28641==   total heap usage: 636 allocs, 229 frees, 45,749 bytes allocated
  ==28641== 
  ==28641== 442 (72 direct, 370 indirect) bytes in 1 blocks are definitely lost in loss record 406 of 407
  ==28641==    at 0x4C28BED: malloc (vg_replace_malloc.c:263)
  ==28641==    by 0x401EC0: allocate_array (array_allocator.c:116)
  ==28641==    by 0x40719C: allocate_part (part_allocator.c:50)
  ==28641==    by 0x42EE3E: deserialise_cybol_part_element_content (content_element_part_cybol_deserialiser.c:262)
  ==28641==    by 0x43098E: deserialise_cybol_part_element (element_part_cybol_deserialiser.c:74)
  ==28641==    by 0x4309FD: deserialise_cybol_part (part_cybol_deserialiser.c:79)
  ==28641==    by 0x42F230: deserialise_cybol_part_element_content (content_element_part_cybol_deserialiser.c:331)
  ==28641==    by 0x43098E: deserialise_cybol_part_element (element_part_cybol_deserialiser.c:74)
  ==28641==    by 0x4309FD: deserialise_cybol_part (part_cybol_deserialiser.c:79)
  ==28641==    by 0x42F230: deserialise_cybol_part_element_content (content_element_part_cybol_deserialiser.c:331)
  ==28641==    by 0x42F4CB: deserialise_cybol (cybol_deserialiser.c:196)
  ==28641==    by 0x42FD48: deserialise (deserialiser.c:229)
  ==28641== 
  ==28641== 4,732 (72 direct, 4,660 indirect) bytes in 1 blocks are definitely lost in loss record 407 of 407
  ==28641==    at 0x4C28BED: malloc (vg_replace_malloc.c:263)
  ==28641==    by 0x401EC0: allocate_array (array_allocator.c:116)
  ==28641==    by 0x40719C: allocate_part (part_allocator.c:50)
  ==28641==    by 0x41F6EA: deserialise_xml_element (element_xml_deserialiser.c:61)
  ==28641==    by 0x41FA65: select_xml_element_content (element_content_xml_selector.c:144)
  ==28641==    by 0x41FAF3: deserialise_xml_element_content (element_content_xml_deserialiser.c:73)
  ==28641==    by 0x41FBA9: deserialise_xml (xml_deserialiser.c:66)
  ==28641==    by 0x42F3E1: deserialise_cybol (cybol_deserialiser.c:178)
  ==28641==    by 0x42FD48: deserialise (deserialiser.c:229)
  ==28641==    by 0x430088: receive_file (file_receiver.c:106)
  ==28641==    by 0x433D2F: initialise (initialiser.c:88)
  ==28641==    by 0x4344C3: manage (manager.c:320)
  ==28641== 
  ==28641== LEAK SUMMARY:
  ==28641==    definitely lost: 144 bytes in 2 blocks
  ==28641==    indirectly lost: 5,030 bytes in 405 blocks
  ==28641==      possibly lost: 0 bytes in 0 blocks
  ==28641==    still reachable: 0 bytes in 0 blocks
  ==28641==         suppressed: 0 bytes in 0 blocks
  ==28641== 
  ==28641== For counts of detected and suppressed errors, rerun with: -v
  ==28641== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 6 from 6)
  </code></pre>
  
  <p>The "definitely lost" error claims not everything was freed properly.
  I don't ask you to do the Sisyphus job and search all my source code.
  There is essentially just one "malloc" that all functions rely on.
  The data structures (top-down) are as follows: part - item - array - value,
  i. e. a part references nine items, and an item references three arrays.</p>
  
  <p>My self-made built-in garbage collection says everything were fine.
  Perhaps somebody wants to have a look? Any hint is appreciated.
  Source code snippet of file "array_allocator.c" following:</p>
  
  <pre><code>void allocate_array(void* p0, void* p1, void* p2) {
  
      if (p0 != *NULL_POINTER_STATE_CYBOI_MODEL) {
  
          void** a = (void**) p0;
  
          // The memory area.
          int ma = *NUMBER_0_INTEGER_STATE_CYBOI_MODEL;
  
          // Determine type (type) size.
          determine_size((void*) &amp;ma, p2);
  
          // Calculate memory area.
          calculate_integer_multiply((void*) &amp;ma, p1);
  
          // The temporary size_t variable.
          size_t tma = ma;
  
          // CAUTION! In order to always get a correct memory address returned
          // that may be used to store data, a potential zero size is changed
          // to a minimum size of one here.
          if (tma == *NUMBER_0_INTEGER_STATE_CYBOI_MODEL) {
  
              tma = *NUMBER_1_INTEGER_STATE_CYBOI_MODEL;
  
          } else if (tma &lt; *NUMBER_0_INTEGER_STATE_CYBOI_MODEL) {
  
  fwprintf(stdout, L"ERROR: Could not allocate array. The memory area to be allocated is negative: %i\n", *a);
  
              tma = *NUMBER_1_INTEGER_STATE_CYBOI_MODEL;
          }
  
          *a = malloc(tma);
  
          // Initialise array elements with null pointer.
          //
          // CAUTION! Initialising with zero values is essential, since
          // cyboi frequently tests variables for null pointer values.
          memset(*a, *NUMBER_0_INTEGER_STATE_CYBOI_MODEL, tma);
  
      } else {
  
          log_message_terminated((void*) ERROR_LEVEL_LOG_CYBOI_MODEL, (void*) L"Could not allocate array. The array is null.");
      }
  }
  </code></pre>