Re: GNUstep and valgrind

[Ivan Vučica]

I think this came up a few years ago with resolution of "it's not a leak unless 
it grows in ram usage" -- it's fine (and faster) if some resources are cleaned 
up by the OS at process termination time. Think singletons and such.

If you observe RAM use growing and leaking beyond this, it's a problem. I think 
it might be possible to mark certain allocations as safe, not sure how.

Valgrind can tell you where memory was allocated, too. Is it giving you useful 
information in this case?

I realize you have safety concerns. Nonetheless, it's probably better to have 
working code and observe if "leaks" are leaks, i.e. growing over time.

Sent from my iPhone

> On 13 Mar 2018, at 23:53, amon <amon@vnl.com> wrote:
> 
> 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"     |
> +---------------------------------------------------------------+
> 
> _______________________________________________
> Discuss-gnustep mailing list
> Discuss-gnustep@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnustep