Question

在我的大学里，我们被要求创建一个分配所有可用内存的程序。所以我认为制作一个无限循环并分配内存而不释放它必须消耗掉计算机的所有可用内存。但是，由于我没有释放内存，因此必然存在巨大的内存泄漏。

所以我写了一个简单的程序但是当我用valgrind检查它时没有内存泄漏。没有任何。没有直接的间接泄漏。

请告诉我原因。这是我的计划：

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

int main()
{
    int i,kb=0,mb=0;
    char *some;
    while(1) {
        for(i=0;i<1024;i++)
        {
            // Allocating memory one kilobyte a time.
            some = (char*) malloc(1024);
            if(some == NULL)
            {
                exit(EXIT_FAILURE);
            }
            kb++;
        }
        // Displaying no. of mbs that have been allocated at each mb
        mb++;
        printf("%d mb\n",mb);
    }
    return 0;
}

Answer 1

将some = (char*) malloc(1024);替换为：some = new char[1024]; 如果你有至少那么多的可用内存，它将在2000MB失败。但是，如果在Win32环境中运行此命令，则不会分配计算机中的所有可用内存，因为每个进程都有2GB的限制，因此在这种情况下，您将需要另一种方法。

Answer 2

首先想到的是，分配已经过优化 - 通常是完全分配或推送到堆栈存储。在这种情况下，完全删除它会更好。

您通常可以通过阅读生成的程序集来证明或反驳这一点。

Answer 3

当我运行它时 - valgrind发现问题：

==3335==
==3335== HEAP SUMMARY:
==3335==     in use at exit: 2,271,338,496 bytes in 2,218,104 blocks
==3335==   total heap usage: 2,218,105 allocs, 0 frees, 2,271,338,496 bytes allocated
==3335== 
==3335== 
==3335==     Valgrind's memory management: out of memory:
==3335==        newSuperblock's request for 8876032 bytes failed.
==3335==        3116339200 bytes have already been allocated.
==3335==     Valgrind cannot continue.  Sorry.
==3335== 
==3335==     There are several possible reasons for this.
==3335==     - You have some kind of memory limit in place.  Look at the
==3335==       output of 'ulimit -a'.  Is there a limit on the size of
==3335==       virtual memory or address space?
==3335==     - You have run out of swap space.`

即使使用O2 O3也不会删除该错误。这是一个完整的样本吗？

UPD

该标志不会改变输出，但如果我在崩溃前中断程序，valgrind会显示下一行：

^C1890 mb
==3286== 
==3286== HEAP SUMMARY:
==3286==     in use at exit: 1,981,808,640 bytes in 1,935,360 blocks
==3286==   total heap usage: 1,935,360 allocs, 0 frees, 1,981,808,640 bytes allocated
==3286== 
==3286== 276,480 bytes in 270 blocks are possibly lost in loss record 2 of 3
==3286==    at 0x402BE68: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==3286==    by 0x8048472: main (mem_test.c:13)
==3286== 
==3286== 1,981,530,112 bytes in 1,935,088 blocks are definitely lost in loss record 3 of 3
==3286==    at 0x402BE68: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==3286==    by 0x8048472: main (mem_test.c:13)
==3286== 
==3286== LEAK SUMMARY:
==3286==    definitely lost: 1,981,530,112 bytes in 1,935,088 blocks
==3286==    indirectly lost: 0 bytes in 0 blocks
==3286==      possibly lost: 276,480 bytes in 270 blocks
==3286==    still reachable: 2,048 bytes in 2 blocks
==3286==         suppressed: 0 bytes in 0 blocks
==3286== Reachable blocks (those to which a pointer was found) are not shown.
==3286== To see them, rerun with: --leak-check=full --show-reachable=yes
==3286== 
==3286== For counts of detected and suppressed errors, rerun with: -v
==3286== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)

Answer 4

在Linux下，内核不限制分配，而是有效使用内存。（见https://www.kernel.org/doc/Documentation/vm/overcommit-accounting）

$ echo 2 > /proc/sys/vm/overcommit_memory

应禁用此功能，否则如果使用0填充已分配的内存，则代码应按预期运行：

some = (char*) malloc(1024);
if(some == NULL) {
   exit(EXIT_FAILURE);
}
memset(some, 0, 1024);
kb++;

没有内存泄漏

4 个答案: