非常简单的C ++程序内存泄漏

Question

我一直在用一个非常简单的C ++程序来解决内存泄漏问题。 我正确地删除了唯一的指针分配，但是仍然发生大量的内存泄漏。 我的班级甚至都没有变量。

所有方法仅输出一个单一的硬编码字符串

主要

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

件类

#ifndef _PIECE_H
#define _PIECE_H

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

#endif

女王

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

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

#endif

MacOS上的Valgrind

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在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

内存泄漏与程序编译单元完全无关。 在某些地方，某些方式的Swift和Objective-C语言运行时已链接到您的程序中。 某个地方的垃圾收集器进入了图片。 Valgrind只是在告诉您，您的程序确实退出了，仍然有一些垃圾回收分配（在垃圾回收器释放它们之前）。

通常，在使用垃圾收集器时，Valgrind总是会看到内存泄漏错误。