귀하의 작업은 가능한 한 적은 바이트로 최소 1 바이트의 메모리를 누출시키는 코드를 작성하는 것입니다. 메모리는 할당되지 않은 상태에서 누출되어야합니다 .

누수 된 메모리는 프로그램이 할당하지만 메모리를 올바르게 할당 해제하기 전에 액세스 할 수없는 메모리입니다. 대부분의 고급 언어의 경우이 메모리는 힙에 할당되어야합니다.

C ++의 예는 다음 프로그램입니다.

int main(){new int;}

이것 new int에 대한 포인터없이 힙을 만듭니다 . 액세스 할 수있는 방법이 없기 때문에이 메모리가 즉시 누출됩니다.

Valgrind 의 누수 요약 은 다음과 같습니다.

LEAK SUMMARY:
   definitely lost: 4 bytes in 1 blocks
   indirectly lost: 0 bytes in 0 blocks
     possibly lost: 0 bytes in 0 blocks
   still reachable: 0 bytes in 0 blocks
        suppressed: 0 bytes in 0 blocks

많은 언어에는 메모리 디버거 (예 : Valgrind )가 있으며 이러한 디버거의 출력을 포함시켜 메모리 누수를 확인해야합니다.

목표는 소스의 바이트 수를 최소화하는 것입니다.

Perl (5.22.2), 0 바이트

온라인으로 사용해보십시오!

빈 프로그램에서 메모리가 누출되는 언어가 있다는 것을 알았습니다. 나는 그것이 esolang 일 것으로 기대했지만 perl모든 프로그램에서 메모리 가 누출 되는 것으로 나타났습니다 . (이것은 의도적이라고 가정합니다. 어쨌든 종료하려고한다는 것을 기억하면 메모리를 확보하면 시간이 낭비됩니다. 현재 일반적인 권장 사항은 프로그램의 종료 루틴에 있으면 남은 메모리를 누출하는 것입니다. .)

확인

$ echo -n | valgrind perl
…snip…
==18517== 
==18517== LEAK SUMMARY:
==18517==    definitely lost: 8,134 bytes in 15 blocks
==18517==    indirectly lost: 154,523 bytes in 713 blocks
==18517==      possibly lost: 0 bytes in 0 blocks
==18517==    still reachable: 0 bytes in 0 blocks
==18517==         suppressed: 0 bytes in 0 blocks
==18517== 
==18517== For counts of detected and suppressed errors, rerun with: -v
==18517== ERROR SUMMARY: 15 errors from 15 contexts (suppressed: 0 from 0)

C, 48 31 22 바이트

경고 : 너무 많이 실행하지 마십시오.

많은 도움과 아이디어 를 주신 Dennis 에게 감사합니다 !

f(k){shmget(k,1,512);}

이것은 한 걸음 더 나아갑니다. shmget프로그램이 종료 될 때 할당 해제되지 않은 공유 메모리를 할당합니다. 메모리를 식별하기 위해 키를 사용하므로 초기화되지 않은 int를 사용합니다. 이것은 기술적으로 정의되지 않은 동작이지만 실제로 호출 될 때 스택의 맨 위에있는 값을 사용한다는 것을 의미합니다. 이것은 다음에 스택에 추가 될 때 작성되므로 키를 잃게됩니다.

이것이 작동하지 않는 유일한 경우는 이전에 스택에 무엇이 있는지 알아낼 수있는 경우입니다. 추가 19 바이트의 경우이 문제를 피할 수 있습니다.

f(){srand(time(0));shmget(rand(),1,512);}

또는 26 바이트의 경우 :

main(k){shmget(&k,1,512);}

그러나 이것으로 프로그램이 종료 된 후 메모리가 누출됩니다. 프로그램을 실행하는 동안 규칙에 위배되는 메모리에 액세스 할 수 있지만 프로그램이 종료 된 후에는 키에 액세스 할 수 없으며 메모리는 여전히 할당됩니다. 이를 위해서는 ASLR (Address Space Layout Randomization)이 필요합니다. 그렇지 않으면 &k항상 동일합니다. 요즘 ASLR은 기본적으로 켜져 있습니다.

확인:

ipcs -m시스템에 어떤 공유 메모리가 있는지 확인할 수 있습니다 . 명확성을 위해 기존 항목을 제거했습니다.

$ cat leakMem.c 
f(k){shmget(k,1,512);}
int main(){f();}     
$ gcc leakMem.c -o leakMem
leakMem.c:1:1: warning: return type defaults to ‘int’ [-Wimplicit-int]
 f(k){shmget(k,1,512);}
 ^
leakMem.c: In function ‘f’:
leakMem.c:1:1: warning: type of ‘k’ defaults to ‘int’ [-Wimplicit-int]
leakMem.c:1:6: warning: implicit declaration of function ‘shmget’ [-Wimplicit-function-declaration]
 f(k){shmget(k,1,512);}
ppcg:ipcs -m

------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status      


$ ./leakMem 

$ ipcs -m

------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status      

0x0000007b 3375157    Riley      0          1          0  

Unlambda ( c-refcnt/unlambda), 1 바이트

i

온라인으로 사용해보십시오!

이것은 매우 간단한 프로그램에서 메모리가 누수되는 기존의 인터프리터를 찾는 데 실제로 어려움이 있습니다. 이 경우 Unlambda를 사용했습니다. 공식 Unlambda 인터프리터가 두 개 이상 있지만 c-refcnt빌드하기 가장 쉬운 방법 중 하나이며 프로그램이 성공적으로 실행될 때 메모리가 누출되는 유용한 속성이 있습니다. 그래서 제가 여기에 필요한 것은 가장 간단한 법적인 Unlambda 프로그램이었습니다. (빈 프로그램은 여기서 작동하지 않으며 인터프리터가 충돌 할 때 메모리에 여전히 접근 할 수 있습니다.)

확인

$ wget ftp://ftp.madore.org/pub/madore/unlambda/unlambda-2.0.0.tar.gz
…한조각…
2017-02-18 18:11:08 (975 KB / s)- 'unlambda-2.0.0.tar.gz'가 저장 됨 [492894]
$ tar xf unlambda-2.0.0.tar.gz 
$ cd unlambda-2.0.0 / c-refcnt /
$ gcc unlambda.c
$ echo -ni | valgrind ./a.out / dev / stdin
…한조각…
== 3417 == 누출 요약 :
== 3417 == 확실히 잃어버린 : 1 블록에 40 바이트
== 3417 == 간접적으로 손실 : 0 블록에서 0 바이트
== 3417 == 유실 가능성 : 0 블록에 0 바이트
== 3417 == 여전히 도달 가능 : 0 블록에서 0 바이트
== 3417 == 억제 : 0 블록에서 0 바이트
== 3417 == 
== 3417 == 감지 및 억제 된 오류 수에 대해 다음을 사용하여 다시 실행하십시오. -v
== 3417 == 오류 요약 : 1 컨텍스트에서 1 오류 (억제 : 0에서 0)

TI 기본, 12 바이트

While 1
Goto A
End
Lbl A
Pause 

"당신이 최종 명령에 도달하기 전에 제어 구조에서 점프 (최종 명령을 아무거나) 루프 내에서 또는 조건부 경우 고토 /하는 Lbl를 사용하는 곳 ... 메모리 누수는 ..." (더)

파이썬 <3.6.5, 23 바이트

property([]).__init__()

property.__init__에 누출 참조 재산의 오래된 fget, fset, fdel, 그리고 __doc__당신은 이미 초기화에를 호출하는 경우 property인스턴스입니다. 이 버그는 결국 CPython 문제 31787의 일부로보고 되어 Python 3.6.5 및 Python 3.7.0 에서 수정되었습니다 . (그렇습니다 property([]). 할 수있는 일입니다.)

C #, 34 바이트

class L{~L(){for(;;)new L();}}

이 솔루션 에는 힙이 필요하지 않습니다. 그것은 실제로 열심히 일하는 GC ( 가비지 콜렉터 )가 필요합니다.

본질적으로 그것은 GC를 자신의 적으로 만듭니다.

설명

소멸자 가 호출 될 때마다 타임 아웃이 만료되는 한이 사악한 클래스의 새 인스턴스를 생성하고 소멸자가 완료되기를 기다리지 않고 GC에게 해당 객체를 버리지 말라고 지시합니다. 그때까지 수천 개의 새로운 인스턴스가 만들어졌습니다.

이것의 "악"은 GC가 더 열심히 작동할수록 이것이 당신의 얼굴에서 더 많이 날아갈 것입니다.

면책 조항 : 귀하의 GC가 내 것보다 똑똑 할 수 있습니다. 프로그램의 다른 상황으로 인해 GC가 첫 번째 오브젝트 또는 소멸자를 무시할 수 있습니다. 이 경우 이것은 터지지 않습니다. 그러나 많은 변형에서 그것은 그렇습니다 . 여기에 몇 바이트를 추가하면 가능한 모든 상황에서 누출이 발생할 수 있습니다. 아마도 전원 스위치를 제외하고는.

테스트

테스트 스위트 는 다음과 같습니다 .

using System;
using System.Threading;
using System.Diagnostics;
class LeakTest {
    public static void Main() {
        SpawnLeakage();
        Console.WriteLine("{0}-: Objects may be freed now", DateTime.Now);
        // any managed object created in SpawbLeakage 
        //  is no longer accessible
        // The GC should take care of them

        // Now let's see
        MonitorGC();
    }
    public static void SpawnLeakage() {
        Console.WriteLine("{0}-: Creating 'leakage' object", DateTime.Now);
        L l = new L();
    }
    public static void MonitorGC() {
        while(true) {
            int top = Console.CursorTop;
            int left = Console.CursorLeft;
            Console.WriteLine(
                "{0}-: Total managed memory: {1} bytes",
                DateTime.Now,
                GC.GetTotalMemory(false)
            );
            Console.SetCursorPosition(left, top);
        }
    }
}

10 분 후 출력 :

2/19/2017 2:12:18 PM-: Creating 'leakage' object
2/19/2017 2:12:18 PM-: Objects may be freed now
2/19/2017 2:22:36 PM-: Total managed memory: 2684476624 bytes

2,684,476,624 바이트입니다. 총 WorkingSet프로세스 수는 약 4.8GB입니다.

이 답변은 에릭 Lippert의의 멋진 기사에서 영감을하고있다 : 당신이 알고있는 모든 잘못되면 .

C (gcc) , 15 바이트

f(){malloc(1);}

확인

$ cat leak.c
f(){malloc(1);}
main(){f();}
$ gcc -g -o leak leak.c
leak.c: In function ‘f’:
leak.c:1:5: warning: incompatible implicit declaration of built-in function ‘malloc’ [enabled by default]
 f(){malloc(1);}
     ^
$ valgrind --leak-check=full ./leak
==32091== Memcheck, a memory error detector
==32091== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==32091== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==32091== Command: ./leak
==32091==
==32091==
==32091== HEAP SUMMARY:
==32091==     in use at exit: 1 bytes in 1 blocks
==32091==   total heap usage: 1 allocs, 0 frees, 1 bytes allocated
==32091==
==32091== 1 bytes in 1 blocks are definitely lost in loss record 1 of 1
==32091==    at 0x4C29110: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==32091==    by 0x40056A: f (leak.c:1)
==32091==    by 0x40057A: main (leak.c:2)
==32091==
==32091== LEAK SUMMARY:
==32091==    definitely lost: 1 bytes in 1 blocks
==32091==    indirectly lost: 0 bytes in 0 blocks
==32091==      possibly lost: 0 bytes in 0 blocks
==32091==    still reachable: 0 bytes in 0 blocks
==32091==         suppressed: 0 bytes in 0 blocks
==32091==
==32091== For counts of detected and suppressed errors, rerun with: -v
==32091== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

자바 스크립트, 14 바이트

골프

setInterval(0)

빈 지연 처리기를 기본 지연으로 등록하여 결과 타이머 ID를 삭제합니다 (취소 할 수 없음).

기본 간격을 사용하면 CPU와 같은 CPU를 먹는 것처럼 누출을 설명하기 위해 기본이 아닌 간격을 사용하여 수백만 개의 타이머를 만들었습니다.

자바, 10 바이트

마지막으로 Java의 경쟁력있는 답변!

골프

". "::trim

이것은 문자열 상수에 대한 메서드 참조이며 다음과 같이 사용할 수 있습니다.

Supplier<String> r = ". "::trim

리터럴 문자열 ". "은 클래스에 의해 유지 관리 되는대로 글로벌 인터네 인드 문자열 풀에 자동으로 추가되며 java.lang.String즉시 트리밍 할 때 코드에서 더 이상 재사용 할 수 없습니다 (정확히 동일한 문자열을 다시 선언하지 않는 한).

...

초기에 비어있는 문자열 풀은 String 클래스에 의해 개인적으로 유지됩니다.

모든 리터럴 문자열과 문자열 값 상수 표현식이 인터 닝됩니다. 문자열 리터럴은 Java ™ 언어 스펙의 3.10.5 섹션에 정의되어 있습니다.

...

https://docs.oracle.com/javase/8/docs/api/java/lang/String.html#intern--

문자열을 자체에 추가 한 다음 루프에서 intern () 메서드를 명시 적으로 호출하여 "생산 등급"메모리 누수로이를 설정할 수 있습니다 .

녹, 52 바이트

extern{fn malloc(_:u8);}fn main(){unsafe{malloc(9)}}

시스템 malloc으로 일부 바이트를 할당합니다. 이것은 잘못된 ABI가 허용되는 것으로 가정합니다.

녹 (이론상), 38 바이트

fn main(){Box::into_raw(Box::new(1));}

힙에 메모리를 할당하고, 원시 포인터를 추출한 다음 무시하고 효과적으로 누출시킵니다. ( Box::into_raw보다 짧습니다 std::mem::forget).

그러나 Rust는 기본적으로 jemalloc을 사용하며 valgrind는 누출을 감지 할 수 없습니다 . 시스템 할당 자로 전환 할 수 있지만 50 바이트 가 추가 되고 밤마다 필요합니다. 메모리 안전에 대단히 감사합니다.

첫 번째 프로그램의 출력 :

==10228== Memcheck, a memory error detector
==10228== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==10228== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright info
==10228== Command: ./1
==10228== 
==10228== 
==10228== HEAP SUMMARY:
==10228==     in use at exit: 9 bytes in 1 blocks
==10228==   total heap usage: 7 allocs, 6 frees, 2,009 bytes allocated
==10228== 
==10228== LEAK SUMMARY:
==10228==    definitely lost: 9 bytes in 1 blocks
==10228==    indirectly lost: 0 bytes in 0 blocks
==10228==      possibly lost: 0 bytes in 0 blocks
==10228==    still reachable: 0 bytes in 0 blocks
==10228==         suppressed: 0 bytes in 0 blocks
==10228== Rerun with --leak-check=full to see details of leaked memory
==10228== 
==10228== For counts of detected and suppressed errors, rerun with: -v
==10228== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

8086 ASM, 3 바이트

이 예에서는 C 런타임이 링크되어 있다고 가정합니다.

jmp _malloc

이것은 상대 주소가 e9 XX XX어디로 어셈블XX XX_malloc

이를 malloc통해 예기치 않은 메모리 양을 할당 한 다음 즉시 프로세스를 종료하여 반환합니다. DOS와 같은 일부 운영 체제에서는 시스템이 재부팅 될 때까지 메모리를 전혀 회수 할 수 없습니다!

넷째, 6 바이트

골프

s" " *

빈 문자열을로 할당 s" "하고 스택에 주소와 길이 (0)를 그대로 둔 다음 곱합니다 (메모리 주소가 손실 됨).

발 그린 드

%valgrind --leak-check=full gforth -e 's" " * bye'
...
==12788== HEAP SUMMARY:
==12788==     in use at exit: 223,855 bytes in 3,129 blocks
==12788==   total heap usage: 7,289 allocs, 4,160 frees, 552,500 bytes allocated
==12788== 
==12788== 1 bytes in 1 blocks are definitely lost in loss record 1 of 22
==12788==    at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==12788==    by 0x406E39: gforth_engine (in /usr/bin/gforth-0.7.0)
==12788==    by 0x41156A: gforth_go (in /usr/bin/gforth-0.7.0)
==12788==    by 0x403F9A: main (in /usr/bin/gforth-0.7.0)
==12788== 
...
==12818== LEAK SUMMARY:
==12818==    definitely lost: 1 bytes in 1 blocks
==12818==    indirectly lost: 0 bytes in 0 blocks

45 바이트로 간다

package main
func main(){go func(){for{}}()}

이것은 내부에 무한 루프를 가진 익명의 고 루틴을 만듭니다. goroutine을 시작하는 것은 동시에 실행중인 작은 스레드를 생성하는 것과 비슷하지만 프로그램은 goroutine에 할당 된 메모리를 회수 할 방법이 없기 때문에 프로그램은 정상적으로 정상적으로 실행될 수 있습니다. 가비지 수집기는 여전히 실행 중이므로 수집하지 않습니다. 어떤 사람들은 이것을 '고 루틴 유출'이라고 부릅니다.

자바 1.3, 23 바이트

void l(){new Thread();}

스레드를 작성하지만 시작하지는 않습니다. 스레드는 내부 스레드 풀에 등록되어 있지만 시작되지 않으므로 종료되지 않으므로 GC의 후보가되지 않습니다. Java 림보에 갇혀 복구 할 수없는 개체입니다.

나중에 수정 된 1.3이 포함될 때까지 Java의 버그입니다 .

테스팅

다음 프로그램은 새로운 스레드 객체로 메모리를 오염시키고 사용 가능한 메모리 공간을 줄입니다. 누수 테스트를 위해 GC를 집중적으로 실행합니다.

public class Pcg110485 {

    static
    void l(){new Thread();}

    public static void main(String[] args) {

        while(true){
            l();
            System.gc();
            System.out.println(Runtime.getRuntime().freeMemory());
        }
    }
}

Befunge ( 곰팡이 ), 1 바이트

$

이것은 플랫폼 및 버전에 따라 다를 수 있지만 (Windows에서는 버전 1.0.4로만 테스트했습니다) 곰팡이 는 역사적으로 매우 누출 된 해석기였습니다. $(드롭) 명령은 빈 스택에 아무것도하지해야하지만,이 코드를 통해 반복 든 매우 빠르게 많은 메모리 누수가 관리합니다. 몇 초 만에 몇 개의 기가 소모되고 "메모리 부족"오류가 발생합니다.

반드시 $명령 일 필요는 없습니다 . 무엇이든 할 수 있습니다. 빈 소스 파일로는 작동하지 않습니다. 적어도 하나의 작업이 있어야합니다.

스위프트 3, 38 바이트

새로운 버전:

class X{var x: X!};do{let x=X();x.x=x}

x 자체에 대한 강력한 참조가 있으므로 할당 해제되지 않아 메모리 누수가 발생합니다.

구 버전:

class X{var y:Y!}
class Y{var x:X!}
do{let x=X();let y=Y();x.y=y;y.x=x}

x에 대한 강력한 참조를 포함 y하며 그 반대도 마찬가지입니다. 따라서 어느 것도 할당 해제되지 않아 메모리 누수가 발생합니다.

델파이 (오브젝트 파스칼)-33 바이트

가변적이고 완전한 콘솔 프로그램없이 객체 만들기 :

program;begin TObject.Create;end.

프로젝트에서 FastMM4를 활성화하면 메모리 누수가 표시됩니다.

C #-84 바이트

class P{static void Main(){System.Runtime.InteropServices.Marshal.AllocHGlobal(1);}}

이것은 정확히 1 바이트의 관리되지 않는 메모리를 할당 한 다음을 잃어 버립니다 IntPtr. 루프에 채우고 응용 프로그램이 충돌하기를 기다리는 것으로 테스트 할 수 있습니다 (속도를 높이기 위해 몇 가지 0을 추가해야 할 수도 있습니다).

나는 생각 System.IO.File.Create("a");과 같은,하지만 난이 응용 프로그램 자체로, 반드시 메모리 누수 것을 확신 아니에요 것이다 메모리를 수집, 그것은 그 아래에있는 OS의 수 (때문에 누출 Close이나가 Dispose호출되지 않은이). 파일 액세스에도 파일 시스템 권한이 필요하며 아무도 그에 의존하기를 원하지 않습니다. 그리고 파이널 라이저 호출을 멈추는 것이 없기 때문에 (기본 리소스를 사용할 수 있음) 프레임 워크에 이러한 종류의 판단 오류 (어느 정도)를 완화시키기 위해 포함되어 있기 때문에 이것이 유출되지 않습니다. 비 결정적 파일 잠금과 겉보기에 프로그래머와 혼동하기 위해 (당신이 냉소적 인 경우). 이 문제를 바로 잡아 준 Jon Hanna에게 감사합니다.

나는 더 짧은 길을 찾을 수 없다는 것에 약간 실망했다. .NET GC가 작동합니다 .mscorlib에서IDisposables 확실히 누출 될 것이라고 생각할 수는 없습니다 (실제로 최종 자, 성가신 것 같습니다) , 관리되지 않는 메모리를 할당하는 다른 방법을 알지 못합니다 (PInvoke 부족 )을 반영하고 반영하면 언어 의미 (예 : 접근자가없는 개인 구성원 또는 클래스)와 상관없이이를 참조하는 모든 항목을 찾을 수 있습니다.

팩터 , 13 바이트

Factor에는 자동 메모리 관리 기능이 있지만 일부 libc 기능에 액세스 할 수도 있습니다.

1 malloc drop

1 바이트의 메모리를 수동으로 할당하고 주소를 반환 한 다음 삭제합니다.

malloc 실제로 메모리 누수와 두 번의 해제를 추적하기 위해 사본을 등록하지만 누출 된 것을 식별하는 것은 쉬운 일이 아닙니다.

그 참조를 정말로 잃어 버리는 것을 선호한다면 :

1 (malloc) drop

테스트 누출 [ 1 malloc drop ] leaks.:

| Disposable class | Instances |                    |
| malloc-ptr       | 1         | [ List instances ] |

테스트 누출 [ 1 (malloc) drop ] leaks.:

| Disposable class | Instances | |

아뇨! 불쌍한 요소, 이제 알츠하이머가 있습니다! 디:

공통 리스프 (SBCL 만 해당) 28 26 바이트

sb-alien::(make-alien int)

다음과 같이 실행합니다. sbcl --eval 'sb-alien::(make-alien int)'; 아무것도 인쇄되거나 반환되지 않지만 메모리 할당이 발생합니다. 양식을에 감싸면 (print ...)REPL에 포인터가 표시됩니다.

1. package::(form)양식을 읽는 동안 현재 패키지를 임시로 바인딩하기위한 SBCL의 특수 표기법입니다. 이 모두 접두사를 방지하기 위해 여기에 사용 make-alien하고 int와 sb-alien. 현재 패키지가 시작으로 설정되어 있지 않기 때문에 현재 패키지 가이 패키지로 설정되어 있다고 가정하는 것이 부정적이라고 생각합니다.

2. make-alien 주어진 유형과 선택적 크기 (malloc 사용)에 메모리를 할당합니다.

3. REPL에서 이것을 실행할 때 0REPL이 포인터를 반환하지 않고 대신 해당 값을 반환하도록 할당 후에 추가하십시오 . REPL 지난 3 개 반환 값 (참조 기억 때문에 그렇지 않으면, 그것은 더 진짜 누수가 없을 것 *, **,*** ) 우리는 여전히 할당 된 메모리를 해제 할 수있는 기회를 가질 수있다.

PrzemysławP 덕분에 2 바이트가 제거되었습니다. 감사합니다!

AutoIt , 39 바이트

#include<Memory.au3>
_MemGlobalAlloc(1)

힙에서 1 바이트를 할당합니다. 에 의해 반환 된 핸들 _MemGlobalAlloc이 삭제 되므로 해당 할당을 명시 적으로 해제 할 수있는 방법이 없습니다.

C ++, 16 바이트

main(){new int;}

나는 누출을 확인하기 위해 valgrind가 없지만 꽤해야합니다. 그렇지 않으면 시도 할 것입니다 :

main(){[]{new int;}();}

발 그린 드 결과

(실제로 누출됩니다)

==708== LEAK SUMMARY:
==708==    definitely lost: 4 bytes in 1 blocks

자바 (오픈 JDK 9) , 322 (220) 바이트

import sun.misc.*;class Main{static void main(String[]a)throws Exception{java.lang.reflect.Field f=Unsafe.class.getDeclaredField("theUnsafe");f.setAccessible‌​(1<2);((Unsafe)f.get‌​(1)).allocateMemory(‌​1);}}

온라인으로 사용해보십시오!

이것은 문자열 캐시를 사용하지 않는 다른 메모리 누수입니다. 그것은 당신의 RAM의 절반을 할당하고 당신은 그것으로 아무것도 할 수 없습니다.

모든 바이트를 저장 한 zeppelin에게 감사합니다.

c, 9 바이트

main(){}

증명:

localhost/home/elronnd-10061: cat t.c
main(){}
localhost/home/elronnd-10062: valgrind gcc t.c
==10092== Memcheck, a memory error detector
==10092== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==10092== Using Valgrind-3.12.0 and LibVEX; rerun with -h for copyright info
==10092== Command: gcc t.c
==10092==
t.c:1:1: warning: return type defaults to ‘int’ [-Wimplicit-int]
 main(){}
 ^~~~
==10092==
==10092== HEAP SUMMARY:
==10092==     in use at exit: 178,518 bytes in 73 blocks
==10092==   total heap usage: 362 allocs, 289 frees, 230,415 bytes allocated
==10092==
==10092== LEAK SUMMARY:
==10092==    definitely lost: 4,659 bytes in 8 blocks
==10092==    indirectly lost: 82 bytes in 5 blocks
==10092==      possibly lost: 0 bytes in 0 blocks
==10092==    still reachable: 173,777 bytes in 60 blocks
==10092==         suppressed: 0 bytes in 0 blocks
==10092== Rerun with --leak-check=full to see details of leaked memory
==10092==
==10092== For counts of detected and suppressed errors, rerun with: -v
==10092== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

C #, 109 바이트

public class P{static void Main({for(;;)System.Xml.Serialization.XmlSerializer.FromTypes(new[]{typeof(P)});}}

우리는 생산 코드에서 이러한 누수의 배후에있는 아이디어를 발견하고 연구 하여이 기사로 이어졌습니다 . 주요 문제는 기사 에서이 긴 인용문에 있습니다 (자세한 내용은 읽으십시오).

PurchaseOrder에 대한 코드를 검색 page_load하면 내 페이지 중 하나 에서이 코드 줄을 찾습니다.XmlSerializer serializer = new XmlSerializer(typeof(PurchaseOrder), new XmlRootAttribute(“”));

이것은 무고한 코드 조각처럼 보일 것입니다. 우리는 만들 XMLSerializer를 들어 PurchaseOrder. 그러나 표지 아래에서 어떻게됩니까?

XmlSerializerReflector 를 사용하여 생성자를 살펴보면 this.tempAssembly = XmlSerializer.GenerateTempAssembly(this.mapping, type, defaultNamespace, location, evidence);임시 (동적) 어셈블리를 생성하는 호출자를 찾습니다 . 따라서이 코드가 실행될 때마다 (즉, 페이지에 도달 할 때마다) 새 어셈블리가 생성됩니다.

어셈블리를 생성하는 이유는 직렬화 및 역 직렬화를위한 함수를 생성해야하고 어딘가에 상주해야하기 때문입니다.

알았어 ... 조립품을 만들면 어떻게 될까? 완료되면 바로 사라져야합니까?

글쎄요… 어셈블리는 GC 힙의 객체가 아니며, GC는 실제로 어셈블리를 인식하지 못하므로 가비지 수집을받지 않습니다. 1.0 및 1.1에서 어셈블리를 제거하는 유일한 방법은 어셈블리가있는 앱 도메인을 언로드하는 것입니다.

그리고 왓슨 박사의 문제가 있습니다.

Visual Studio 2015의 컴파일러에서 실행하고 진단 도구 창을 사용하면 약 38 초 후 다음 결과가 표시됩니다. 프로세스 메모리가 꾸준히 증가하고 있으며 가비지 콜렉터 (GC)는 계속 실행되지만 아무 것도 수집 할 수 없습니다.

C 30 바이트

f(){int *i=malloc(sizeof(4));}

발 그린 드 결과 :

         ==26311== HEAP SUMMARY:
         ==26311==     in use at exit: 4 bytes in 1 blocks
         ==26311==   total heap usage: 1 allocs, 0 frees, 4 bytes allocated
         ==26311== 
         ==26311== LEAK SUMMARY:
         ==26311==    definitely lost: 4 bytes in 1 blocks
         ==26311==    indirectly lost: 0 bytes in 0 blocks
         ==26311==      possibly lost: 0 bytes in 0 blocks
         ==26311==    still reachable: 0 bytes in 0 blocks
         ==26311==         suppressed: 0 bytes in 0 blocks
         ==26311== Rerun with --leak-check=full to see details of leaked memory

다트, 76 바이트

import'dart:async';main()=>new Stream.periodic(Duration.ZERO).listen((_){});

JavaScript 답변과 약간 비슷합니다. .listenDart 스트림 객체 를 호출 하면 StreamSubscription이 제공되어 스트림 연결을 끊을 수 있습니다. 그러나 버리면 스트림에서 구독을 취소하여 누수를 일으킬 수 없습니다. 누출을 해결할 수있는 유일한 방법은 Stream 자체가 수집되지만 여전히 StreamController + Timer 콤보에 의해 내부적으로 참조되는 경우입니다.

불행히도 다트는 내가 시도한 다른 것들에 비해 너무 똑똑합니다. ()async=>await new Completer().futureawait를 사용하는 것과 같은 동작을하지 않기 때문에 작동하지 않습니다 new Completer().future.then(<continuation>). 두 번째 Completer가 참조되지 않은 클로저 자체가 소멸 될 수 있습니다 .future.

또한 GC에 의해 분리 물 (일명 스레드)이 정리되므로 새 스레드에서 자신을 생성하고 즉시 일시 중지 ( import'dart:isolate';main(_)=>Isolate.spawn(main,0,paused:true);) 할 수 없습니다. 무한 루프 ( import'dart:isolate';f(_){while(true){print('x');}}main()=>Isolate.spawn(f,0);) 로 분리를 생성하더라도 분리가 종료되고 프로그램이 종료됩니다.

오 잘

스위프트, 12 바이트

[3,5][0...0]

설명:

이는 언어에서 메모리 수동 관리, 자동 참조 카운트 (ARC, Swift와 같은) 또는 전체 가비지 수집을 사용하는지 여부에 관계없이 모든 언어에서 발생할 수있는 사실상의 메모리 누수입니다.

[3,5]단지 배열 리터럴입니다. 이 배열은 적어도이 두 요소에 충분한 메모리를 할당합니다. 3및 5단지 임의이다.

첨자 (인덱싱)는을 Array<T>생성합니다 ArraySlice<T>. An ArraySlice<T>은 생성 된 Array의 메모리에 대한 뷰입니다.

[3,5][0...0]ArraySlice<Int>값이 인을 생성합니다 .[3] . 점을 유의 3이 슬라이스가 동일 3는 AS 소자 3본래의이 Array상기 도시 하지 사본.

결과 슬라이스는 변수에 저장되어 사용될 수 있습니다. 원래 배열은 더 이상 참조되지 않으므로 할당을 해제 할 수 있다고 생각합니다. 그러나 그것은 할 수 없습니다.

슬라이스는 원래 배열의 메모리에 뷰를 표시하므로 슬라이스가 존재하는 한 원래 배열을 활성 상태로 유지해야합니다. 따라서 2할당 된 원래 요소 크기의 메모리 중 첫 번째 요소 크기의 메모리 만 사용되며 다른 하나는 첫 번째 요소를 할당하지 않도록 존재해야합니다. 메모리의 두 번째 요소 크기는 디 팩터 유출입니다.

이 문제에 대한 해결책은 살아있는 작은 배열의 큰 배열을 오랫동안 유지하지 않는 것입니다. 슬라이스 내용을 유지해야하는 경우이를 메모리로 복사하면 메모리가 복사되어 원래 배열의 메모리에 대한 종속성이 제거됩니다.

Array([3,5][0...0])

해결 방법 1 : C (Mac OS X x86_64), 109 바이트

golf_sol1.c의 소스

main[]={142510920,2336753547,3505849471,284148040,2370322315,2314740852,1351437506,1208291319,914962059,195};

위의 프로그램은 __DATA 세그먼트에 대한 실행 액세스 권한으로 컴파일해야합니다.

clang golf_sol1.c -o golf_sol1 -Xlinker -segprot -Xlinker __DATA -Xlinker rwx -Xlinker rwx

그런 다음 프로그램을 실행하려면 다음을 실행하십시오.

./golf_sol1 $(ruby -e 'puts "\xf5\xff\xff\xfe\xff\xff\x44\x82\x57\x7d\xff\x7f"')

결과 :

불행히도 Valgrind는 시스템 호출에서 할당 된 메모리를 감시하지 않으므로 누출을 감지 할 수 없습니다.

그러나 vmmap을 보면 할당 된 메모리의 큰 덩어리 (MALLOC 메타 데이터)를 볼 수 있습니다.

                                VIRTUAL   REGION 
REGION TYPE                        SIZE    COUNT (non-coalesced) 
===========                     =======  ======= 
Kernel Alloc Once                    4K        2 
MALLOC guard page                   16K        4 
MALLOC metadata                   16.2M        7 
MALLOC_SMALL                      8192K        2         see MALLOC ZONE table below
MALLOC_TINY                       1024K        2         see MALLOC ZONE table below
STACK GUARD                       56.0M        2 
Stack                             8192K        3 
VM_ALLOCATE (reserved)             520K        3         reserved VM address space (unallocated)
__DATA                             684K       42 
__LINKEDIT                        70.8M        4 
__TEXT                            5960K       44 
shared memory                        8K        3 
===========                     =======  ======= 
TOTAL                            167.0M      106 
TOTAL, minus reserved VM space   166.5M      106 

설명

개선 된 솔루션으로 넘어 가기 전에 실제로 여기서 무슨 일이 일어나고 있는지 설명해야한다고 생각합니다.

이 주요 함수는 C의 누락 된 형식 선언을 남용합니다 (따라서 문자를 쓰지 않아도 int로 기본 설정됩니다). 링커는라는 심볼을 찾을 수 있는지 여부에만 관심을 갖습니다.main 는 호출 할 . 그래서 여기서 우리는 main을 배열 코드로 초기화 할 int 배열로 만들고 있습니다. 이 때문에 main은 __TEXT 세그먼트에 추가되지 않고 __DATA 세그먼트에 추가되므로 실행 가능한 __DATA 세그먼트로 프로그램을 컴파일해야합니다.

main에있는 쉘 코드는 다음과 같습니다.

movq 8(%rsi), %rdi
movl (%rdi), %eax
movq 4(%rdi), %rdi
notl %eax
shrq $16, %rdi
movl (%rdi), %edi
leaq -0x8(%rsp), %rsi
movl %eax, %edx
leaq -9(%rax), %r10
syscall
movq (%rsi), %rsi
movl %esi, (%rsi)
ret

이 작업은 syscall 함수를 호출하여 메모리 페이지를 할당하는 것입니다 (syscall mach_vm_allocate는 내부적으로 사용함). RAX는 0x100000a (원하는 함수를 알려주는 syscall을 알려줘야 함) 여야하지만 RDI는 할당 대상 (이 경우 mach_task_self ()이 되길 원함)을 유지하지만 RSI는 새로 작성된 메모리에 포인터를 쓸 주소를 보유해야합니다. (따라서 스택의 섹션을 가리키고 있습니다.) RDX는 할당 크기를 유지합니다 (우리는 바이트를 절약하기 위해 RAX 또는 0x100000a로 전달합니다) .R10은 플래그를 보유합니다 (우리는 할 수 있음을 나타냅니다) 어디서나 할당 할 수 있습니다.

이제 RAX와 RDI가 어디에서 가치를 얻는 지 분명하지 않습니다. RAX는 0x100000a 여야하고 RDI는 mach_task_self ()가 반환하는 값이어야합니다. 운 좋게도 mach_task_self ()는 실제로 매번 동일한 메모리 주소에있는 변수 (mach_task_self_)의 매크로입니다 (다시 부팅 할 때 변경해야 함). 내 특정 인스턴스에서 mach_task_self_는 0x00007fff7d578244에 있습니다. 따라서 지침을 줄이기 위해 argv 에서이 데이터를 대신 전달합니다. 이런 식으로 프로그램을 실행하는 이유$(ruby -e 'puts "\xf5\xff\xff\xfe\xff\xff\x44\x82\x57\x7d\xff\x7f"')첫 번째 주장. 문자열은 두 값을 합한 것입니다. 여기서 RAX 값 (0x100000a)은 32 비트이며 여기에 1의 보수가 적용되었습니다 (따라서 null 바이트는 없습니다. 원본을 얻을 수있는 값은 아닙니다). 다음 값은 RDI (0x00007fff7d578244)는 왼쪽에 2 개의 여분의 정크 바이트가 추가되어 왼쪽으로 이동되었습니다 (널 바이트를 제외하기 위해 다시 오른쪽으로 이동하여 원래로 되돌립니다).

syscall 후에 우리는 새로 할당 된 메모리에 쓰고 있습니다. 그 이유는 mach_vm_allocate (또는이 syscall)를 사용하여 할당 된 메모리는 실제로 VM 페이지이며 자동으로 메모리에 페이징되지 않기 때문입니다. 오히려 데이터가 기록 될 때까지 예약 된 다음 해당 페이지가 메모리에 매핑됩니다. 예약 된 경우에만 요구 사항을 충족하는지 확실하지 않았습니다.

다음 솔루션에서는 쉘 코드에 널 바이트가 없다는 점을 이용하므로 프로그램 코드 외부로 이동하여 크기를 줄일 수 있습니다.

해결 방법 2 : C (Mac OS X x86_64), 44 바이트

golf_sol2.c의 소스

main[]={141986632,10937,1032669184,2,42227};

위의 프로그램은 __DATA 세그먼트에 대한 실행 액세스 권한으로 컴파일해야합니다.

clang golf_sol2.c -o golf_sol2 -Xlinker -segprot -Xlinker __DATA -Xlinker rwx -Xlinker rwx

그런 다음 프로그램을 실행하려면 다음을 실행하십시오.

./golf_sol2 $(ruby -e 'puts "\xb8\xf5\xff\xff\xfe\xf7\xd0\x48\xbf\xff\xff\x44\x82\x57\x7d\xff\x7f\x48\xc1\xef\x10\x8b\x3f\x48\x8d\x74\x24\xf8\x89\xc2\x4c\x8d\x50\xf7\x0f\x05\x48\x8b\x36\x89\x36\xc3"')

동일한 크기의 할당을 수행하므로 결과는 이전과 동일해야합니다.

설명

누출 코드 조각을 프로그램 외부로 옮겼다는 점을 제외하면 솔루션 1과 거의 동일한 개념을 따릅니다.

main에있는 쉘 코드는 이제 다음과 같습니다.

movq 8(%rsi), %rsi
movl $42, %ecx
leaq 2(%rip), %rdi
rep movsb (%rsi), (%rdi)

이것은 기본적으로 argv에 전달한 쉘 코드를이 코드 다음에 복사합니다 (복사 한 후에는 삽입 된 쉘 코드를 실행합니다). 우리에게 유리한 점은 __DATA 세그먼트는 최소한 페이지 크기이므로 코드가 크지 않아도 "안전하게"더 많이 쓸 수 있다는 것입니다. 단점은 여기서 이상적인 솔루션입니다. 복사본이 필요하지 않습니다. 대신 argv에서 직접 쉘 코드를 호출하고 실행합니다. 그러나 불행히도이 메모리에는 실행 권한이 없습니다. 이 메모리의 권한을 변경할 수 있지만 단순히 복사하는 것보다 더 많은 코드가 필요합니다. 다른 전략은 외부 프로그램에서 권한을 변경하는 것입니다 (하지만 나중에 더 자세히 설명).

argv에 전달하는 쉘 코드는 다음과 같습니다.

movl $0xfefffff5, %eax
notl %eax
movq $0x7fff7d578244ffff, %rdi
shrq $16, %rdi
movl (%rdi), %edi
leaq -0x8(%rsp), %rsi
movl %eax, %edx
leaq -9(%rax), %r10
syscall
movq (%rsi), %rsi
movl %esi, (%rsi)
ret

이것은 이전 코드와 거의 동일하지만 EAX 및 RDI 값을 직접 포함한다는 점만 다릅니다.

가능한 해결 방법 1 : C (Mac OS X x86_64), 11 바이트

프로그램을 외부에서 수정한다는 아이디어는 누출 프로그램을 외부 프로그램으로 옮길 수있는 솔루션을 제공합니다. 실제 프로그램 (제출)이 단지 더미 프로그램 인 경우, 누수 프로그램은 대상 프로그램에 약간의 메모리를 할당합니다. 이제 이것이이 도전에 대한 규칙에 해당되는지 확실하지 않지만 그럼에도 불구하고 공유합니다.

따라서 타겟 프로그램을 챌린지 프로그램으로 설정 한 외부 프로그램에서 mach_vm_allocate를 사용하는 경우, 챌린지 프로그램은 다음과 같은 라인 만 있으면됩니다.

main=65259;

그 쉘 코드가 단순히 짧은 점프 (무한 점프 / 루프)이므로 프로그램은 열린 상태로 유지되며 외부 프로그램에서 참조 할 수 있습니다.

가능한 해결책 2 : C (Mac OS X x86_64), 8 바이트

나는 valgrind 출력을 볼 때 재미있게도 적어도 valgrind에 따르면 dyld가 메모리를 누출하는 것을 보았습니다. 따라서 모든 프로그램이 실제로 일부 메모리를 누출하고 있습니다. 이 경우 우리는 실제로 아무것도하지 않는 (단순히 종료) 프로그램을 만들 수 있으며 실제로 메모리가 누출됩니다.

출처:

main(){}


==55263== LEAK SUMMARY:
==55263==    definitely lost: 696 bytes in 17 blocks
==55263==    indirectly lost: 17,722 bytes in 128 blocks
==55263==      possibly lost: 0 bytes in 0 blocks
==55263==    still reachable: 0 bytes in 0 blocks
==55263==         suppressed: 16,316 bytes in 272 blocks

일반 영어 , 71 70 58 35 바이트

빈 줄을 삭제하여 1 바이트를 제거했습니다. "bogon"유형 정의를 제거하고 "bogon"하위 유형 대신 상위 "thing"유형을 사용하여 12 바이트를 제거했습니다. 완전한 프로그램에서 메모리 누수 루틴으로 전환하여 23 바이트를 제거했습니다.

골프 버전 :

To x:
Allocate memory for a thing.

완전한 프로그램 인 ungolfed 버전은 하위 유형 정의를 사용하며 메모리가 누출되지 않습니다.

A bogon is a thing.

To do something:
  Allocate memory for a bogon.
  Destroy the bogon.

To run:
  Start up.
  Do something.
  Shut down.

"x"의 골프 버전을 호출하면 "x"호출 횟수에 비례하여 메모리가 누출됩니다. 골프 버전에서 "사물 할당 해제" 메모리 누수를 해결합니다.

일반 영어는 기본적으로 메모리 누수를 확인합니다. 메모리 누수 버전이 실행되면 프로그램이 종료되기 직전에 대화 상자가 나타납니다. 대화 상자에는 제목 "debug", 메시지 "1 drip"및 "OK"버튼이 있습니다. 누수 함수를 여러 번 호출할수록 메시지의 "드립"수가 많아집니다. 메모리 누수가없는 버전이 실행되면 대화 상자가 나타나지 않습니다.

일반 영어에서 "thing"은 이중 연결 목록의 항목에 대한 포인터입니다. "사물", "시작"및 "종료"는 "국수"라는 모듈에서 정의되며, 각 프로젝트에 (보통 별도 파일로) 복사해야합니다. "A", "the", "to", "to 메모리 할당"및 "파괴"는 컴파일러에서 정의됩니다.