GNUstep and valgrind

[amon]

Perhaps someone can tell me if my guess on the following is
correct. After an afternoon of trying to figure out where the
large number of leaks reported by valgrind were coming from, I
went all the way back to basics. What it seems to show is that
the GNUStep run time allocates a bunch of stuff at start up and
never clears it. Here are the two test cases. The first is an
empty main(), which one would expect should come up clean, and
it does:

        /* Build with
            gcc -I /usr/include/GNUstep test2.m -lm -lobjc \
                        -lgnustep-base -o test2
          [DMA 20180220]
        */
        #import <Foundation/Foundation.h>
        main () {
        }
        /* This claims there are leaks in the above program:
            valgrind --leak-check=yes --show-leak-kinds=definite ./test2
          [DMA 20180313]
        */

        ~/Work $ valgrind --leak-check=yes --show-leak-kinds=definite ./test2
        ==5211== Memcheck, a memory error detector
	==5211== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et 
al.
	==5211== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright 
info
        ==5211== Command: ./test2
        ==5211==
        ==5211==
        ==5211== HEAP SUMMARY:
        ==5211==     in use at exit: 0 bytes in 0 blocks
        ==5211==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
        ==5211==
        ==5211== All heap blocks were freed -- no leaks are possible
        ==5211==
        ==5211== For counts of detected and suppressed errors, rerun with: -v
        ==5211== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

The second does nothing but create a pool and release it, and
holy mackerel does it ever leak:

        /* Build with
            gcc -I /usr/include/GNUstep test2.m -lm -lobjc \
                        -lgnustep-base -o test2
          [DMA 20180220]
        */
        #import <Foundation/Foundation.h>
        main () {
          NSAutoreleasePool *pool;
          pool = [[NSAutoreleasePool alloc] init];
          [pool release];
        }
        /* This claims there are leaks in the above program:
            valgrind --leak-check=yes --show-leak-kinds=definite ./test2
          [DMA 20180313]
        */

I only included the very tail end of a huge volume of data.

	==5232== 2,720 (48 direct, 2,672 indirect) bytes in 3 blocks are 
definitely lost in loss record 452 of 471
        ==5232==    at 0x4C2AB80: malloc (vg_replace_malloc.c:296)
	==5232==    by 0x4E439B8: objc_malloc (in 
/usr/lib/x86_64-linux-gnu/libobjc.so.4.0.0)
	==5232==    by 0x4E426B4: ??? (in 
/usr/lib/x86_64-linux-gnu/libobjc.so.4.0.0)
	==5232==    by 0x4E428CB: ??? (in 
/usr/lib/x86_64-linux-gnu/libobjc.so.4.0.0)
	==5232==    by 0x4E43050: __objc_exec_class (in 
/usr/lib/x86_64-linux-gnu/libobjc.so.4.0.0)
        ==5232==    by 0x40101D9: call_init.part.0 (dl-init.c:78)
        ==5232==    by 0x40102C2: call_init (dl-init.c:36)
        ==5232==    by 0x40102C2: _dl_init (dl-init.c:126)
        ==5232==    by 0x4001299: ??? (in /lib/x86_64-linux-gnu/ld-2.19.so)
        ==5232==
        ==5232== LEAK SUMMARY:
        ==5232==    definitely lost: 1,842 bytes in 110 blocks
        ==5232==    indirectly lost: 4,704 bytes in 294 blocks
        ==5232==      possibly lost: 4,646 bytes in 132 blocks
        ==5232==    still reachable: 431,594 bytes in 7,837 blocks
        ==5232==         suppressed: 0 bytes in 0 blocks
	==5232== Reachable blocks (those to which a pointer was found) are not 
shown.
	==5232== To see them, rerun with: --leak-check=full 
--show-leak-kinds=all
        ==5232==
        ==5232== For counts of detected and suppressed errors, rerun with: -v
	==5232== ERROR SUMMARY: 149 errors from 149 contexts (suppressed: 0 
from 0)

Is this indeed the GNUstep runtime doing this or have I
not set up or not interpreted valgrid correctly?
--
+---------------------------------------------------------------+
|   Dale Amon                  Immortal Data                    |
|   CEO             Midland International Air and Space Port    |
| amon@vnl.com       "Data Systems for Deep Space and Time"     |
+---------------------------------------------------------------+