79

आपका कार्य कोड लिखना है जो कम से कम एक बाइट को कम से कम बाइट्स में लीक करेगा। स्मृति को केवल आवंटित नहीं किया जाना चाहिए ।

लीक की गई मेमोरी वह मेमोरी है जिसे प्रोग्राम आवंटित करता है लेकिन मेमोरी को ठीक से डील करने से पहले एक्सेस करने की क्षमता खो देता है। अधिकांश उच्च स्तरीय भाषाओं के लिए यह मेमोरी ढेर पर आवंटित की जानी है।

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 ) होता है, यदि आप मेमोरी को लीक करने की पुष्टि करने के लिए ऐसे डीबगर से आउटपुट शामिल कर सकते हैं।

लक्ष्य अपने स्रोत में बाइट्स की संख्या को कम करना है।

code-golf

— श्रीओटचिलिज्म ओ'जैसिक
स्रोत

2

शायद आपके पास लीक की गई राशि की अलग-अलग सीमाएं हो सकती हैं और इस बात पर निर्भर करता है कि आप अपनी बाइट की संख्या का कितना% खोते हैं

— क्रिस्टोफर

11

@ChristopherPeart एक के लिए मैं चुनौतियों पर बोनस का प्रशंसक नहीं हूं और दो के लिए जैसा कि आप पहले ही दिखा चुके हैं कि अनबाउंड मेमोरी को लीक करना बहुत आसान है।

— श्रीओटचिलिज्म ओ'जैविक

1

संबंधित । यद्यपि कोई डुप्लिकेट नहीं है, क्योंकि उस प्रश्न के अधिकांश उत्तर वास्तव में मेमोरी को लीक करने के बजाय स्मृति में एक अनंत पहुंच योग्य संरचना बनाते हैं।

2

क्या विचार है? इस मेम को मुक्त नहीं किया जा सकता है? मुझे लगता है कि इसके लिए कचरा एकत्र करने वाली भाषाओं के लिए देशी निष्पादन या बग का दोहन करने की आवश्यकता होगी।

— अकोस्टैडिनोव

7

मैं देखता हूं कि गोल्फिंग के लिए तैयार की गई भाषाएं इस पर बुरी तरह से कैसे विफल हो जाती हैं ...

— खूंटी

89

पर्ल (5.22.2), 0 बाइट्स

इसे ऑनलाइन आज़माएं!

मुझे पता था कि वहाँ एक खाली कार्यक्रम पर लीक हुई कुछ भाषा होगी। मैं उम्मीद कर रहा था कि यह एक एसोलैंग होगा, लेकिन 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)

16

मुझे बेलगाम उत्तर पसंद आया, लेकिन यह (IMHO) बहुत अधिक खिंचाव वाला है, क्योंकि यह स्पष्ट रूप से दुभाषिया है जो स्मृति को लीक करता है, अर्थात मुझे निश्चित रूप से खो दिया गया है: 14 ब्लॉकों में 7,742 बाइट्स जब मैं perl --versionअपनी मशीन पर चलाता हूं। , इसके बावजूद यह कभी भी किसी भी कार्यक्रम को चलाने के लिए नहीं होता है।

— जेपेलिन

11

@zeppelin: सहमत हैं, लेकिन हमारे नियमों के अनुसार, यह कार्यान्वयन है जो भाषा को परिभाषित करता है, इस प्रकार यदि कार्यान्वयन स्मृति को लीक करता है, तो भाषा के सभी प्रोग्राम स्मृति में रिसाव करते हैं। मुझे यकीन नहीं है कि मैं उस नियम से सहमत हूं, लेकिन इस बिंदु पर यह वास्तव में बदलने में सक्षम है।

8

यह नोड जेएस में भी काम करता है।

— डेनिस

6

ऐसा लगता है कि एक नए मानक बनाने में खामियों का

— माइकल हैम्पटन

46

अंत में एक पर्ल स्क्रिप्ट जिसे मैं समझ सकता हूं।

— user11153

66

सी, 48 31 22 बाइट्स

चेतावनी: इसे बहुत बार न चलाएं।

बहुत सारी मदद / विचारों के लिए डेनिस को धन्यवाद !

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

यह एक कदम आगे जाता है। shmgetसाझा मेमोरी को आवंटित करता है जो प्रोग्राम समाप्त होने पर डीलॉक्लेट नहीं किया जाता है। यह मेमोरी की पहचान करने के लिए एक कुंजी का उपयोग करता है, इसलिए हम एक uninitialized int का उपयोग करते हैं। यह तकनीकी रूप से अपरिभाषित व्यवहार है, लेकिन व्यावहारिक रूप से इसका मतलब है कि हम उस मूल्य का उपयोग करते हैं जो स्टैक के शीर्ष से ऊपर होता है जब यह कहा जाता है। यह अगली बार लिखा जाएगा कि स्टैक में कुछ भी जोड़ा जाता है, इसलिए हम कुंजी खो देंगे।

केवल एक ही मामला है कि यह काम नहीं करता है यदि आप यह पता लगा सकते हैं कि स्टैक पर पहले क्या था। अतिरिक्त 19 बाइट्स के लिए आप इस समस्या से बच सकते हैं:

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

या, 26 बाइट्स के लिए:

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

लेकिन इस एक के साथ, कार्यक्रम के बाहर निकलने के बाद मेमोरी लीक हो जाती है। प्रोग्राम को चलाने के दौरान मेमोरी तक पहुंच होती है जो कि नियमों के विरुद्ध है, लेकिन प्रोग्राम समाप्त होने के बाद हम कुंजी तक पहुंच खो देते हैं और मेमोरी अभी भी आवंटित की जाती है। इसके लिए एड्रेस स्पेस लेआउट रैंडमाइजेशन (ASLR) की आवश्यकता होती है, अन्यथा &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

— रिले
स्रोत

1

@AndrewSavinykh सैद्धांतिक रूप से, shmid को एक फ़ाइल में संग्रहीत किया जा सकता था और भविष्य में एक कार्यक्रम इसे संलग्न कर सकता था। यह है कि यूनिक्स साझा स्मृति कैसे काम करती है ...

— 22

1

@AndrewSavinykh साझा की गई मेमोरी मूल रूप से एक संसाधन बन जाती है जिसे OS अन्य प्रक्रियाओं को दे सकता है। यह एक ऐसी फाइल के समान है जो RAM में रहती है और कोई भी प्रक्रिया जो नाम (कुंजी) को जानती है, उसे तब तक एक्सेस करती है जब तक वह डिलीट नहीं हो जाती। एक ऐसी प्रक्रिया की कल्पना करें जो एक संख्या की गणना करती है और इसे मेमोरी में संग्रहीत करती है और उस प्रक्रिया से पहले बाहर निकल जाती है जो डेटा को साझा की गई मेमोरी से जोड़ती है। इस स्थिति में, यदि OS मेमोरी को मुक्त करता है, तो दूसरी प्रक्रिया इसे प्राप्त नहीं कर सकती है।

— रिले

35

इसे पोस्ट करने के लिए आपका धन्यवाद। मैंने साझा मेमोरी लीक के खिलाफ टीआईओ की रक्षा की।

— डेनिस

4

@ डेनिस इसीलिए मैंने TIO लिंक पोस्ट नहीं किया। मुझे नहीं पता था कि यह संरक्षित है या नहीं।

— रिले

12

मुझे पसंद है कि आप परिदृश्य समस्या का वर्णन करने के लिए शब्द समस्या का उपयोग कैसे करते हैं जहां कार्यक्रम उद्देश्य से कम मेमोरी लीक करता है।

— कैस्परल्ड

40

अनलम्बदा ( `c-refcnt/unlambda`), 1 बाइट

इसे ऑनलाइन आज़माएं!

यह वास्तव में एक पूर्व-मौजूदा दुभाषिया खोजने के बारे में एक चुनौती है जो बहुत सरल कार्यक्रमों पर स्मृति को लीक करता है। इस मामले में, मैंने अनलैम्ब्डा का उपयोग किया। एक से अधिक आधिकारिक अनलम्ब्डा दुभाषिया है, लेकिन c-refcntनिर्माण करने में सबसे आसान है, और यहां इसकी उपयोगी संपत्ति है कि यह स्मृति को लीक करता है जब कोई कार्यक्रम सफलतापूर्वक चलता है। इसलिए मुझे यहां जो कुछ भी देने की आवश्यकता थी, वह सबसे सरल संभव कानूनी अनलांबा कार्यक्रम था, एक नो-ऑप। (ध्यान दें कि खाली कार्यक्रम यहां काम नहीं करता है; दुभाषिया के दुर्घटनाग्रस्त होने के समय स्मृति अभी भी उपलब्ध है।)

सत्यापन

$ wget ftp http://ftp.madore.org/pub/madore/unlambda/unlambda-2.0.0.tar.gz
... कटाव ...
2017-02-18 18:11:08 (975 KB / s) - 'अनलम्बडा-2.0.0.tar.gz' सहेजा गया [252828]
$ टर xf अनलैम्बडा-2.0.0.tar.gz 
$ cd अनलम्बाडा 2.0.0 / c-refcnt /
$ जीसीसी
$ इको -नी | valgrind ./a.out / dev / stdin
... कटाव ...
== 3417 == LEAK सारांश:
== 3417 == निश्चित रूप से हार गया: 1 ब्लॉकों में 40 बाइट्स
== 3417 == अप्रत्यक्ष रूप से खो गया: 0 ब्लॉक में 0 बाइट्स
== 3417 == संभवतः खो गया: 0 ब्लॉक में 0 बाइट्स
== 3417 == अभी भी पहुंच योग्य: 0 ब्लॉक में 0 बाइट्स
== 3417 == दमन: 0 ब्लॉक में 0 बाइट्स
== 3417 == 
== 3417 == ज्ञात और दबी हुई त्रुटियों की गणना के लिए: -v के साथ पुन: चलाएँ
== 3417 == त्रुटि सारांश: 1 संदर्भों से 1 त्रुटियां (दबी हुई: 0 0 से 0)

39

टीआई-बेसिक, 12 बाइट्स

While 1
Goto A
End
Lbl A
Pause

"... मेमोरी रिसाव वह जगह है जहाँ आप एक लोटो के भीतर एक गोटो / लबल का उपयोग करते हैं या यदि एंड कमांड के पहुंचने से पहले उस नियंत्रण संरचना से बाहर कूदने के लिए सशर्त (कुछ भी जिसके पास एंड कमांड है) ..." (अधिक)

— Timtech
स्रोत

7

वाह, मुझे लगता है कि मुझे यह याद है। मैं अपने पुराने बुनियादी कार्यक्रमों में अपने छोरों से बाहर कूदता रहा और देखा कि कैसे मेरे TI-84 + को धीमा और धीमा मिला ...

— रे

2

हां, हम में से ज्यादातर लोग इस भावना को जानते हैं;) @ रेकूपा

— टिमटेक

13

टीआई बेसिक के लिए +1। मैंने अपनी 9 वीं कक्षा के अधिकांश वर्ष उन चीजों की प्रोग्रामिंग में बिताए।

— markasoftware

क्या आपको Pause अंत में आवश्यकता है ? आप 2 बाइट्स बचा सकते हैं।

— kamoroso94

@ kamoroso94 मुझे ऐसा लगता है, क्योंकि "अगर एक कार्यक्रम समाप्त हो गया है तो रिसाव को साफ कर दिया जाएगा और आगे कोई समस्या नहीं होगी", इसलिए कार्यक्रम को समाप्त होने से रोकना है।

— टिमटेक

32

पायथन <3.6.5, 23 बाइट्स

property([]).__init__()

property.__init__करने के लिए लीक संदर्भ संपत्ति के पुराने fget, fset, fdel, और __doc__यदि आप पहले से प्रारंभ पर इसे कहते propertyउदाहरण। यह एक बग है, अंततः सीपीथॉन मुद्दे के 31787 के हिस्से के रूप में सूचित किया गया और पायथन 3.6.5 और पायथन 3.7.0 में तय किया गया । (इसके अलावा, हाँ, property([])एक ऐसी चीज़ है जो आप कर सकते हैं।)

— user2357112
स्रोत

क्या बग रिपोर्ट भेजी गई है?

— mbomb007

1

@ mbomb007: CPython जारी 31787.

— user2357112

27

सी #, 34 बाइट्स

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

इस समाधान को ढेर की आवश्यकता नहीं है। इसके लिए सिर्फ एक वास्तविक परिश्रमी जीसी ( गारबेज कलेक्टर ) की जरूरत है।

अनिवार्य रूप से यह जीसी को अपने दुश्मन में बदल देता है।

व्याख्या

जब भी विध्वंसक कहा जाता है, तो यह इस बुरे वर्ग के नए उदाहरण बनाता है जब तक कि समय समाप्त हो जाता है और जीसी को बस उस खाई को खत्म करने के लिए इंतजार किए बिना उस खाई को बताता है। तब तक हजारों नए उदाहरण बन चुके हैं।

यह "बुराई" है, जीसी जितना कठिन काम कर रहा है, उतना ही यह आपके चेहरे पर उड़ जाएगा।

अस्वीकरण : आपका जीसी मेरी तुलना में अधिक स्मार्ट हो सकता है। कार्यक्रम की अन्य परिस्थितियों में जीसी के कारण पहली वस्तु या इसके विनाशकर्ता की अनदेखी हो सकती है। इन मामलों में यह नहीं फूटेगा। लेकिन कई रूपों में यह होगा । यहां कुछ बाइट्स जोड़ना और हर संभव परिस्थितियों के लिए एक रिसाव सुनिश्चित करना हो सकता है। शायद बिजली के स्विच को छोड़कर।

परीक्षा

यहाँ एक परीक्षण सूट है :

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.8 जीबी थी

यह उत्तर एरिक लिपर्ट के अद्भुत लेख से प्रेरित है: जब आप जो कुछ भी जानते हैं वह गलत है ।

— MrPaulch
स्रोत

यह आकर्षक है। क्या कचरा संग्रहकर्ता "भूल" करता है कि कुछ चीजें मौजूद हैं और इस वजह से उनमें से कुछ खो दिया है? मैं c # के बारे में ज्यादा नहीं जानता। अब मैं भी सोच रहा हूं कि बम और रिसाव में क्या अंतर है? मैं कल्पना करता हूं कि एक समान फ़ाइस्को को एक कंस्ट्रक्टर के अंदर से एक कंस्ट्रक्टर को कॉल करके बनाया जा सकता है, या एक अनंत आवर्ती फ़ंक्शन हो सकता है जो कभी भी बंद नहीं होता है, हालांकि तकनीकी रूप से सिस्टम कभी भी उन संदर्भों का ट्रैक नहीं खोता है, यह सिर्फ अंतरिक्ष से बाहर चलाता है ...

— डॉन उज्ज्वल

1

एक कंस्ट्रक्टर के भीतर एक निर्माण एक ढेर अतिप्रवाह का कारण होगा। लेकिन एक उदाहरण के विध्वंसक एक फ्लैट पदानुक्रम में कहा जाता है। जीसी वास्तव में वस्तुओं का ट्रैक कभी नहीं खोता है। बस जब भी यह उन्हें नष्ट करने की कोशिश करता है तो अनजाने में नई वस्तुओं का निर्माण करता है। दूसरी ओर उपयोगकर्ता कोड की उक्त वस्तुओं तक कोई पहुंच नहीं है। इसके अलावा उल्लिखित विसंगतियां उत्पन्न हो सकती हैं क्योंकि जीसी अपने विध्वंसक को बुलाए बिना किसी वस्तु को नष्ट करने का निर्णय ले सकता है।

— MrPaulch

क्या सिर्फ इस्तेमाल करने से चुनौती पूरी नहीं होगी class L{~L(){new L();}}? AFAIK for(;;)ही यह रिसाव मेमोरी को तेज बनाता है, है ना?

— BgrWorker

1

दुख की बात है नहीं। चूंकि प्रत्येक नष्ट की गई वस्तु के लिए केवल एक नया उदाहरण बनने जा रहा है, जो फिर से दुर्गम है और विनाश के लिए चिह्नित है। दोहराएँ। विनाश के लिए केवल एक वस्तु लंबित होगी। बढ़ती जनसंख्या नहीं।

— MrPaulch

2

ज़रुरी नहीं। आखिरकार एक अंतिम रूप से नजरअंदाज कर दिया जाएगा। संबंधित वस्तु की परवाह किए बिना खाया जाएगा।

— MrPaulch

26

सी (जीसीसी) , 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)

— डेनिस
स्रोत

26

जावास्क्रिप्ट, 14 बाइट्स

golfed

setInterval(0)

एक डिफ़ॉल्ट अंतराल के साथ एक खाली अंतराल हैंडलर पंजीकृत करता है, जिसके परिणामस्वरूप टाइमर आईडी को रद्द करना (इसे रद्द करना असंभव है)।

मैंने एक गैर-डिफ़ॉल्ट अंतराल का उपयोग किया है, रिसाव को स्पष्ट करने के लिए कई मिलियन टाइमर बनाने के लिए, डिफ़ॉल्ट अंतराल का उपयोग करके सीपीयू को पागल बना देता है।

— टसेपेल्लिन
स्रोत

5

Haha मुझे अच्छा लगता है कि आपने 'Golfed' टाइप किया है, जिससे मुझे असंगत संस्करण के बारे में उत्सुकता होती है

— Martijn

9

यह इस तरह दिख सकता हैif(window && window.setInterval && typeof window.setInterval === 'function') { window.setInterval(0); }

— Tschallacka

3

वास्तव में, यह रद्द करना असंभव नहीं है: अंतराल (और टाइमआउट) आईडी क्रमिक रूप से गिने जाते हैं, इसलिए clearIntervalजब तक आपका अंतराल नहीं हो जाता है तब तक केवल एक वृद्धि आईडी के साथ कॉल करके चीज़ को रद्द करना काफी आसान है। उदाहरण के लिए:for(let i=0;i<1e5;i++){try{clearInterval(i);}catch(ex){}}

— user2428118

5

@ user2428118 जैसा कि zeppelin कहता है, यह C / C ++ लीक को "असली" कहने की तुलना में अधिक "वैध" नहीं है क्योंकि आप free()

— 12:00 पर

1

वाह, बहुत सारी चुनौतियाँ नहीं हैं जहाँ जावास्क्रिप्ट एक वास्तविक दावेदार है ...

— जेरेड स्मिथ

19

जावा, 10 बाइट्स

अंत में, जावा में एक प्रतिस्पर्धी जवाब!

golfed

". "::trim

यह एक विधि संदर्भ (एक स्ट्रिंग स्थिरांक के खिलाफ) है, जिसका उपयोग इस तरह किया जा सकता है:

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

एक शाब्दिक स्ट्रिंग ". "को स्वचालित रूप से वैश्विक इंटर्न स्ट्रिंग्स पूल में जोड़ा जाएगा, जैसा कि java.lang.Stringकक्षा द्वारा बनाए रखा गया है , और जैसा कि हमने तुरंत इसे ट्रिम कर दिया है, इसके संदर्भ को कोड में आगे पुन: उपयोग नहीं किया जा सकता (जब तक कि आप फिर से वही स्ट्रिंग घोषित नहीं करते)।

...

स्ट्रिंग्स का एक पूल, जो शुरू में खाली था, को निजी तौर पर क्लास स्ट्रिंग द्वारा बनाए रखा जाता है।

सभी शाब्दिक तार और स्ट्रिंग-मूल्यवान स्थिर अभिव्यक्ति को नजरबंद किया जाता है। स्ट्रिंग ™ शाब्दिकों को जावा ™ भाषा विनिर्देश के खंड 3.10.5 में परिभाषित किया गया है।

...

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

आप इसे "प्रोडक्शन ग्रेड" मेमोरी लीक में बदल सकते हैं, स्ट्रिंग को स्वयं से जोड़कर और फिर लूप में इंटर्न () विधि को स्पष्ट रूप से लागू कर सकते हैं ।

— टसेपेल्लिन
स्रोत

2

मैंने इसे C # के लिए माना है ... लेकिन मुझे नहीं लगता कि यह मायने रखता है, क्योंकि जैसा कि आप कहते हैं कि आप एक और स्ट्रिंग शाब्दिक को शामिल करके उस मेमोरी तक पहुंच सकते हैं । मुझे यह जानने में भी दिलचस्पी ("." + " ").intern()होगी कि वे क्या करेंगे (यदि वे उपयोगकर्ता इनपुट या w / e थे, तो हम कंपाइलर ऑप्टिमाइज़ेशन को छूट देते हैं)।

— विजुअलमेल

1

वास्तव में, केवल आम सहमति सबसे पतली है, मैं सिर्फ "कोड संकलन करना चाहिए" पक्ष पर दृढ़ता से हूं। मुझे अभी भी यकीन नहीं है कि मैं प्रश्न पर दिए गए इस समाधान को खरीदता हूं (इन तारों को मुक्त नहीं किया जा सकता है, और वे सामान्य ऑपरेटिंग कोड में पाए जा सकते हैं भले ही इसकी संभावना न हो), लेकिन मैं दूसरों को अपना निर्णय लेने के लिए आमंत्रित करता हूं

— विजुअलमेल

3

वह स्ट्रिंग भी दुर्गम नहीं है , अकेले लीक होने दें। हम किसी भी समय एक समान स्ट्रिंग को इंटर्न करके इसे पुनः प्राप्त कर सकते हैं। यदि इसे गिना जाए, तो कोई भी अप्रयुक्त वैश्विक चर (जावा में निजी स्थैतिक) एक रिसाव होगा। मेमोरी लीक को परिभाषित नहीं किया गया है।

— user2357112

3

@ user2357112 "... वह स्ट्रिंग भी दुर्गम नहीं है ..." यह केवल स्पष्ट दिखता है क्योंकि आप कोड देखते हैं। अब विचार करें कि आपको यह विधि संदर्भ X () आपके कोड के तर्क के रूप में है, आप जानते हैं कि यह एक स्ट्रिंग शाब्दिक को अंदर (और इंटर्न) आवंटित करता है, लेकिन आपको नहीं पता कि कौन सा वास्तव में है, यह "या" 123 "हो सकता है।" या (आमतौर पर) अज्ञात लंबाई के किसी भी अन्य स्ट्रिंग। क्या आप यह प्रदर्शित कर सकते हैं कि आप इसे अभी भी कैसे एक्सेस कर सकते हैं, या "इंटर्न" पूल में प्रवेश को निपटा सकते हैं?

— ज़ेपेलिन

2

@ user2357112 एक परिमित मेमोरी वाली मशीन पर, आप मेमोरी के किसी भी टुकड़े में संग्रहीत मान को एक्सेस कर सकते हैं simply by guessing it correctly, लेकिन इसका मतलब यह नहीं है कि मेमोरी लीक जैसी कोई चीज मौजूद नहीं है। there's probably some way to use reflection to determine the string's contents tooक्या आप इसे प्रदर्शित कर सकते हैं? (संकेत, String.intern () मूल कोड में लागू किया गया है )।

— zeppelin

17

जंग, 52 बाइट्स

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

सिस्टम मॉलॉक के साथ कुछ बाइट्स आवंटित करता है। यह मानता है कि गलत एबीआई स्वीकार्य है।

जंग (सिद्धांत में), 38 बाइट्स

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

हम ढेर पर मेमोरी आवंटित करते हैं, एक कच्चा पॉइंटर निकालते हैं, और फिर बस इसे अनदेखा करते हैं, इसे प्रभावी ढंग से लीक करते हैं। ( Box::into_rawतब छोटा होता है std::mem::forget)।

हालाँकि, डिफ़ॉल्ट रूप से जंग जेमलॉक का उपयोग करती है, जो कि किसी भी रिसाव का पता नहीं लगा सकता है । हम सिस्टम आबंटक में बदल सकते हैं लेकिन वह हैं इसमें 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)

— kennytm
स्रोत

बहुत बढ़िया। इस तरह की पोस्टों ने मुझे पिछले एक साल में जंग का पता लगाने के लिए प्रेरित किया, निश्चित रूप से सबसे मजेदार भाषाओं में से एक जिसे मैंने सीखने की कोशिश की है।

— उज्ज्वल

16

8086 एएसएम, 3 बाइट्स

यह उदाहरण मानता है कि एक सी क्रम में जुड़ा हुआ है।

jmp _malloc

यह e9 XX XXजहां XX XXके सापेक्ष पता है के लिए कोडांतरण_malloc

यह mallocस्मृति की अप्रत्याशित मात्रा को आवंटित करने का आह्वान करता है और फिर प्रक्रियाओं को समाप्त करते हुए तुरंत लौट आता है। डॉस जैसे कुछ ऑपरेटिंग सिस्टम पर, मेमोरी को तब तक पुनः प्राप्त नहीं किया जा सकता है जब तक कि सिस्टम रिबूट न हो जाए!

— FUZxxl
स्रोत

मैलोक के सामान्य कार्यान्वयन के परिणामस्वरूप मेमोरी को प्रक्रिया से बाहर होने पर मुक्त कर दिया जाएगा।

— जोशुआ

@ जोशुआ हाँ, लेकिन यह कार्यान्वयन परिभाषित व्यवहार है।

— फ़ूजएक्सएक्सएल

12

फोर्थ, 6 बाइट्स

golfed

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

— टसेपेल्लिन
स्रोत

10

45 बाइट जाओ

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

यह एक अनन्त लूप के साथ एक अनन्त लूप बनाता है जिसके अंदर। कार्यक्रम सामान्य रूप से चलना जारी रख सकता है, क्योंकि गोरोइन को शुरू करना एक तरह से समवर्ती रूप से चलने वाले छोटे धागे को पैदा करने की तरह है, लेकिन कार्यक्रम में उस मेमोरी को पुनः प्राप्त करने का कोई तरीका नहीं है जिसे गोरोइन के लिए आवंटित किया गया था। कचरा संग्रहकर्ता इसे कभी भी एकत्र नहीं करेगा क्योंकि यह अभी भी चल रहा है। कुछ लोग इसे 'एक गोरोचन लीक करना' कहते हैं

— चमकाओ
स्रोत

गोल्फ की जाँच: यह C.malloc(8)आपको कॉल करने की तुलना में 2 बाइट्स है , जब से आपको जरूरत हैimport"C"

— राईकिंग करें

9

जावा 1.3, 23 बाइट्स

void l(){new Thread();}

एक धागा बनाना लेकिन इसे शुरू नहीं करना। थ्रेड आंतरिक थ्रेड पूल में पंजीकृत है, लेकिन कभी भी शुरू नहीं किया जाएगा, इसलिए कभी भी समाप्त नहीं होगा और इसलिए कभी भी जीसी के लिए उम्मीदवार नहीं होगा। यह एक अपरिपक्व वस्तु है, जो जावा लिंबोस में अटक जाती है।

यह जावा में एक बग है जब तक 1.3 शामिल नहीं किया गया था क्योंकि यह बाद में तय किया गया था।

परिक्षण

निम्न प्रोग्राम नई थ्रेड ऑब्जेक्ट्स के साथ मेमोरी को प्रदूषित करने और घटती मुक्त मेमोरी स्पेस को दिखाने के लिए सुनिश्चित करता है। लीक परीक्षण के लिए, मैं गहन रूप से जीसी रन बनाता हूं।

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());
        }
    }
}

— ओलिवियर ग्रेजायर
स्रोत

चूंकि यह केवल विशिष्ट जावा संस्करणों पर काम करता है, इसलिए आपको इसके बजाय अपने हेडर में "जावा 3" कहना चाहिए।

5

जावा 3 जैसी कोई चीज नहीं है। यह जावा 1.3 है। जावा 1.0, 1.1, 2, 1.3, 1.4, 5, 6, 7, 8, 9. अजीब संख्या थी, लेकिन यह है कि यह कैसा है।

— ओलिवियर ग्रेगोइरे

मेरा भी यही विचार था। अरे नहीं।

— मैजिक ऑक्टोपस Urn

8

Befunge ( कवक ), 1 बाइट

यह मंच पर निर्भर और संस्करण पर निर्भर हो सकता है (मैंने केवल विंडोज पर संस्करण 1.0.4 के साथ परीक्षण किया है), लेकिन कवक ऐतिहासिक रूप से बहुत टपका हुआ दुभाषिया रहा है। $(ड्रॉप) आदेश एक खाली ढेर पर कुछ भी नहीं करना चाहिए, लेकिन इस कोड पर पाशन किसी भी तरह बहुत जल्दी स्मृति का एक बहुत लीक करने के लिए प्रबंधन करता है। कुछ ही सेकंड के भीतर इसने कुछ गिग्स का उपयोग किया होगा और "मेमोरी से बाहर" त्रुटि के साथ क्रैश होगा।

ध्यान दें कि यह जरूरी नहीं कि एक $कमांड हो - बस कुछ भी हो जाएगा। हालांकि यह एक रिक्त स्रोत फ़ाइल के साथ काम नहीं करेगा। कम से कम एक ऑपरेशन होना चाहिए।

— जेम्स होल्डरनेस
स्रोत

8

स्विफ्ट 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और इसके विपरीत एक मजबूत संदर्भ शामिल है । इस प्रकार, न तो निपटा जाएगा, एक स्मृति रिसाव के लिए अग्रणी।

— डैनियल
स्रोत

हम्म, आप अभी भी उस मेमोरी को संदर्भित कर सकते हैं xऔर yइसलिए, यह वास्तव में मेरे लिए लीक की तरह नहीं दिखता है (जब तक कि आप उन्हें किसी तरह नष्ट नहीं करते)।

— ज़ेपेलिन

@zeppelin अंतिम पंक्ति को ठीक करने के लिए एक फ़ंक्शन में लपेटा जा सकता है

— कोई नहीं

@ कोई नहीं, अगर मुझे एक doब्लॉक में आखिरी लाइन डालनी थी जो कि समस्या को ठीक करेगा जो जेपेलिन ने उठाया था?

— डैनियल

@ डोप्प्प हां; a doभी काम करेगा। अच्छा विचार!

— नवादा

इसे छोटा किया जा सकता है, आपको दो वर्गों की आवश्यकता नहीं है - X स्वयं को संदर्भ दे सकता है:class X{var x: X!};do{let x=X();x.x=x}

— सेबस्टियन ओसियोस्की

7

डेल्फी (ऑब्जेक्ट पास्कल) - 33 बाइट्स

वैरिएबल, फुल कंसोल प्रोग्राम के बिना ऑब्जेक्ट बनाना:

program;begin TObject.Create;end.

प्रोजेक्ट में FastMM4 को सक्षम करने से मेमोरी लीक होगी:

— आरडी
स्रोत

6

सी # - 84bytes

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

यह मानवरहित मेमोरी का ठीक 1 बाइट आवंटित करता है, और फिर खो देता है IntPtr, जो मेरा मानना है कि इसे प्राप्त करने या मुक्त करने का एकमात्र तरीका है। आप इसे लूप में भरकर इसका परीक्षण कर सकते हैं, और एप्लिकेशन के क्रैश होने की प्रतीक्षा कर सकते हैं (चीजों को गति देने के लिए कुछ शून्य जोड़ना चाह सकते हैं)।

मैंने माना System.IO.File.Create("a");और ऐसा है, लेकिन मुझे यकीन नहीं है कि ये जरूरी मेमोरी लीक हैं, क्योंकि एप्लिकेशन ही मेमोरी को इकट्ठा करेगा , यह ओएस है जो लीक हो सकता है (क्योंकि Closeया Disposeबुलाया नहीं गया था)। फ़ाइल एक्सेस सामान के लिए फ़ाइल सिस्टम अनुमतियों की भी आवश्यकता होती है, और कोई भी उन पर भरोसा नहीं करना चाहता है। और यह पता चला है कि यह वैसे भी लीक नहीं होगा, क्योंकि अंतिम रूप से बुलाया जा रहा कुछ भी नहीं रोक रहा है (जो कि अंतर्निहित संसाधनों को मुक्त करना संभव है), जिसमें रूपरेखा में निर्णय की त्रुटि के इन प्रकारों को कम करना शामिल है (कुछ हद तक), और प्रतीत होने वाले गैर-नियतात्मक फ़ाइल लॉकिंग के साथ प्रोग्रामर्स को भ्रमित करने के लिए (यदि आप एक सनकी हैं)। मुझे सीधे इस पर रखने के लिए जॉन हैना के लिए धन्यवाद।

मैं एक निराश हूँ कि मुझे इससे छोटा रास्ता नहीं मिल रहा है। .NET GC काम करता है, मैं IDisposablesmscorlib में किसी के बारे में नहीं सोच सकता जो निश्चित रूप से लीक होगा (और वास्तव में वे सभी फाइनल करने वाले हैं, कितना परेशान हैं) , मुझे अनवांटेड मेमोरी (PInvoke की कमी) को आवंटित करने के किसी भी अन्य तरीके के बारे में पता नहीं है ), और प्रतिबिंब (भाषा अर्थ विज्ञान की परवाह किए बिना (जैसे निजी सदस्यों या कोई accessors साथ वर्ग) यह करने के लिए एक संदर्भ के साथ कुछ भी सुनिश्चित करता है) कर सकते हैं पाया जा।

— VisualMelon
स्रोत

1

System.IO.File.Create("a")कुछ भी लीक नहीं होगा, लेकिन GC.SuppressFinalize(System.IO.File.Create("a"))जैसा कि स्पष्ट रूप से कहा जाता है कि FileStreamउत्पादित के फाइनल को नहीं चलाना चाहिए ।

— जॉन हैना

@JonHanna काफी सही। लगता है कि मेरी आईडी से डिस्पोजेबल व्यामोह मुझे बेहतर मिला है।

— विजुअलमेल

आपके पास System.Drawing.Bitmap का उपयोग करके GDI + रिसाव करने का मौका हो सकता है। नहीं जानता कि क्या यह मायने रखता है क्योंकि यह एक विंडोज़ लाइब्रेरी है जो लीक का कारण है, न कि कार्यक्रम।

— BgrWorker

@BgrWorker उन्हें कोई संदेह नहीं है कि उनके पास भी एक फाइनल है, और मैं कोड-गोल्फ में बाहरी पुस्तकालयों से बचने के लिए जाता हूं क्योंकि मैं उन्हें लागत पर सहमति से सहमत नहीं हूं: यदि आप एक ऐसा तरीका पा सकते हैं जिसमें आप आश्वस्त हैं, तो पोस्ट करने में संकोच न करें यह आपके अपने जवाब में है!

— विजुअलमेल

इस और अच्छे उत्तर के लिए धन्यवाद! (इट्स सी # तो आई लव

— इट

5

फैक्टर , 13 बाइट्स

फैक्टर में स्वचालित मेमोरी प्रबंधन होता है, लेकिन यह कुछ लिबास कार्यक्षमता को भी एक्सेस देता है:

1 malloc drop

स्मृति के 1 बाइट को मैन्युअल रूप से आवंटित करता है, इसका पता देता है, और इसे छोड़ देता है।

malloc वास्तव में मेमोरी लीक का ट्रैक रखने के लिए एक कॉपी रजिस्टर करता है adn double frees, लेकिन आपके द्वारा लीक की गई एक की पहचान करना आसान काम नहीं है।

यदि आप यह सुनिश्चित करना पसंद करते हैं कि आप वास्तव में उस संदर्भ को खो देते हैं:

1 (malloc) drop

परीक्षण लीक के साथ [ 1 malloc drop ] leaks.कहता है:

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

परीक्षण लीक के साथ [ 1 (malloc) drop ] leaks.कहता है:

| Disposable class | Instances | |

अरे नहीं! गरीब कारक, यह अब अल्जाइमर हो गया है! डी:

— फ़ेडर एस।
स्रोत

5

सामान्य लिस्प (केवल SBCL), 28 26 बाइट्स

sb-alien::(make-alien int)

तुम इसे ऐसे चलाते हो sbcl --eval 'sb-alien::(make-alien int)'; कुछ भी मुद्रित नहीं है और न ही वापस किया गया है, लेकिन मेमोरी आवंटन होता है। यदि मैं प्रपत्र को एक के अंदर लपेटता हूं (print ...), तो सूचक REPL में प्रदर्शित होता है।

package::(form)प्रपत्र को पढ़ते समय वर्तमान पैकेज को अस्थायी रूप से बाँधने के लिए SBCL में एक विशेष संकेतन है। इसका उपयोग यहाँ दोनों के साथ make-alienऔर उपसर्ग से बचने के लिए किया जाता है । मुझे लगता है कि वर्तमान पैकेज को यह मान लेना धोखा होगा, क्योंकि स्टार्टअप में ऐसा नहीं है।intsb-alien
make-alien किसी दिए गए प्रकार और एक वैकल्पिक आकार (मॉलॉक का उपयोग करके) के लिए मेमोरी आवंटित करता है।
आरईपीएल में इसे निष्पादित करते समय, 0आवंटन के बाद जोड़ें ताकि आरईपीएल सूचक को वापस न करे, लेकिन इसके बजाय मूल्य। अन्यथा, कि कोई एक असली रिसाव होगा क्योंकि आरईपीएल याद है पिछले तीन लौटे मूल्यों (देखें *, **,*** ) और हम अभी भी आबंटित स्मृति मुक्त करने का मौका हो सकता था।

2 बाइट्स PrzemysławP के लिए धन्यवाद हटा दिया, धन्यवाद!

— कोर निपात
स्रोत

1

क्या आप 1(या 2, 3आदि) का उपयोग नहीं कर सकते हैं ()ताकि आप मूल्य वापस कर सकें 1? इससे 1 बाइट बच जाती। यह भी जवाब केवल REPL है? हो सकता है कि यदि आप कोड को अपने साथ लोड करते loadहैं ()या अंत में कुछ भी शामिल नहीं कर सकते हैं , क्योंकि यह वैसे भी सुलभ नहीं होगा?

— PrzemysławP

1

@ PrzemysławP आप दोनों बिंदुओं पर सही हैं, मैंने आपके साथ evalकाम किया और जैसा आपने कहा था। आपका बहुत बहुत धन्यवाद!

— coredump

4

ऑटो इट , 39 बाइट्स

#include<Memory.au3>
_MemGlobalAlloc(1)

ढेर से एक बाइट आवंटित करता है। चूँकि संभाल द्वारा वापस ले लिया गया _MemGlobalAllocहै, उस आवंटन को स्पष्ट रूप से मुक्त करने का कोई तरीका नहीं है।

— mınxomaτ
स्रोत

3

सी ++, 16 बाइट्स

main(){new int;}

मेरे पास इसे लीक की जांच करने के लिए वैध नहीं है, लेकिन बहुत यकीन है कि यह होना चाहिए। नहीं तो मैं कोशिश करूंगा:

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

वल्ग्रिंड परिणाम

(यह वास्तव में लीक होता है)

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

— matovitch
स्रोत

@WheatWizard मैं g++ 4.3.2(सबसे हाल ही में नहीं) का उपयोग कर रहा हूं और यह बस ठीक संकलन करता है। कोई रिटर्न प्रकार intडिफ़ॉल्ट रूप से मुझे नहीं लगता है। साथ -Wallमैं एक चेतावनी है, हालांकि है:plop.cpp:1: warning: ISO C++ forbids declaration of 'main' with no type

— matovitch

2

@WheatWizard क्षमा करें, मैंने अभी देखा कि आपने प्रतियोगिता शुरू करने के लिए c ++ उदाहरण दिया। रेडिट से आते हुए मैंने केवल उत्तरों को देखा और (विचित्र रूप से) किसी भी C ++ को नहीं देखा। मैं थोड़ा गूंगा महसूस करता हूं। : /

— matovitch

आम सहमति यह है कि आप केवल []{new int;}C ++ फ़ंक्शन के रूप में गिन सकते हैं (चुनौती ने एक संपूर्ण कार्यक्रम निर्दिष्ट नहीं किया है)।

— टोबी स्पाईट

3

जावा (ओपनजेडके 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 का धन्यवाद

— Serverfrog
स्रोत

आप Unsafeइसके अंदर स्थैतिक चर से उदाहरण प्राप्त करके बाइट्स का एक गुच्छा बचा सकते हैं , जैसे:

import sun.misc.*;class M{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);}}

— zeppelin

और आप public static void mainस्थैतिक इनिशियलाइज़र द्वारा static{try{}catch(Exception e){}}(जो लॉन्च करने के लिए थोड़ा और अधिक मुश्किल हो सकता है लेकिन फिर भी वैध और संकलन योग्य है) द्वारा प्रतिस्थापित करके कुछ और बचत कर सकते हैं ।

— zeppelin

मेरे द्वारा उपयोग किए गए कोड के एंड्रॉइड संस्करण में कंस्ट्रक्टर का उपयोग किया गया था। मैं कुछ चीजों को बदल दूंगा जब im @home लेकिन मैं आपके द्वारा दिए गए पथ पर एक ही कथन के साथ

— जाऊंगा

व्हाट्सएप को हटा दें, aइसके स्थान पर उपयोग करें argsऔर सार्वजनिक हटा दें। tio.run/nexus/…

— पावेल

सच को 1> 0

— मास्टरएक्स 244

3

सी, 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)

— Elronnd
स्रोत

1

आप वास्तव में मेमोरी लीक नहीं कर रहे हैं; gccहै। यह भी खाली कार्यक्रम के साथ काम करना चाहिए। कोशिश करें gcc src.c && valgrind ./a.out, जो एक स्वच्छ परिणाम उत्पन्न करे।

3

सी #, 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। लेकिन कवर के तहत क्या होता है?

यदि हम XmlSerializerरिफ्लेक्टर के साथ निर्माणकर्ता पर एक नज़र डालते हैं, तो हम पाते हैं कि यह कॉल करता है this.tempAssembly = XmlSerializer.GenerateTempAssembly(this.mapping, type, defaultNamespace, location, evidence);जो एक अस्थायी (गतिशील) विधानसभा उत्पन्न करता है। इसलिए हर बार यह कोड चलता है (यानी हर बार पेज हिट होने पर) यह एक नई असेंबली उत्पन्न करेगा।

एक असेंबली उत्पन्न करने का कारण यह है कि इसे क्रमबद्ध और deserializing के लिए कार्य उत्पन्न करने की आवश्यकता है और इन्हें कहीं न कहीं निवास करने की आवश्यकता है।

ठीक है, ठीक है ... यह एक विधानसभा बनाता है, तो क्या? जब हम इसके साथ कर रहे हैं, तो यह सही गायब हो जाना चाहिए?

खैर ... एक विधानसभा जीसी हीप पर एक वस्तु नहीं है, जीसी असेंबलियों से वास्तव में अनजान है, इसलिए इसे कचरा एकत्र नहीं किया जाएगा। 1.0 और 1.1 में विधानसभाओं से छुटकारा पाने का एकमात्र तरीका ऐप डोमेन को अनलोड करना है जिसमें वह रहता है।

और इसमें समस्या डॉ। वाटसन की है।

विजुअल स्टूडियो 2015 में कंपाइलर से चलना और डायग्नोस्टिक टूल्स विंडो का उपयोग करना लगभग 38 सेकंड के बाद निम्न परिणाम दिखाता है। ध्यान दें कि प्रक्रिया मेमोरी तेजी से चढ़ रही है और कचरा कलेक्टर (जीसी) चलता रहता है लेकिन कुछ भी एकत्र नहीं कर सकता है।

— TheLethalCoder
स्रोत

2

सी 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

— हाबिल टॉम
स्रोत

2

क्या यह सिर्फ करना संभव है main(){malloc(1);} ?

— kirbyfan64sos

@हाँ यह है! लेकिन इसके पहले से ही पोस्ट किया गया है!

— एबेल टॉम

2

डार्ट, 76 बाइट्स

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

जावास्क्रिप्ट उत्तर की तरह थोड़ा सा। जब आप .listenडार्ट स्ट्रीम ऑब्जेक्ट पर कॉल करते हैं, तो आपको एक स्ट्रीमबस्क्रिप्शन वापस दिया जाता है, जो आपको स्ट्रीम से डिस्कनेक्ट करने की अनुमति देता है। हालांकि, यदि आप उसे दूर फेंक देते हैं, तो आप कभी भी स्ट्रीम से अनसब्सक्राइब नहीं कर सकते हैं, जिससे रिसाव हो सकता है। रिसाव को ठीक करने का एकमात्र तरीका यह है कि यदि स्ट्रीम स्वयं एकत्र हो जाए, लेकिन इसकी अभी भी एक StreamController + टाइमर कॉम्बो द्वारा आंतरिक रूप से संदर्भित है।

दुर्भाग्य से, डार्ट मेरे द्वारा की गई अन्य सामग्री के लिए बहुत स्मार्ट है। ()async=>await new Completer().futureकाम नहीं करता है क्योंकि प्रतीक्षा का उपयोग करने के समान है new Completer().future.then(<continuation>), जो बंद होने पर खुद को नष्ट करने की अनुमति देता है दूसरा कम्पलीटर संदर्भित नहीं है (कंप्लेंट फ्यूचर से .futureएक संदर्भ रखता है, फ्यूचर एक क्लोजर के रूप में निरंतरता का संदर्भ रखता है)।

इसके अलावा, आइसोलेट्स (उर्फ थ्रेड्स) को जीसी द्वारा साफ किया जाता है, इसलिए एक नए धागे में खुद को जगाएं और तुरंत इसे रोक दें ( import'dart:isolate';main(_)=>Isolate.spawn(main,0,paused:true);) काम नहीं करता है। यहां तक कि एक अनंत लूप ( import'dart:isolate';f(_){while(true){print('x');}}main()=>Isolate.spawn(f,0);) के साथ एक आइसोलेट को स्पॉलेट करने से प्रोग्राम को बाहर निकाल दिया जाता है।

ओह अच्छा।

— ड्वेन स्लेटर
स्रोत

यदि आपका मुख्य कार्यक्रम चल रहा है और अन्य सामान कर रहा है, तो क्या कचरा संग्रहकर्ता कभी भी अलगाव को रोकने में सक्षम होगा? मैं पूछता हूं क्योंकि मेरा गोरोइन उदाहरण एक जैसा लगता है ... मैंने मान लिया कि तथ्य यह है कि कार्यक्रम से बाहर निकलता है और ओएस को सभी मेमोरी वापस देता है जरूरी नहीं कि इसका मतलब यह नहीं है कि यह लीक नहीं हुआ है।

— उज्ज्वल

2

स्विफ्ट, 12 बाइट्स

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

स्पष्टीकरण:

यह एक डी-फैक्टो मेमोरी लीक है जो किसी भी भाषा में हो सकता है, भले ही भाषा मेमोरी मैनुअल मैनेजमेंट, स्वचालित संदर्भ गणना (एआरसी, स्विफ्ट की तरह) या यहां तक कि कचरा संग्रह का उपयोग करती हो।

[3,5]सिर्फ एक सरणी शाब्दिक है। यह सरणी कम से कम इन 2 तत्वों के लिए पर्याप्त मेमोरी आवंटित करती है। 3और 5सिर्फ मनमाने ढंग से कर रहे हैं।

अनुक्रमण (अनुक्रमण) एक Array<T>पैदा करता है aArraySlice<T> । एक ArraySlice<T>एरे की स्मृति में एक दृश्य है जिसे यह बनाया गया था।

[3,5][0...0]a का उत्पादन करता है ArraySlice<Int>, जिसका मूल्य है [3]। ध्यान दें कि 3इस स्लाइस में ऊपर दिखाए गए मूल के समान 3तत्व है, न कि एक प्रति।3Array

परिणामी टुकड़ा फिर एक चर में संग्रहित किया जा सकता है और इस्तेमाल किया जा सकता है। मूल सरणी अब संदर्भित नहीं है, इसलिए आपको लगता है कि इसे निपटाया जा सकता है। हालाँकि, यह नहीं हो सकता।

चूँकि टुकड़ा उस सरणी की स्मृति पर एक दृश्य को उजागर करता है जिससे यह आया था, मूल सरणी को तब तक जीवित रखा जाना चाहिए जब तक कि टुकड़ा रहता है। तो मूल का2 तत्व-आकार की स्मृति जो कि आवंटित की गई थी, केवल पहले तत्व-आकार की स्मृति का उपयोग किया जा रहा है, दूसरे के साथ मौजूद होने के लिए आवश्यक है ताकि पहले आवंटित न हो सके। स्मृति का दूसरा तत्व-आकार डी-फैक्टर लीक है।

इस समस्या का समाधान लंबे समय तक बड़ी सरणियों के छोटे स्लाइस को जीवित नहीं रखना है। यदि आपको स्लाइस सामग्री को बनाए रखने की आवश्यकता है, तो इसे एक ऐरे में बढ़ावा दें, जो मेमोरी को कॉपी करने के लिए ट्रिगर करेगा, इस प्रकार मूल सरणी की मेमोरी पर निर्भरता को हटा देगा:

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

— सिकंदर
स्रोत

2

समाधान 1: सी (मैक ओएस एक्स 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 सिस्टम कॉल से आवंटित मेमोरी के लिए नहीं देखता है, इसलिए मैं एक अच्छा पता लगाया गया रिसाव नहीं दिखा सकता।

हालाँकि हम आवंटित मेमोरी (MALLOC मेटाडेटा) के बड़े हिस्से को देखने के लिए vmmap पर देख सकते हैं।

                                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

व्याख्या

इसलिए मुझे लगता है कि मुझे बेहतर समाधान पर आगे बढ़ने से पहले यह बताने की जरूरत है कि वास्तव में यहां क्या हो रहा है।

यह मुख्य कार्य सी के लापता प्रकार की घोषणा को निरस्त कर रहा है (इसलिए यह हमारे बिना इसे लिखने के लिए बेकार करने के लिए चूक करता है), साथ ही प्रतीकों कैसे काम करते हैं। लिंकर केवल इस बात की परवाह करता है कि क्या वह mainकॉल करने के लिए बुलाया गया प्रतीक नहीं पा सकता है। इसलिए यहाँ हम मुख्य int की एक सरणी बना रहे हैं जिसे हम अपने शेलकोड के साथ आरंभ कर रहे हैं जिसे निष्पादित किया जाएगा। इस वजह से, मुख्य को __TEXT सेगमेंट में नहीं जोड़ा जाएगा, बल्कि __DATA सेगमेंट में, कारण हमें एक निष्पादन योग्य __DATA सेगमेंट के साथ प्रोग्राम को संकलित करने की आवश्यकता है।

मुख्य में पाया जाने वाला शेलकोड निम्नलिखित है:

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 को नए बनाए गए मेमोरी को पॉइंटर लिखने के लिए पता रखना चाहिए। (इसलिए हम इसे केवल स्टैक पर एक खंड की ओर इशारा कर रहे हैं), आरडीएक्स आवंटन का आकार रखता है (हम सिर्फ बाइट पर बचाने के लिए 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 बिट्स है और इस पर किसी का पूरक लागू किया गया है (इसलिए कोई अशक्त बाइट्स नहीं है; हम मूल प्राप्त करने के लिए सिर्फ मूल्य नहीं हैं), अगला मान; RDI (0x00007fff7d578244) जिसे 2 अतिरिक्त जंक बाइट्स के साथ बाईं ओर स्थानांतरित कर दिया गया है, अंत में जोड़ा गया है (फिर से नल बाइट्स को बाहर करने के लिए, हम इसे मूल में वापस लाने के लिए इसे वापस दाईं ओर शिफ्ट करते हैं)।

Syscall के बाद हम अपनी नई आवंटित मेमोरी को लिख रहे हैं। इसका कारण यह है क्योंकि mach_vm_allocate (या इस syscall) का उपयोग करके आवंटित की गई मेमोरी वास्तव में VM पृष्ठ हैं, और स्वचालित रूप से स्मृति में पृष्ठांकित नहीं हैं। बल्कि उन्हें तब तक आरक्षित रखा जाता है जब तक कि उन्हें डेटा नहीं लिखा जाता है, और फिर उन पृष्ठों को स्मृति में मैप किया जाता है। यकीन नहीं था कि यह आवश्यकताओं को पूरा करेगा अगर यह केवल आरक्षित था।

अगले समाधान के लिए हम इस तथ्य का लाभ उठाएंगे कि हमारे शेलकोड में कोई शून्य बाइट्स नहीं हैं, और इसलिए आकार को कम करने के लिए इसे हमारे प्रोग्राम के कोड के बाहर ले जा सकते हैं।

समाधान 2: सी (मैक ओएस एक्स 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 के रूप में एक ही अवधारणा का अनुसरण करता है, इस अपवाद के साथ कि हमने प्रोग्राम के बाहर हमारे लीक कोड का हिस्सा बदल दिया है।

मुख्य में पाया गया शेलकोड अब निम्नलिखित है:

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: सी (मैक ओएस एक्स x86_64), 11 बाइट्स

कार्यक्रम को बाहरी रूप से संशोधित करने का विचार, हमें बाहरी प्रोग्राम में लीकर को स्थानांतरित करने का संभव समाधान देता है। जहां हमारा वास्तविक कार्यक्रम (सबमिशन) सिर्फ एक डमी प्रोग्राम है, और लीकर प्रोग्राम हमारे लक्ष्य कार्यक्रम में कुछ मेमोरी आवंटित करेगा। अब मैं निश्चित नहीं था कि अगर यह इस चुनौती के नियमों के दायरे में आता, लेकिन फिर भी इसे साझा करना।

इसलिए यदि हम अपने चुनौती कार्यक्रम के लिए निर्धारित लक्ष्य के साथ बाहरी कार्यक्रम में mach_vm_allocate का उपयोग करते हैं, तो इसका मतलब यह हो सकता है कि हमारे चुनौती कार्यक्रम को केवल कुछ की आवश्यकता होगी:

main=65259;

जहां वह शेलकोड केवल स्वयं के लिए एक छोटी छलांग (अनंत कूद / पाश) है, इसलिए कार्यक्रम खुला रहता है और हम इसे बाहरी कार्यक्रम से संदर्भित कर सकते हैं।

संभव समाधान 2: सी (मैक ओएस एक्स x86_64), 8 बाइट्स

मजेदार रूप से पर्याप्त है जब मैं वाल्ग्रिंड आउटपुट को देख रहा था, मैंने देखा कि कम से कम वैलेग्रिंड के अनुसार, डाईल्ड लीक मेमोरी है। इसलिए प्रभावी रूप से हर कार्यक्रम कुछ स्मृति को लीक कर रहा है। यह मामला होने के साथ, हम वास्तव में केवल एक कार्यक्रम बना सकते हैं जो कुछ भी नहीं करता है (बस बाहर निकलता है), और वह वास्तव में मेमोरी को लीक करेगा।

स्रोत:

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

— ScrimpyCat
स्रोत

2

सादा अंग्रेजी , 71 70 58 35 बाइट्स

रिक्त पंक्ति हटाकर 1 बाइट हटा दी गई। "बोगन" प्रकार की परिभाषा को समाप्त करके, और "बोगन" उपप्रकार के बजाय माता-पिता "चीज़" प्रकार का उपयोग करके 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" कहे जाने वाले समय की संख्या के अनुपात में मेमोरी को लीक कर देगा। गोल्फ वाले संस्करण में, "बात को निपटाएं।" मेमोरी लीक को ठीक करेगा।

डिफ़ॉल्ट रूप से मेमोरी लीक के लिए सादे अंग्रेजी की जांच। जब स्मृति को लीक करने वाला संस्करण चलाया जाता है, तो प्रोग्राम बंद होने से ठीक पहले एक संवाद बॉक्स दिखाई देगा। संवाद बॉक्स में "डीबग", "1 ड्रिप" का संदेश और "ओके" बटन का शीर्षक है। अधिक बार लीक करने वाले फ़ंक्शन को कहा जाता है, संदेश में "ड्रिप" की संख्या जितनी बड़ी होगी। जब संस्करण जो मेमोरी को लीक नहीं करता है वह चलाया जाता है, तो संवाद बॉक्स प्रकट नहीं होता है।

प्लेन इंग्लिश में, एक "चीज" एक डबल-लिंक्ड सूची में एक आइटम के लिए एक संकेतक है। "थिंग", "स्टार्ट अप", और "शट डाउन" को "नूडल" नामक मॉड्यूल में परिभाषित किया गया है, जिसे प्रत्येक प्रोजेक्ट में (आमतौर पर एक अलग फ़ाइल के रूप में) कॉपी करने की आवश्यकता होती है। "ए", "ए", "टू", "मेमोरी आवंटित करने के लिए", और "नष्ट करने के लिए" संकलक में परिभाषित किए गए हैं।

— सूर्यकांत मणि
स्रोत

संभव के रूप में कुछ बाइट्स में रिसाव मेमोरी

पर्ल (5.22.2), 0 बाइट्स

सत्यापन

सी, 48 31 22 बाइट्स

अनलम्बदा ( c-refcnt/unlambda), 1 बाइट

सत्यापन

टीआई-बेसिक, 12 बाइट्स

पायथन <3.6.5, 23 बाइट्स

सी #, 34 बाइट्स

व्याख्या

परीक्षा

सी (जीसीसी) , 15 बाइट्स

सत्यापन

जावास्क्रिप्ट, 14 बाइट्स

जावा, 10 बाइट्स

जंग, 52 बाइट्स

जंग (सिद्धांत में), 38 बाइट्स

8086 एएसएम, 3 बाइट्स

फोर्थ, 6 बाइट्स

45 बाइट जाओ

जावा 1.3, 23 बाइट्स

परिक्षण

Befunge ( कवक ), 1 बाइट

स्विफ्ट 3, 38 बाइट्स

डेल्फी (ऑब्जेक्ट पास्कल) - 33 बाइट्स

सी # - 84bytes

फैक्टर , 13 बाइट्स

सामान्य लिस्प (केवल SBCL), 28 26 बाइट्स

ऑटो इट , 39 बाइट्स

सी ++, 16 बाइट्स

वल्ग्रिंड परिणाम

जावा (ओपनजेडके 9) , 322 220 बाइट्स

सी, 9 बाइट्स

सी #, 109 बाइट्स

सी 30 बाइट्स

मान्य परिणाम:

डार्ट, 76 बाइट्स

स्विफ्ट, 12 बाइट्स

स्पष्टीकरण:

समाधान 1: सी (मैक ओएस एक्स x86_64), 109 बाइट्स

परिणाम:

व्याख्या

समाधान 2: सी (मैक ओएस एक्स x86_64), 44 बाइट्स

व्याख्या

संभव समाधान 1: सी (मैक ओएस एक्स x86_64), 11 बाइट्स

संभव समाधान 2: सी (मैक ओएस एक्स x86_64), 8 बाइट्स

सादा अंग्रेजी , 71 70 58 35 बाइट्स

अनलम्बदा ( `c-refcnt/unlambda`), 1 बाइट