Extrem einfaches C++ Programm Speicherleck

Question

Ich habe mir über dieses Speicherleck in einem sehr einfachen C++ Programm den Kopf verkratzt. Ich lösche richtig die einzige Zeigerzuordnung, aber eine lächerliche Menge an Speicherleck tritt immer noch auf. Keiner meiner Klassen hat sogar Variablen.

Methoden druckt alle nur eine sinple harte String codiert

Haupt

#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; 
} 

Stück Klasse

#ifndef _PIECE_H 
#define _PIECE_H 

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

#endif 

Königin

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

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

#endif 

Valgrind auf 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 auf 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

Der Speicherverlust ist zu Ihrem Programm Kompilierungseinheiten völlig unabhängig. Irgendwo sind Teile der Sprachlaufzeiten Swift und Objective-C in Ihr Programm eingebunden. Irgendwo dringt ein Müllsammler in das Bild ein. Und Valgrind sagt Ihnen einfach, dass Ihr Programm mit noch ein paar Garbage Collection-Zuweisungen beendet wurde (bevor der Garbage Collector sie freigeben konnte).

Wenn Sie einen Garbage Collector verwenden, werden bei Valgrind im Allgemeinen immer Speicherleckfehler angezeigt.