Extremely simple C++ program memory leak - c++

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.