Extremely simple C++ program memory leak

Question

I have been scratching my head over this memory leak in a extremely simple C++ program. I properly delete the only pointer allocation but a ridiculous amount of memory leak still occurs. None of my classes even have variables.

All the methods only prints a sinple hard coded string

main

#include <iostream>
#include "queen.h"
#include "piece.h"
using namespace std;

void printPiece(piece *p) {
  cout<<"In printPiece, printType() of the same memory address is:"<<endl;
  p->printType();
}

int main() {
  queen *q = new queen();

  cout<<"In main, printType() of queen *q is:"<<endl;
  q->printType();

  printPiece(q);

  delete q;
  return 0;
}

piece class

#ifndef _PIECE_H
#define _PIECE_H

class piece {
public:
    void printType();
};

#endif

Queen

#ifndef _QUEEN_H
#define _QUEEN_H
#include "piece.h"

class queen : public piece{
  public:
    void printType();
};

#endif

Valgrind on MacOS

HEAP SUMMARY:
==8775==     in use at exit: 26,145 bytes in 190 blocks
==8775==   total heap usage: 257 allocs, 67 frees, 31,922 bytes allocated
==8775==
==8775== 2,064 bytes in 1 blocks are possibly lost in loss record 58 of 62
==8775==    at 0x10000B942: malloc_zone_malloc (in /usr/local/Cellar/valgrind/3.12.0/lib/valgrind/vgpreload_memcheck-amd64-darwin.so)
==8775==    by 0x1005E6EFD: _objc_copyClassNamesForImage (in /usr/lib/libobjc.A.dylib)
==8775==    by 0x1005DA182: protocols() (in /usr/lib/libobjc.A.dylib)
==8775==    by 0x1005DA093: readClass(objc_class*, bool, bool) (in /usr/lib/libobjc.A.dylib)
==8775==    by 0x1005D7C13: gc_init (in /usr/lib/libobjc.A.dylib)
==8775==    by 0x1005DF24E: objc_initializeClassPair_internal(objc_class*, char const*, objc_class*, objc_class*) (in /usr/lib/libobjc.A.dylib)
==8775==    by 0x1005EC132: layout_string_create (in /usr/lib/libobjc.A.dylib)
==8775==    by 0x1005DA83C: realizeClass(objc_class*) (in /usr/lib/libobjc.A.dylib)
==8775==    by 0x1005DA300: copySwiftV1MangledName(char const*, bool) (in /usr/lib/libobjc.A.dylib)
==8775==    by 0x1005DA2E9: copySwiftV1MangledName(char const*, bool) (in /usr/lib/libobjc.A.dylib)
==8775==    by 0x1005DA2E9: copySwiftV1MangledName(char const*, bool) (in /usr/lib/libobjc.A.dylib)
==8775==    by 0x1005DA2E9: copySwiftV1MangledName(char const*, bool) (in /usr/lib/libobjc.A.dylib)
==8775==
==8775== LEAK SUMMARY:
==8775==    definitely lost: 0 bytes in 0 blocks
==8775==    indirectly lost: 0 bytes in 0 blocks
==8775==      possibly lost: 2,064 bytes in 1 blocks
==8775==    still reachable: 4,096 bytes in 1 blocks
==8775==         suppressed: 19,985 bytes in 188 blocks
==8775== Reachable blocks (those to which a pointer was found) are not shown.
==8775== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==8775==
==8775== For counts of detected and suppressed errors, rerun with: -v
==8775== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 14 from 14)

Valgrind on Ubuntu

==32313== Memcheck, a memory error detector
==32313== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==32313== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==32313== Command: ./main
==32313== 
In main, printType() of queen *q is:
Queen
In printPiece, printType() of the same memory address is:
Unknown Piece Type
==32313== 
==32313== HEAP SUMMARY:
==32313==     in use at exit: 72,704 bytes in 1 blocks
==32313==   total heap usage: 3 allocs, 2 frees, 73,729 bytes allocated
==32313== 
==32313== 72,704 bytes in 1 blocks are still reachable in loss record 1 of 1
==32313==    at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==32313==    by 0x4EC3EFF: ??? (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
==32313==    by 0x40104E9: call_init.part.0 (dl-init.c:72)
==32313==    by 0x40105FA: call_init (dl-init.c:30)
==32313==    by 0x40105FA: _dl_init (dl-init.c:120)
==32313==    by 0x4000CF9: ??? (in /lib/x86_64-linux-gnu/ld-2.23.so)
==32313== 
==32313== LEAK SUMMARY:
==32313==    definitely lost: 0 bytes in 0 blocks
==32313==    indirectly lost: 0 bytes in 0 blocks
==32313==      possibly lost: 0 bytes in 0 blocks
==32313==    still reachable: 72,704 bytes in 1 blocks
==32313==         suppressed: 0 bytes in 0 blocks
==32313== 
==32313== For counts of detected and suppressed errors, rerun with: -v
==32313== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

Answer 1

The memory leak is completely unrelated to your program compilation units. Somewhere, somehow parts of the Swift and Objective-C language runtimes are linked into your program. Somewhere in there a garbage collector enters the picture. And Valgrind simply is telling you, that your program did exit with still a few garbage collected allocations being (before the garbage collector could free them).

In general when using a garbage collector you'll always see memory leak errors with Valgrind.