Valgrind detecting leaks from GNUstep (Objective-C) on Ubuntu

0
votes

I am trying to use valgrind to find leaks from an objective-c program running on Ubuntu with GNUstep.

However, even the following simple code causes valgrind to throw lots of memory leaks (mostly from NSZoneMalloc).

#import <Foundation/Foundation.h>

int main()
{
    NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];

    [pool drain];

    return 0;
}

After googling a bit about this, I did find that these leaks are expected: http://lists.gnu.org/archive/html/gnustep-dev/2004-08/msg00063.html

Has anyone had experience using valgrind with GNUStep? Would be great if someone can share some experience on how to suppress these kind of errors from valgrind. So the "real" leaks can be clearly detected.

1
objective-cvalgrindgnustep
well you have only created one object and return immediately... how many leaks can you have? – Grady Player
definitely lost: 1,889 bytes in 150 blocks – bohanl
I am seeing this message repeatedly: 8 bytes in 1 blocks are definitely lost in loss record 115 of 1,224 ==4714== at 0x402BE68: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==4714== by 0x44BFCEA: objc_malloc (in /usr/lib/i386-linux-gnu/libobjc.so.3.0.0) – bohanl
Looks like there is no way to suppress because the leaks are from libobjc.so.3.0.0. If this is suppressed, all will be suppressed. – bohanl

1 Answers

0
votes

well you can try a different runtime... (apple vs gnustep) or fix it yourself or similar... or if it is only one leak that always happens you can just ignore that one. and pay attention to others... In apple land we rely on clang's static analysis which should show no problem with memory management in your example.