মেমরি ফাঁস কি কখনও ঠিক আছে? [বন্ধ]


231

আপনার সি বা সি ++ অ্যাপ্লিকেশনটিতে মেমরি ফাঁস হওয়া কি কখনও গ্রহণযোগ্য ?

আপনি যদি কিছু মেমরি বরাদ্দ করেন এবং আপনার অ্যাপ্লিকেশনটিতে কোডের শেষ লাইন পর্যন্ত এটি ব্যবহার করেন (উদাহরণস্বরূপ, একটি গ্লোবাল অবজেক্টের ডেস্ট্রাক্টর)? যতক্ষণ সময়ের সাথে মেমরির খরচ বাড়বে না, আপনার অ্যাপ্লিকেশনটি বন্ধ হয়ে গেলে (উইন্ডোজ, ম্যাক এবং লিনাক্সে) আপনার জন্য আপনার মেমরিটি মুক্ত করতে ওএসকে বিশ্বাস করা ঠিক হবে? এমনকি যদি ওএস দ্বারা মুক্ত না করা পর্যন্ত মেমরিটি ধারাবাহিকভাবে ব্যবহৃত হয়ে থাকে তবে আপনি কি এটি একটি আসল মেমরি ফাঁস বিবেচনা করবেন?

যদি কোনও তৃতীয় পক্ষের গ্রন্থাগার আপনার উপর এই পরিস্থিতি জোর করে? তৃতীয় পক্ষের লাইব্রেরিটি এটি ব্যবহার করতে অস্বীকার করবে তা অন্যথায় যতই দুর্দান্ত হোক না কেন?

আমি কেবল একটি ব্যবহারিক অসুবিধা দেখতে পাচ্ছি এবং তা হ'ল এই সৌম্য লিকগুলি মেমরি ফাঁস সনাক্তকরণ সরঞ্জামগুলি মিথ্যা ধনাত্মক হিসাবে প্রদর্শিত হবে।


50
যদি সময়ের সাথে স্মৃতিশক্তি গ্রাহ্য না হয় তবে এটি ফুটো নয়।
এমপিজেড

4
বেশিরভাগ অ্যাপ্লিকেশনগুলিতে (সমস্ত। নেট প্রোগ্রামগুলি সহ) কমপক্ষে কয়েকটি বাফার থাকে যা একবার বরাদ্দ করা হয় এবং কখনই স্পষ্টভাবে মুক্তি পায় না so
বেন ভয়েগট

2
হ্যাঁ, যদি আপনার অসীম স্মৃতি থাকে।
ব্যবহারকারী

একটি "সৌম্য" ফুটো (যদি এমন কোনও জিনিস থাকে) কোনও মিথ্যা ইতিবাচক নয় - এটি একটি ফাঁস যা খুব সঠিকভাবে সনাক্ত করা হয়েছিল। ফাঁস সনাক্তকরণ, এমনকি লিকের জন্য এমনকি আপনি ব্যক্তিগতভাবে ফিক্সিংয়ের মতো মনে করেন না, এটি একটি লিক ডিটেক্টর এর বিদ্যমান কারণ।
সিএওও

1
@ এমপিজ ০ "সময়ের সাথে সাথে যদি স্মৃতিশক্তি গ্রাহ্য না হয় তবে এটি ফাঁস হয় না"? এটি কোনও স্মৃতি ফাঁসের সংজ্ঞা নয়। একটি ফুটো হ'ল মেমরি যা ফাঁস হয়েছিল, যার অর্থ এটি মুক্ত হয় নি এবং এর সাথে আপনার আর কোনও রেফারেন্স নেই, সুতরাং এটি আর কখনও মুক্তি দেওয়া আপনার পক্ষে অসম্ভব। এটি বৃদ্ধি পায় বা না তা অপ্রাসঙ্গিক।
মেকি

উত্তর:


329

না।

পেশাদার হিসাবে, যে প্রশ্নটি আমাদের নিজেদের জিজ্ঞাসা করা উচিত নয় তা হ'ল "এটি করা কি কখনও ঠিক হয়?" তবে বরং "এটি করার কোনও ভাল কারণ আছে কি?" এবং "সেই স্মৃতি ফাঁস হওয়া একটি ব্যথা হ'ল শিকার করা কোনও ভাল কারণ নয়।

আমি জিনিসগুলি সহজ রাখতে পছন্দ করি। এবং সহজ নিয়মটি হল আমার প্রোগ্রামটির কোনও মেমরি ফাঁস হওয়া উচিত নয়।

এটি আমার জীবনকেও সহজ করে তোলে। যদি আমি কোনও স্মৃতি ফাঁস সনাক্ত করি, তবে এটি "গ্রহণযোগ্য" মেমরি ফাঁস কিনা তা নির্ধারণ করার জন্য কিছু বিস্তৃত সিদ্ধান্ত গাছ কাঠামোর মধ্য দিয়ে চালানোর পরিবর্তে আমি এটিকে দূর করি।

এটি সংকলক সতর্কতাগুলির অনুরূপ - সতর্কতাটি কি আমার বিশেষ প্রয়োগের জন্য মারাত্মক হবে? হয়তো না.

তবে শেষ পর্যন্ত এটি পেশাদার অনুশাসনের বিষয়। সংকলক সতর্কতা সহ্য করা এবং মেমরি ফুটো সহ্য করা একটি খারাপ অভ্যাস যা শেষ পর্যন্ত আমাকে পিছনে দংশন করবে।

কোনও বিষয়কে চূড়ান্ত দিকে নিয়ে যাওয়ার জন্য, কোনও শল্যচিকিৎসকের পক্ষে কোনও রোগীর ভিতরে অপারেটিং সরঞ্জামের কিছু অংশ রেখে দেওয়া কি কখনও গ্রহণযোগ্য হবে?

যদিও এটি সম্ভব যে পরিস্থিতি তৈরি হতে পারে যেখানে সেই সরঞ্জামের টুকরো অপসারণের ব্যয় / ঝুঁকিটি এটি ছেড়ে দেওয়ার ব্যয় / ঝুঁকির চেয়ে বেশি হয়ে যায় এবং এমন পরিস্থিতিও হতে পারে যেখানে এটি নিরীহ ছিল, যদি আমি এই প্রশ্নটি সার্জনওভারফ্লো ডটকমকে পোস্ট করে দেখি এবং "না" ব্যতীত অন্য কোনও উত্তর দেখেছি এটি চিকিত্সা পেশায় আমার আত্মবিশ্বাসকে মারাত্মকভাবে ক্ষুণ্ন করবে।

-

যদি কোনও তৃতীয় পক্ষের লাইব্রেরি আমার উপর এই পরিস্থিতি জোর করে, তবে এটি আমাকে গ্রন্থাগারের সামগ্রিক গুণকে সন্দেহজনকভাবে সন্দেহের দিকে নিয়ে যেতে বাধ্য করবে। এটি এমন হবে যেন আমি পরীক্ষা করে গাড়ী চালিয়েছি এবং কাপলোল্ডারগুলির মধ্যে একটিতে দু'জন looseিলে .ালা ওয়াশার এবং বাদাম পেয়েছি - এটি নিজের মধ্যে বড় কথা নাও হতে পারে, তবে এটি মানের প্রতি প্রতিশ্রুতির অভাবকে চিত্রিত করেছে, তাই আমি বিকল্পগুলি বিবেচনা করব।


57
সত্য এবং একই সময়ে সত্য নয়। চূড়ান্তভাবে আমাদের বেশিরভাগ মজুরি দাস এবং কারুশিল্পের জন্য যে কোনও আকাঙ্ক্ষা অবশ্যই ব্যবসায়ের প্রয়োজনীয়তার পিছনে আসন গ্রহণ করতে পারে। যদি 3 য় পক্ষের গ্রন্থাগারটিতে একটি ফুটো থাকে এবং 2 সপ্তাহের কাজ বাঁচায় তবে এটি ব্যবহার করার জন্য কোনও ব্যবসায়ের ক্ষেত্রেও থাকতে পারে ... ইত্যাদি
সার্ভো

3
আমি যাহাই হউক না কেন লাইব্রেরিটি ব্যবহার করিব, যদি এটি আমার প্রয়োজন হয় এবং কোনও শালীন বিকল্প না থাকত তবে আমি রক্ষণাবেক্ষণকারীদের সাথে একটি বাগ লগ করব।
tloach

7
আমি ব্যক্তিগতভাবে ঠিক একই উত্তরটি সহ যাব, এমন কিছু প্রোগ্রাম রয়েছে যা মেমরির পক্ষে মোটেও মুক্ত নয়। কারণটি হ'ল তারা হ'ল) ​​ক) নিখরচায় স্মৃতি মুক্ত ওএসে চালিত করার উদ্দেশ্যে, এবং খ) খুব বেশি সময় না চালানোর জন্য ডিজাইন করা। সত্যিই কোনও প্রোগ্রামের জন্য বিরল বাধা, তবে আমি একে পুরোপুরি বৈধ হিসাবে গ্রহণ করি।

2
প্রাথমিক পরীক্ষা করার জন্য কয়েকটি কারণ যুক্ত করার জন্য: যখন আপনার ডিবাগিং সরঞ্জামগুলি "সৌম্য" ফুটো হয়ে যায়, আপনি কীভাবে "আসল" সন্ধান করবেন? আপনি যদি কোনও ব্যাচের বৈশিষ্ট্য যুক্ত করেন, এবং হঠাৎ আপনার 1K / ঘন্টা লিকটি 1K / সেকেন্ডে পরিণত হয়?
পিটারচেন

5
হুম কি "মেমরি ফাঁস হচ্ছে না" "পারফেক্ট"?
জনএমসিজি

80

"ব্যবহার করা" থাকার পরিমাণ বাড়তে না থাকলে আমি এটিকে মেমরি ফাঁস হিসাবে বিবেচনা করি না। কিছু অপ্রকাশিত মেমরি থাকা, আদর্শ না হলেও, কোনও বড় সমস্যা নয় যতক্ষণ না প্রয়োজনীয় মেমরির পরিমাণ বাড়তে থাকে।


12
প্রযুক্তিগতভাবে, একটি ফুটো হ'ল মেমরি যা বরাদ্দ করা হয় এবং এর সমস্ত উল্লেখ হারিয়ে যায়। শেষে স্মৃতিটিকে অবনতি না করা কেবল অলস।
মার্টিন ইয়র্ক

17
আপনার যদি 4 গিগাবাইটের 1-সময়ের মেমরি লিক হয়, তবে এটি একটি সমস্যা।
জন ডিবলিং

21
এটি বাড়ছে কি না তাতে কিছু আসে যায় না। অন্যান্য প্রোগ্রাম মেমরিটি বরাদ্দ থাকলে ব্যবহার করতে পারে না।
টিকটিকিটি

8
> অন্যান্য প্রোগ্রাম মেমরিটি বরাদ্দ থাকলে ব্যবহার করতে পারে না। ঠিক আছে, ওএস সর্বদা আপনার স্মৃতিটিকে ডিস্কে অদলবদল করতে পারে এবং অন্যান্য অ্যাপ্লিকেশনগুলিকে আপনি যে র্যামটি ব্যবহার করছেন না সেটিকে ব্যবহার করার অনুমতি দেয়।
ম্যাক্স ল্যাবার্ট

4
প্রোগ্রামটি যদি খুব স্বল্পস্থায়ী হয় তবে একটি ফুটো এতটা খারাপ নাও হতে পারে। এছাড়াও, আদর্শ না হলেও, পেজিংগুলি এতটা ব্যয়বহুল নয় যেহেতু এখানে কিছু এটি তৈরি করে দেয়, কারণ প্রোগ্রামটি সেই স্মৃতিতে আগ্রহী নয় (এবং এইভাবে এটি সর্বদা সজ্জিত হবে না) - যদি না হয় অবশ্যই আপনার একটি জিসি ...
আরাফাঙ্গিয়ান

79

প্রথমে আমাদের সংজ্ঞাগুলি সঠিকভাবে নেওয়া যাক। একটি মেমরি ফাঁস হয় যখন মেমরিটি গতিশীলভাবে বরাদ্দ করা হয়, যেমন, সহ malloc()এবং মেমরির সমস্ত রেফারেন্সগুলি সম্পর্কিত বিনামূল্যে ছাড়াই হারিয়ে যায় are এটিকে তৈরি করার একটি সহজ উপায়:

#define BLK ((size_t)1024)
while(1){
    void * vp = malloc(BLK);
}

নোট করুন যে প্রতিবার (1) লুপের চারপাশে 1024 (+ ওভারহেড) বাইট বরাদ্দ করা হয়েছে, এবং নতুন ঠিকানাটি ভিপিতে নির্ধারিত হয়েছে; আগের ম্যালোকড ব্লকগুলিতে কোনও পয়েন্টার নেই। এই প্রোগ্রামটি গাদা হয়ে গেছে যতক্ষণ না গাদা শেষ হয়ে যায় এবং ম্যালোকের কোনও স্মৃতি পুনরুদ্ধার করার উপায় নেই। স্মৃতি গাদা থেকে "ফাঁস" হচ্ছে, আর কখনও দেখা যাবে না।

আপনি কী বর্ণনা করছেন, যদিও তা দুর্দান্ত

int main(){
    void * vp = malloc(LOTS);
    // Go do something useful
    return 0;
}

আপনি মেমরি বরাদ্দ করেন, প্রোগ্রামটি শেষ না হওয়া পর্যন্ত এটির সাথে কাজ করুন। এই না একটি মেমরি লিক; এটি প্রোগ্রামকে ক্ষতিগ্রস্থ করে না, এবং প্রোগ্রামটি শেষ হয়ে গেলে সমস্ত মেমরি স্বয়ংক্রিয়ভাবে আপ্লুত হবে।

সাধারণত, আপনার মেমরি ফুটো এড়ানো উচিত। প্রথমত, কারণ আপনার উপরে উচ্চতা এবং হ্যাঙ্গারে ফিরে জ্বালানীর মতো, মেমরি যা ফাঁস হয়েছে এবং পুনরুদ্ধার করা যায় না তা অকেজো; দ্বিতীয়ত, মেমরি ফাঁস না করে সঠিকভাবে কোড করা অনেক সহজ, পরে মেমরি ফাঁস হওয়ার চেয়ে এটি খুঁজে পাওয়া।


এখন এই বরাদ্দের কয়েক ডজন বিবেচনা করুন। এখন "প্রধান" বডিটিকে রুটিনে স্থানান্তরিত করার বিষয়ে বিবেচনা করুন যা একাধিকবার ডাকা হয়। উপভোগ করুন। - আমি এই সংবেদনের সাথে একমত যে এটি এই পরিস্থিতিতে এত বড় সমস্যা নয়, তবে পরিস্থিতি পরিবর্তিত হয়। তারা যেমন বলে, সর্বদা কোড লিখুন যেন এটি বজায় রাখার জন্য লোকটি জানেন যে আপনি কোথায় থাকেন।
পিটারচেন

2
ঠিক আছে, মুল বক্তব্যটি হল যে মেমোরিটি malloc'ed এবং অনুষ্ঠান _exit () কল না করা পর্যন্ত অনুষ্ঠিত হয় "ফাঁস" হয় না।
চার্লি মার্টিন

1
এটি একটি মেমরি ফুটো এবং এটি আপনার প্রোগ্রামকে ক্ষতিগ্রস্থ করতে পারে। ভবিষ্যতের বরাদ্দগুলি এই প্রক্রিয়া থেকে ব্যর্থ হতে পারে কারণ আমি নিশ্চিত যে আপনি যে ম্যালোক সর্বত্র ফিরে এসেছেন তা পরীক্ষা করে নিচ্ছেন। স্মৃতি ব্যবহারের মাধ্যমে যেমন এম্বেড থাকা অবস্থায় স্মৃতিচিহ্নের অভাব হয় তা জীবন এবং মৃত্যুর মধ্যে পার্থক্য হতে পারে।
মাইকেজে

10
মাইক, এটা ঠিক সত্য নয়। একটি আনুগত্যকারী সি পরিবেশে, প্রধান সমাপ্তি সমস্ত প্রক্রিয়া সংস্থানকে মুক্ত করে। আপনার বর্ণনার মতো এম্বেড থাকা পরিবেশে আপনি সেই পরিস্থিতিটি দেখতে পাবেন, তবে আপনার কোনও প্রধান থাকবে না। এখন, আমি মঞ্জুর করব যে এখানে ত্রুটিযুক্ত এমবেডেড পরিবেশ থাকতে পারে যার জন্য এটি সত্য হবে না তবে এর পরে আমি ত্রুটিযুক্ত পরিবেশ দেখেছি যা + = সঠিকভাবে মোকাবেলা করতে পারে না।
চার্লি মার্টিন

3
হ্যাঁ, আপনি এখন আবিষ্কার করেছেন যে আপনার mallocখুব বেশি স্মৃতি থাকলে এটি একটি খারাপ জিনিস। এটি এখনও ফুটো হয়নি । রেফারেন্সটি হারিয়ে গেছে এমন না হওয়া পর্যন্ত এটি ফুটো হয় না malloc
চার্লি মার্টিন

39

তত্ত্ব নং, বাস্তবে এটি নির্ভর করে

এটি প্রোগ্রামটি কতটা ডেটা নিয়ে কাজ করছে, প্রোগ্রামটি কতবার চালিত হয় এবং এটি অবিচ্ছিন্নভাবে চালিত হয় কি না তা নির্ভর করে depends

যদি আমার কাছে একটি দ্রুত প্রোগ্রাম থাকে যা অল্প পরিমাণে ডেটা পড়ে একটি গণনা করে এবং প্রস্থান করে তবে একটি ছোট মেমরি ফাঁস কখনই লক্ষ্য করা যাবে না। যেহেতু প্রোগ্রামটি খুব দীর্ঘ সময়ের জন্য চলছে না এবং কেবলমাত্র অল্প পরিমাণ মেমরি ব্যবহার করে, প্রোগ্রামটি উপস্থিত থাকলে লিকটি ছোট এবং মুক্ত হবে।

অন্যদিকে আমার কাছে যদি এমন একটি প্রোগ্রাম থাকে যা কয়েক মিলিয়ন রেকর্ড প্রক্রিয়া করে এবং দীর্ঘ সময় ধরে চলে, একটি ছোট মেমরি ফাঁস মেশিনকে যথেষ্ট সময় দিতে পারে।

তৃতীয় পক্ষের লাইব্রেরিগুলিতে যেমন ফাঁস রয়েছে, যদি তাদের কোনও সমস্যা হয় তবে তা হয় লাইব্রেরিটি ঠিক করুন বা আরও ভাল বিকল্পের সন্ধান করুন। এটি যদি কোনও সমস্যার কারণ না হয় তবে তা কি সত্যই গুরুত্ব দেয়?


আপনি আমার পুরো প্রশ্নটি পড়বেন কিনা তা আমি জানি না। আমি বলছি যে অ্যাপ্লিকেশনটির একেবারে শেষ পর্যন্ত স্মৃতি ব্যবহৃত হয় used এটি সময়ের সাথে বৃদ্ধি পায় না। কেবলমাত্র কোনওটি হ'ল মুক্ত / মোছার জন্য কোনও কল নেই।
Imbue

2
তাহলে এটি আসলে কোনও স্মৃতি ফাঁস নয়। একটি মেমরি ফুটো অল্প পরিমাণে অব্যবহৃত তবে অপরিবর্তিত স্মৃতি থাকে, সময়ের সাথে সাথে এই পরিমাণ আরও বেশি হয়। আপনি যে বিষয়ে কথা বলছেন তা হ'ল একটি স্মৃতি বিন্দু। আপনার ফোঁটা খুব বড় না হলে এ নিয়ে নিজেকে উদ্বিগ্ন করবেন না।
vfilby

"যদি এটি সমস্যার কারণ না ঘটে তবে আসলেই কি কিছু আসে যায়?" নাহ, এটা মোটেই কিছু যায় আসে না। আমি আশা করি ধর্মীয় হওয়ার পরিবর্তে আরও লোকেরা তা পেয়েছিল।
Imbue

2
@ জন: এটি সাধারণত অলস বিকাশকারীদের প্রশ্ন কম এবং আরও উন্নত সফ্টওয়্যার সম্পর্কিত প্রশ্ন। আমরা সবাই ভুল করি, বাগগুলি আমাদের বাণিজ্য; আমরা তাদের তৈরি করি আমরা তাদের ঠিক করেছি, আমরা এটিই করি। এটি সর্বদা আপফ্রন্ট ব্যয় এবং দীর্ঘমেয়াদী রক্ষণাবেক্ষণের মধ্যে একটি ভারসাম্য থাকে that এই ভারসাম্যটি কখনও সোজা হয় না।
vfilby

1
জন, আমি আপনার সাথে 100% একমত .. Imbum প্রশ্নটি প্রায়, "আপনি কতটা গ্রহণ করবেন"। ঝিম ঝিমঝিম .. আমি তোমার মনিটরের পিছনে একটি চিংড়ি রেখে যাব কীভাবে। দুর্গন্ধ দুর্গন্ধ হয়। প্রতিবার যখন আমরা গুহা, আমাদের শিল্প কিছুটা গুহা। যদি আপনি জানেন যে একটি ফুটো আছে এবং আপনি যদি জানেন যে আপনি এটির কারণ হয়েছিলেন তবে আপনার এটি ঠিক করা উচিত।
baash05

37

অনেক লোক মনে হয় যে আপনি একবার মেমরি মুক্ত করার পরে এটি তাত্ক্ষণিকভাবে অপারেটিং সিস্টেমে ফিরে আসে এবং অন্যান্য প্রোগ্রামগুলি ব্যবহার করতে পারে।

এটা সত্য নয়। অপারেটিং সিস্টেমগুলি সাধারণত 4KiB পৃষ্ঠায় মেমরি পরিচালনা করে। mallocএবং অন্যান্য ধরণের মেমরির পরিচালনাগুলি ওএস থেকে পৃষ্ঠাগুলি পান এবং উপযুক্ত দেখায় সেগুলি উপ-পরিচালনা করে। সম্ভবত এটি সম্ভবত আপনার প্রোগ্রামটি আরও স্মৃতি মেমোল করে দেবে এই ধারণার অধীনে অপারেটিং সিস্টেমে পৃষ্ঠাগুলি ফিরিয়ে free()দেবে না

আমি বলছি না যে free()অপারেটিং সিস্টেমে কখনই মেমরি ফিরে আসে না। এটি ঘটতে পারে, বিশেষত যদি আপনি মেমরির প্রসারকে মুক্ত করে থাকেন। তবে এর কোনও গ্যারান্টি নেই।

গুরুত্বপূর্ণ বিষয়: আপনি যদি আর মেমরির প্রয়োজন নেই যা আপনার আর প্রয়োজন নেই, আরও ম্যালোকগুলি আরও বেশি মেমরি গ্রাস করার গ্যারান্টিযুক্ত । তবে আপনি যদি প্রথমে মুক্ত হন তবে malloc এর পরিবর্তে মুক্ত মেমরিটি পুনরায় ব্যবহার করতে পারে।

অনুশীলনে এর অর্থ কী? এর অর্থ হ'ল যদি আপনি জানেন যে এখন থেকে আপনার প্রোগ্রামটির আর কোনও মেমরির প্রয়োজন নেই (উদাহরণস্বরূপ এটি ক্লিনআপ ধাপে রয়েছে), মেমরি মুক্ত করা এত গুরুত্বপূর্ণ নয়। তবে যদি প্রোগ্রামটি পরে আরও মেমরি বরাদ্দ করতে পারে তবে আপনার মেমরি ফাঁসগুলি এড়ানো উচিত - বিশেষত যা বারবার ঘটতে পারে।

আরো দেখুন এই মন্তব্যটি কেন মেমরি freeing ঠিক আগে পরিসমাপ্তি খারাপ সম্পর্কে আরো বিস্তারিত জানার জন্য।

একজন মন্তব্যকারী বুঝতে পারে নি যে কলিং free()অন্য প্রোগ্রামগুলিকে মুক্ত মেমরিটি স্বয়ংক্রিয়ভাবে মঞ্জুরি দেয় না। কিন্তু এই উত্তর পুরো পয়েন্ট!

সুতরাং, লোকদের বোঝাতে, আমি একটি উদাহরণ প্রদর্শন করব যেখানে ফ্রি () খুব কম ভাল কাজ করে। গণিতটি অনুসরণ করা সহজ করার জন্য, আমি ভান করব যে ওএস 4000 বাইট পৃষ্ঠায় মেমরি পরিচালনা করে।

ধরা যাক আপনি দশ হাজার 100-বাইট ব্লক বরাদ্দ করেছেন (সরলতার জন্য আমি এই বরাদ্দগুলি পরিচালনা করার জন্য অতিরিক্ত মেমোরি উপেক্ষা করব)। এটি 1MB বা 250 পৃষ্ঠাগুলি ব্যয় করে। এরপরে আপনি যদি এগুলির মধ্যে 9000 টি এলোমেলোভাবে মুক্ত করেন তবে আপনার কেবল 1000 টি ব্লক রয়েছে - তবে সেগুলি পুরো জায়গায় ছড়িয়ে ছিটিয়ে রয়েছে। পরিসংখ্যানগতভাবে, পৃষ্ঠাগুলির প্রায় 5 টি খালি থাকবে। অন্যান্য 245 প্রত্যেকের মধ্যে কমপক্ষে একটি বরাদ্দ ব্লক থাকবে। এটি 980KB মেমরির পরিমাণ, এটি সম্ভবত অপারেটিং সিস্টেম দ্বারা পুনরুদ্ধার করা যায় না - যদিও এখন আপনার কাছে কেবল 100KB বরাদ্দ রয়েছে!

অন্যদিকে, আপনি এখন ম্যালোক করতে পারেন (9000) আরও বেশি ব্লক না করে আপনার প্রোগ্রামটি মেমরিটি বেঁধে রাখছে।

এমনকি যখন free()পারে টেকনিক্যালি ওএস মেমরি আসতে, তাই না নাও করতে পারে। free()দ্রুত অপারেটিং এবং মেমরি সংরক্ষণের মধ্যে ভারসাম্য অর্জন করতে হবে। এবং তদ্ব্যতীত, এমন একটি প্রোগ্রাম যা ইতিমধ্যে প্রচুর মেমরি বরাদ্দ করেছে এবং তারপরে মুক্তি পেয়েছে এটি আবার এটি করার সম্ভাবনা রয়েছে। একটি ওয়েব সার্ভারের অনুরোধের পরে অনুরোধের পরে অনুরোধটি হ্যান্ডেল করা দরকার - কিছু "স্ল্যাক" মেমরিটি উপলব্ধ রাখা বুদ্ধিমান হয়ে যায় যাতে আপনাকে সর্বদা মেমরির জন্য ওএসকে জিজ্ঞাসা করতে হবে না।


1
কি হবে যদি, অন্যান্য প্রোগ্রামের মেমরি যা আপনার প্রোগ্রাম অকারণে আপ ধারণ করা হয় প্রয়োজন, অত: পর যদিও আপনি কোন mallocs বিনামূল্যে () অব্যবহৃত মেমরি স্পেস :) প্রয়োজন হবে না পারে,
এম এন

2
আপনি আমার বক্তব্য পুরোপুরি মিস করেছেন। আপনি যখন () স্মৃতি মুক্ত করেন, অন্যান্য প্রোগ্রামগুলি এটি ব্যবহার করতে পারে না! (কখনও কখনও তারা এগুলি করতে পারে, বিশেষত যদি আপনি মেমরির বৃহত ব্লকগুলি মুক্ত করেন But তবে প্রায়শই তারা পারেন না!) এই পরিষ্কার করার জন্য আমি আমার পোস্টটি সম্পাদনা করব।
আর্টিলিয়াস

27

অ্যাপ্লিকেশনটি চালুর পরে ওএস পরিষ্কার করার ক্ষেত্রে ধারণাগতভাবে কোনও ভুল নেই।

এটি অ্যাপ্লিকেশন এবং এটি কীভাবে চালানো হবে তার উপর নির্ভর করে। অবিচ্ছিন্নভাবে একটি অ্যাপ্লিকেশনটিতে সপ্তাহের জন্য চালিত হওয়া ফাঁস হওয়া উচিত, যত্ন নেওয়া উচিত তবে একটি ছোট সরঞ্জাম যা মেমরির প্রয়োজনের খুব বেশি ছাড়াই ফলাফল গণনা করে কোনও সমস্যা হওয়া উচিত নয়।

অনেক স্ক্রিপ্টিং ভাষা আবর্জনাচক্রীয় রেফারেন্স সংগ্রহ করে না তার কারণ রয়েছে ... তাদের ব্যবহারের নিদর্শনগুলির জন্য এটি কোনও আসল সমস্যা নয় এবং এভাবে নষ্ট স্মৃতি হিসাবে যত সম্পদ অপচয় করা হয় ততটা হ'ল।


স্ক্রিপ্টিং ল্যাঙ্গুয়েজ সম্পর্কে: পাইথন রিফকাউন্টিং ব্যবহার করে তবে সাইক্লিকাল রেফারেন্সগুলি মুক্ত করার জন্য একটি জিসি রয়েছে। অন্যান্য ভাষায়, প্রোগ্রামার প্রায়শই পুরোপুরি স্পষ্টভাবে চক্রীয় রেফারেন্স এড়িয়ে যায়, যা অন্যান্য সমস্যা তৈরি করে।
ব্লেসরব্লেড

পিএইচপি-র পূর্ববর্তী সংস্করণগুলি মেমরি ছেড়ে দেয় না, এগুলি কেবল মেমরির বৃদ্ধি থেকে শুরু থেকে শেষ পর্যন্ত দৌড়েছিল - সাধারণত সম্পাদনের সময় 0.1 সেকেন্ডের পরে স্ক্রিপ্টটি প্রস্থান করে, এবং সমস্ত স্মৃতি পুনরায় দাবি করা হবে।
আরাফাঙ্গিয়ন

19

আমি বিশ্বাস করি উত্তরটি হ'ল না, কখনই কোনও স্মৃতি ফাঁস হতে দেবেন না এবং আমার কয়েকটি কারণ রয়েছে যা আমি স্পষ্ট করে বলেছি না। এখানে দুর্দান্ত প্রযুক্তিগত উত্তর রয়েছে তবে আমি মনে করি আসল উত্তরটি আরও সামাজিক / মানবিক কারণে আবদ্ধ।

(প্রথমত, লক্ষ্য করুন যে অন্যরা যেমন উল্লেখ করেছে, সত্যিকারের ফাঁস তখন হয় যখন আপনার প্রোগ্রামটি যে কোনও মুহুর্তে বরাদ্দকৃত মেমরি রিসোর্সগুলি হারিয়ে ফেলে। সি তে, যখন আপনি malloc()কোনও পয়েন্টারের কাছে যান এবং সেই পয়েন্টারটি না করেই সুযোগ ছেড়ে দিন this free()প্রথম।)

এখানে আপনার সিদ্ধান্তের গুরুত্বপূর্ণ ক্রুসটি অভ্যাস। আপনি যখন এমন কোনও ভাষায় কোড করেন যা পয়েন্টার ব্যবহার করে, আপনি পয়েন্টারগুলি প্রচুর ব্যবহার করতে যাচ্ছেন । এবং পয়েন্টারগুলি বিপজ্জনক; আপনার কোডটিতে সমস্ত ধরণের গুরুতর সমস্যা যুক্ত করার সহজ উপায় এটি।

আপনি যখন কোডিং করছেন, কখনও কখনও আপনি বলের দিকে চলে যাবেন এবং কখনও কখনও আপনি ক্লান্ত বা উন্মাদ বা চিন্তিত হয়ে যাবেন। কিছুটা বিভ্রান্ত সময়ে, আপনি অটোপাইলটে আরও কোডিং করছেন। বৃহত্তর প্রকল্পের এক-অফ কোড এবং মডিউলের মধ্যে স্বতঃপাইলট প্রভাব পার্থক্য করে না। এই সময়ে, আপনি যে অভ্যাসগুলি প্রতিষ্ঠা করেন তা হ'ল যা আপনার কোড বেসে শেষ হবে।

সুতরাং না, কখনও একই কারণে মেমরি ফাঁস হতে দেবেন না যে এই মুহুর্তে আপনি যদি রাস্তায় একমাত্র গাড়ি হন এমনকি লেন পরিবর্তন করার সময় আপনার অন্ধ দাগগুলি পরীক্ষা করা উচিত। আপনার সক্রিয় মস্তিষ্কের বিভ্রান্ত হওয়ার সময়ে, ভাল অভ্যাসগুলি হ'ল বিপর্যয়কর ক্ষতির হাত থেকে বাঁচাতে পারে।

"অভ্যাস" ইস্যু ছাড়াই পয়েন্টারগুলি জটিল এবং প্রায়শই মানসিকভাবে ট্র্যাক করার জন্য প্রচুর মস্তিষ্কের শক্তি প্রয়োজন। আপনার পয়েন্টারগুলির ব্যবহারের বিষয়টি যখন "জলকে কাঁদা" না করা ভাল, বিশেষত আপনি যখন প্রোগ্রামিংয়ে নতুন হন।

আরও একটি সামাজিক দিক আছে। malloc()এবং এর যথাযথ ব্যবহারের দ্বারা free(), যে কেউ আপনার কোড দেখবে সে নিশ্চিন্ত হবে; আপনি আপনার সংস্থান পরিচালনা করছেন। তবে আপনি যদি তা না করেন তবে তারা তাত্ক্ষণিকভাবে কোনও সমস্যার সন্দেহ করবে।

হতে পারে আপনি পরিশ্রম করেছেন যে মেমরি ফুটো এই প্রসঙ্গে কোনও ক্ষতি করে না, তবে কোডের এই অংশটি পড়লে আপনার কোডের প্রত্যেক রক্ষণকারীকে তার মাথায় কাজ করতে হবে। free()আপনি ব্যবহার করে এমনকি বিষয়টি বিবেচনা করার প্রয়োজনীয়তা সরিয়ে ফেলুন।

পরিশেষে, প্রোগ্রামিং একটি প্রক্রিয়াটির মানসিক মডেলটিকে একটি দ্ব্যর্থহীন ভাষায় লিখছে যাতে কোনও ব্যক্তি এবং একটি কম্পিউটার পুরোপুরি এই প্রক্রিয়াটি বুঝতে পারে। ভাল প্রোগ্রামিং অনুশীলনের একটি গুরুত্বপূর্ণ অংশ কখনই অপ্রয়োজনীয় অস্পষ্টতা প্রবর্তন করে না।

স্মার্ট প্রোগ্রামিং নমনীয় এবং জেনেরিক। খারাপ প্রোগ্রামিং অস্পষ্ট।


আমি অভ্যাস ধারণা পছন্দ। আমিও একমত। যদি আমি কোনও স্মৃতি ফাঁস দেখি তবে আমি সর্বদা ভাবছি যে কোডারটি অন্য কোণটি কেটেছিল। বিশেষত যদি এটি সুস্পষ্ট হয়
baash05

এটি এখন পর্যন্ত সেরা উত্তর। আমি এখন 5 বছর ধরে সি ++ এ প্রোগ্রামিং করছি এবং আমি কোনও একক মেমরি ফুটো কখনও লিখিনি। কারণটি হ'ল আমি এমন কোড লিখি না যা মেমরি ফাঁস করে। ভাল সি ++ ডিজাইনের ক্ষেত্রে আপনি খুব কমই ব্যবহার করেছেন new, যাতে এখনই বেশিরভাগ মেমরি ফাঁস দূর হয়। কেবলমাত্র যদি আপনি অবশ্যই ব্যবহার করেন new। এর ফলাফলটি newঅবশ্যই অবিলম্বে একটি স্মার্ট পয়েন্টারে রেখে দেওয়া উচিত। আপনি যদি এই দুটি নিয়ম অনুসরণ করেন তবে আপনি কখনই মেমরি ফাঁস করবেন না (কোনও লাইব্রেরিতে বাগ বাদ দিয়ে)। বাকি একমাত্র shared_ptrকেসটি চক্র, সেই ক্ষেত্রে আপনাকে ব্যবহার করতে হবে weak_ptr
ডেভিড স্টোন

15

আমি মনে করি আপনার পরিস্থিতিতে উত্তরটি হতে পারে এটি ঠিক আছে। তবে আপনাকে অবশ্যই ডকুমেন্ট করতে হবে যে মেমরি ফাঁস একটি সচেতন সিদ্ধান্ত। আপনি কোনও রক্ষণাবেক্ষণের প্রোগ্রামারটি আসতে চান না, কোনও ফাংশনের অভ্যন্তরে আপনার কোডটি চাপড়ান এবং এটি মিলিয়ন বার কল করুন। সুতরাং যদি আপনি সিদ্ধান্ত নেন যে একটি ফাঁস ঠিক আছে তবে আপনাকে ভবিষ্যতে প্রোগ্রামটিতে কাজ করতে হতে পারে তার জন্য এটি (বড় আকারে) নথিভুক্ত করতে হবে।

এটি যদি কোনও তৃতীয় পক্ষের গ্রন্থাগার হয় তবে আপনি আটকে যেতে পারেন। তবে অবশ্যই এই দলিল যা এই ফাঁস ঘটে।

তবে মূলত যদি মেমরি ফাঁস 512 কেবি বাফার বা অন্য কোনও মত জ্ঞাত পরিমাণ হয় তবে এটি একটি নন ইস্যু। মেমরি ফাঁস যদি আপনি লাইব্রেরিতে কল করার মতো প্রতিটি বার বাড়তে থাকে তবে আপনার স্মৃতি 512KB বৃদ্ধি পায় এবং মুক্ত হয় না, তবে আপনার সমস্যা হতে পারে। আপনি যদি এটি নথিভুক্ত করেন এবং কলটি কার্যকর হওয়ার সময়টি নিয়ন্ত্রণ করেন তবে এটি পরিচালনাযোগ্য হতে পারে। তবে তারপরে আপনার সত্যিকারের ডকুমেন্টেশন প্রয়োজন কারণ 512 বেশি নয়, 5 মিলিয়নের বেশি কল প্রচুর।

এছাড়াও আপনাকে আপনার অপারেটিং সিস্টেমের ডকুমেন্টেশন পরীক্ষা করতে হবে। যদি এটি এমবেডড ডিভাইস থাকে তবে এমন অপারেটিং সিস্টেম থাকতে পারে যা প্রস্থান থেকে বেরিয়ে আসা কোনও প্রোগ্রাম থেকে সমস্ত মেমরি মুক্ত করে না। আমি নিশ্চিত নই, সম্ভবত এটি সত্য নয়। তবে এটি সন্ধান করা মূল্যবান।


3
"তবে আপনাকে অবশ্যই নথিভুক্ত করতে হবে যে মেমরি ফাঁস একটি সচেতন সিদ্ধান্ত" " ধন্যবাদ স্বর্গ। এখন পর্যন্ত তৈরি সেরা পয়েন্ট।
পেস্টোফাগোগাস

15

আমি অজনপ্রিয় কিন্তু বাস্তব উত্তর দিতে যাচ্ছি যে এটি মুক্ত করা মেমরির পক্ষে সর্বদা ভুল না হয় যদি না তা আপনার প্রোগ্রামের মেমরির ব্যবহার হ্রাস করে । উদাহরণস্বরূপ, এমন কোনও প্রোগ্রাম যা ডেটাসেটটি লোড করতে একক বরাদ্দ বা বরাদ্দের সিরিজ করে যা এটি তার পুরো জীবনকালের জন্য ব্যবহার করবে, কিছুই মুক্ত করার দরকার নেই। খুব গতিশীল মেমোরি প্রয়োজনীয়তা (ওয়েব ব্রাউজারের কথা ভাবা) সহ একটি বৃহত প্রোগ্রামের সাধারণ ক্ষেত্রে আপনি অবশ্যই যত তাড়াতাড়ি সম্ভব ব্যবহার করতে পারবেন না (উদাহরণস্বরূপ কোনও ট্যাব / নথি / ইত্যাদি বন্ধ করে দেওয়া) , তবে ব্যবহারকারী যখন ক্লিকগুলি "প্রস্থান" নির্বাচন করেন, তখন কিছুই মুক্ত করার কোনও কারণ নেই এবং এটি করা ব্যবহারকারীর অভিজ্ঞতার পক্ষে ক্ষতিকারক।

কেন? মেমরি মুক্ত করার জন্য স্পর্শকৃত স্মৃতি দরকার। এমনকি যদি আপনার সিস্টেমের মলোক বাস্তবায়ন বরাদ্দ মেমরি ব্লক সংলগ্ন মেটাডেটা সংরক্ষণ না করে, আপনি সম্ভবত যে সমস্ত পয়েন্টারগুলি মুক্ত করতে হবে তা খুঁজে পাওয়ার জন্য আপনি সম্ভবত পুনরাবৃত্ত কাঠামোয় হাঁটছেন।

এখন, ধরুন আপনার প্রোগ্রামটি বিশাল পরিমাণে ডেটা নিয়ে কাজ করেছে তবে কিছুক্ষণের জন্য এটির বেশিরভাগ অংশ স্পর্শ করেনি (আবার ওয়েব ব্রাউজারটি একটি দুর্দান্ত উদাহরণ)। যদি ব্যবহারকারী প্রচুর অ্যাপ চালাচ্ছেন তবে সেই ডেটার একটি ভাল অংশ সম্ভবত ডিস্কে বদলে গেছে to আপনি যদি কেবল প্রস্থান করেন (0) বা প্রধান থেকে ফিরে এসেছেন, এটি তাত্ক্ষণিকভাবে প্রস্থান করে। দুর্দান্ত ব্যবহারকারীর অভিজ্ঞতা। আপনি যদি সমস্ত কিছু খালি করার চেষ্টা করে যান তবে আপনি 5 সেকেন্ড বা তারও বেশি সময় ধরে সমস্ত ডেটা অদলবদল করতে ব্যয় করতে পারেন, কেবলমাত্র এরপরেই তা ফেলে দিতে। ব্যবহারকারীর সময় নষ্ট। ল্যাপটপের ব্যাটারির লাইফ নষ্ট করা। হার্ড ডিস্কে পরিধানের অপচয়।

এটি কেবল তাত্ত্বিক নয়। যখনই আমি নিজেকে অনেক বেশি অ্যাপযুক্ত লোড পেয়েছি এবং ডিস্কটি থ্র্যাশ করতে শুরু করে, আমি "প্রস্থান" ক্লিক করাও বিবেচনা করি না। আমি যত তাড়াতাড়ি টার্মিনালে উঠি এবং কিল্ল -9 টাইপ করি ... কারণ আমি জানি "প্রস্থান" এটিকে আরও খারাপ করে দেবে।


5
রেমন্ড চেনের এই উক্তিটি ভালবাসুন: "বিল্ডিংটি ধ্বংস হচ্ছে। আউট চৌম্বককে বের করে দিন you're আপনারা যা করছেন তা ধ্বংসাত্মক দলকে এই অর্থহীন গৃহসজ্জার কাজগুলি শেষ করার জন্য আপনার অপেক্ষা করতে তৈরি করছে "" ( Blogs.msdn.microsoft.com/oldnewthing/20120105-00/?p=8683 )
আন্দ্রিয়াস Magnusson

11

আমি নিশ্চিত যে কেউ হ্যাঁ বলার কারণ নিয়ে আসতে পারে তবে এটি আমার হবে না। না বলার পরিবর্তে, আমি বলতে যাচ্ছি যে এটি হ্যাঁ / কোনও প্রশ্ন হওয়া উচিত নয়। মেমরি ফাঁস পরিচালনা বা ধারণ করার বিভিন্ন উপায় রয়েছে এবং অনেকগুলি সিস্টেমে সেগুলি রয়েছে।

ডিভাইসগুলিতে নাসা সিস্টেম রয়েছে যা পৃথিবী ছেড়ে যায় যা এর জন্য পরিকল্পনা করে। সিস্টেমগুলি স্বয়ংক্রিয়ভাবে প্রতিবার পুনরায় চালু হবে যাতে মেমরি ফাঁস সামগ্রিক ক্রিয়াকলাপের জন্য মারাত্মক না হয়। পাত্রে কেবল উদাহরণ।


এটি আসলে সফ্টওয়্যার বার্ধক্যের একটি উদাহরণ। অধ্যয়নের বিষয় আকর্ষণীয়।
কনরাড রুডল্ফ

এত বার প্রায়শই একটি স্বয়ংক্রিয় রিবুট হয়, তাই না? নাসা, হাহ? (* পুরানো মাইক্রোসফ্ট উইন্ডোজ ইনস্টলেশন সিডির দিকে নজর দেওয়া *) এটি এতটা ব্যাখ্যা করে ...
ক্রিশ্চিয়ান সেভেরিন

8

যদি আপনি মেমরি বরাদ্দ করেন এবং আপনার প্রোগ্রামের শেষ লাইন পর্যন্ত ব্যবহার করেন, এটি কোনও ফাঁস নয়। আপনি যদি মেমোরি বরাদ্দ করেন এবং এটিকে ভুলে যান, এমনকি মেমরির পরিমাণ বাড়ছে না তাও সমস্যা a বরাদ্দযুক্ত কিন্তু অব্যবহৃত মেমরির কারণে অন্যান্য প্রোগ্রামগুলি ধীরে ধীরে চলতে পারে বা না মোটেই না।


আসলেই নয়, যেহেতু এটি অব্যবহৃত হয় তবে এটি কেবল পৃষ্ঠাযুক্ত হয়ে যাবে। অ্যাপটি প্রস্থান করলে সমস্ত মেমরি প্রকাশিত হয়।
অন্ধকার

যতক্ষণ না এটি বরাদ্দ করা হয় অন্য প্রোগ্রামগুলি এটি ব্যবহার করতে সক্ষম হবে না। আপনি যদি এটি হ্রাস না করেন তবে এটি পৃষ্ঠাবদ্ধ হবে না।
বিলটি

অবশ্যই এটি হবে - যা ভার্চুয়াল মেমরি প্রায় হয়। আপনার কাছে 1 গিগাবাইট আসল র‌্যাম থাকতে পারে এবং ততক্ষণে 4 টি প্রক্রিয়া সম্পূর্ণরূপে প্রতিটি 2 জিবি ভার্চুয়াল মেমরির বরাদ্দ করে থাকে (যতক্ষণ না আপনার পৃষ্ঠার ফাইল যথেষ্ট বড় হয়)।
অন্ধকার

অবশ্যই, যদি সেই প্রতিটি প্রক্রিয়া সক্রিয়ভাবে সমস্ত স্মৃতি ব্যবহার করে তবে আপনি দুষ্টু পেজিংয়ের সমস্যাগুলি পাবেন।
অন্ধকার

ঠিক আছে, আমি বুঝতে পারছি আপনি এখন কী বিষয়ে কথা বলছেন। আপনি যদি মেমোরিটি ডিলেট করেন না তবে আপনি পেজিংয়ের প্রয়োজনীয়তা হ্রাস করবেন। আপনি যদি এটি বরাদ্দ
বিলোর দ্য লিজার্ড

8

আমি একদিকে আমি "সৌম্য" ফাঁসের সংখ্যাটি গণনা করতে পারি যা আমি সময়ের সাথে সাথে দেখেছি।

সুতরাং উত্তরটি খুব যোগ্য হ্যাঁ।

একটি উদাহরণ. যদি আপনার একটি সিঙ্গলটন রিসোর্স থাকে যার একটি বৃত্তাকার সারি বা ডিউক সংরক্ষণের জন্য বাফারের প্রয়োজন হয় তবে বাফারটি কতটা বড় হতে হবে তা জানেন না এবং লকিং বা প্রতিটি পাঠকের ওভারহেড বহন করতে পারবেন না, তবে একটি তাত্পর্যপূর্ণ দ্বিগুণ বাফার বরাদ্দ করুন তবে পুরানোগুলি নিখরচায় না করা প্রতি সারি / ডেকিতে একটি সীমিত পরিমাণের মেমরি ফাঁস করবে। এগুলির জন্য সুবিধা হ'ল তারা নাটকীয়ভাবে প্রতিটি অ্যাক্সেসকে গতিময় করে এবং কোনও লকের পক্ষে ঝুঁকির ঝুঁকি না নিয়ে মাল্টিপ্রসেসর সলিউশনের অ্যাসিপটিকগুলি পরিবর্তন করতে পারে।

আমি এই পদ্ধতিটি দেখতে পেয়েছি যে প্রতি সিপিইউ ওয়ার্ক-চুরির ডেকস হিসাবে খুব স্পষ্টভাবে নির্দিষ্ট গণনা সহ জিনিসগুলির জন্য দুর্দান্ত উপকারের জন্য ব্যবহৃত হয়েছিল /proc/self/mapsএবং হ্যান্স বোহমের রক্ষণশীল আবর্জনা সংগ্রাহক সি এর জন্য সিঙ্গলটন রাজ্যে অধিষ্ঠিত ব্যাফারের অনেক কম পরিমাণে / সি ++, যা মূল সেট ইত্যাদি সনাক্ত করতে ব্যবহৃত হয় etc.

প্রযুক্তিগতভাবে একটি ফুটো হওয়ার সময়, এই দুটি ক্ষেত্রেই আকারের সাথে আবদ্ধ এবং বিকাশযুক্ত বিজ্ঞপ্তিযুক্ত কাজ চুরি ডিক কেসটিতে সারিগুলির জন্য মেমরির ব্যবহারের 2 সীমাবদ্ধ ফ্যাক্টরের বিনিময়ে বিশাল পারফরম্যান্সের জয় রয়েছে।


1
ফাঁস রোধ করতে আপনি হিজার্ড পয়েন্টার ব্যবহার করতে পারেন।
ডেমি

8

আপনি যদি আপনার প্রোগ্রামের শুরুতে প্রচুর গাদা বরাদ্দ করেন এবং বাইরে বেরোনোর ​​সময় আপনি এটি মুক্ত করেন না, এটি প্রতি মেমরির ফুটো নয়। একটি মেমরি ফাঁস হয় যখন আপনার প্রোগ্রামটি কোডের একটি বিভাগের উপরে লুপ করে, এবং সেই কোডটি গাদা বরাদ্দ করে এবং তারপরে এটিকে বিনামূল্যে ছাড়াই "ট্র্যাক হারায়"।

প্রকৃতপক্ষে, বাইরে বেরোনোর ​​আগে বিনামূল্যে () মুক্ত করতে বা মুছতে কল করার প্রয়োজন নেই। প্রক্রিয়াটি যখন প্রস্থান করে, তখন এর সমস্ত স্মৃতি ওএস দ্বারা পুনরুদ্ধার করা হয় (এটি অবশ্যই পসিক্সের ক্ষেত্রে হয় other অন্যান্য ওএসগুলিতে - বিশেষত এমবেড হওয়াগুলি - ওয়াইএমএমভি)।

প্রস্থান করার সময় মেমরিটি নিখরচায় না করা সম্পর্কে কেবলমাত্র সতর্কতা হ'ল যদি আপনি আপনার প্রোগ্রামটিকে কখনও রিফেক্টর করেন যাতে এটি উদাহরণস্বরূপ, এমন একটি পরিষেবা হয়ে যায় যা ইনপুটটির জন্য অপেক্ষা করে, আপনার প্রোগ্রাম যা কিছু করে, তারপরে অপেক্ষা করার জন্য প্রায় লুপ করে অন্য একটি পরিষেবা কল, তারপর আপনি কি কোডেড থাকেন করতে একটি মেমরি লিক এ পরিণত হয়।


আমি আলাদা করতে অনুরোধ। এটি হ'ল "প্রতি মেমরি ফাঁস"।
কনরাড রুডল্ফ

আপনি অবজেক্টের রেফারেন্সটি "হারান" না হওয়া পর্যন্ত এটি ফাঁস হয় না। সম্ভবত, যদি মেমরিটি প্রোগ্রামটির আজীবন ব্যবহার করা হয়, তবে এটি ফাঁস হয় না। প্রস্থানটি (প্রস্থান) না বলা পর্যন্ত যদি রেফারেন্সটি হারিয়ে না যায় তবে তা একেবারে ফাঁস হয় না
nsayer

অমিগা ডস হ'ল সর্বশেষ ও / এসআই যা দেখেছিল তা প্রক্রিয়াগুলির পিছনে পরিষ্কার হয়নি। যদিও সচেতন হোন যে সিস্টেম ভি আইপিসি ভাগ করা মেমরিটি কোনও প্রক্রিয়া ব্যবহার না করা সত্ত্বেও ফেলে রাখা যেতে পারে।
জোনাথন লেফলার

আপনি হটসিঙ্ক না করা পর্যন্ত পাম মেমরিটিকে "ফাঁস" মুক্ত করে না। এমিগা পরে এটি ভাল এসেছিল। আমি আমার পাম এমুলেটরটিতে অ্যাপ্লিকেশন চালিয়েছি যার ফাঁস হয়েছিল .. তারা কখনই আমার আসল তালুর দিকে যায় নি।
baash05

6

এটি এতটা ডোমেন-নির্দিষ্ট যে এর উত্তর দেওয়া খুব কমই মূল্যবান। আপনার উদ্ভট মাথা ব্যবহার করুন।

  • স্পেস শাটল অপারেটিং সিস্টেম: না, কোনও মেমরি ফাঁসের অনুমতি নেই
  • দ্রুত বিকাশের প্রমাণ-অফ-কনসেপ্ট কোড: এই সমস্ত মেমরি ফুটো ঠিক করা সময়ের অপচয়।

এবং মধ্যবর্তী পরিস্থিতিতে একটি বর্ণালী আছে।

সবচেয়ে খারাপ মেমরি ফাঁস ছাড়াও সমস্ত কিছু ঠিক করার জন্য কোনও পণ্যের রিলিজ বিলম্বিত করার সুযোগ ব্যয় ($$$) সাধারণত "আচ্ছাদিত বা অলাভজনক" হওয়ার কোনও অনুভূতি বামন করে। আপনার বস আপনাকে অর্থোপার্জন করার জন্য অর্থ প্রদান করে, উষ্ণ, অস্পষ্ট অনুভূতি না পেতে।


2
খুব স্বল্পদৃষ্টির মনোভাব। আপনি মূলত বলছেন যে যতক্ষণ না এই অনুশীলনের ফলে কোনও ত্রুটি দেখা না দেয় ততক্ষণ মৌলিকভাবে সাউন্ড প্রোগ্রামিং অনুশীলনগুলি ব্যবহার করার দরকার নেই। সমস্যাটি হ'ল যে সফটওয়্যারটি opালু পদ্ধতি ব্যবহার করে লেখা হয় সেই সফ্টওয়্যারটির চেয়ে আরও বেশি ত্রুটি থাকে।
জন ডিবলিং

1
আমি সব বিশ্বাস করি না। এবং পরিষ্কার পদ্ধতি লেখার চেয়ে মেমরি পরিচালনা আরও জটিল।
ডাস্টিন গেটেজ

1
ডাস্টিন স্পষ্টতই আমাদের বেশিরভাগের মতো বাস্তব বিশ্বে কাজ করে, যেখানে আমরা ক্রমাগত প্রতিযোগিতা চালিয়ে যাওয়ার জন্য উন্মাদ সময়সীমার বিরুদ্ধে কাজ করি। সুতরাং বাগগুলি নিয়ে কাজ করার বিষয়টি ব্যবহারিক পদ্ধতিতে করা উচিত। গুরুত্বহীন প্রোগ্রামগুলিতে গুরুত্বহীন বাগগুলিতে অতিরিক্ত সময় নষ্ট করে আপনি আপনার জিনিসগুলি শেষ করতে পারবেন না।
ওয়াউটার ভ্যান নিফটারিক

এই মনোভাবের সাথে সমস্যাটি: আপনি কখন ফাঁসগুলি ঠিক করতে শুরু করেন? "ঠিক আছে, এটি একটি পাওয়ার প্লান্ট, তবে এটি কেবল কয়লা, ইউরেনিয়াম নয় here এখানে কেন ফাঁস ঠিক করবেন?" - আমি বাস্তব বিশ্বে শিখেছি যে আপনি যদি প্রথম থেকেই সঠিক কাজটি না করেন, সমস্ত সময়, এটি কখনও ঘটে না। এই মনোভাবটি এমন প্রকল্পগুলিকে প্রজনন করে যা দুটি সপ্তাহের পরে "99% সম্পূর্ণ" এবং দু'মাস ধরে থাকে।
পিটারচেন

5

আপনাকে প্রথমে বুঝতে হবে যে অনুভূত মেমরি ফাঁস এবং একটি আসল মেমরি ফাঁসের মধ্যে একটি বড় পার্থক্য রয়েছে। খুব ঘন ঘন বিশ্লেষণ সরঞ্জামগুলি অনেকগুলি লাল হেরিংয়ের প্রতিবেদন করবে এবং এমন কিছুকে ফাঁস হয়ে গেছে (স্মৃতি বা হ্যান্ডলগুলির মতো সম্পদগুলি) যেখানে এটি আসলে নেই তা লেবেল করবে। বিশ্লেষণ সরঞ্জামের স্থাপত্যের কারণে প্রায়শই এটি ঘটে। উদাহরণস্বরূপ, নির্দিষ্ট বিশ্লেষণ সরঞ্জামগুলি রান টাইম অবজেক্টগুলিকে মেমরি ফাঁস হিসাবে প্রতিবেদন করবে কারণ এটি কখনই সেগুলিকে মুক্ত করে না। তবে রান-টাইমের শাটডাউন কোডে ডিএলোকেশনটি ঘটে যা বিশ্লেষণ সরঞ্জামটি দেখতে না পারা।

যা বলেছিল, এখনও এমন সময় আসবে যখন আপনার আসল মেমরি ফাঁস হবে যা খুঁজে পাওয়া খুব কঠিন বা সমাধান করা খুব কঠিন। সুতরাং এখন প্রশ্নটি হয়ে যায় যে তাদের কোডে রেখে দেওয়া কি কখনও ঠিক হবে?

আদর্শ উত্তরটি হ'ল "না, কখনই নয়।" আরও ব্যবহারিক উত্তর হতে পারে "না, প্রায় কখনও না"। খুব প্রায়ই বাস্তব জীবনে আপনার সমাধানের সীমিত সংস্থান এবং কার্যের অবিরাম তালিকা থাকে have যখন কোনও কাজ মেমরির ফাঁস দূর করে দিচ্ছে, তখন প্রায়শই হ্রাসকারী রিটার্নটি খেলতে আসে। আপনি এক সপ্তাহের মধ্যে একটি অ্যাপ্লিকেশনে 98% সমস্ত মেমরি লিকটি কেটে ফেলতে পারেন, তবে বাকি 2% মাসে কয়েক মাস সময় নিতে পারে। কিছু ক্ষেত্রে কোডের কোনও বড় প্রতিস্থাপন ছাড়াই অ্যাপ্লিকেশনটির আর্কিটেকচারের কারণে নির্দিষ্ট লিকগুলি অপসারণ করাও অসম্ভব হতে পারে। বাকি 2% মুছে ফেলার জন্য আপনাকে ব্যয় এবং সুবিধাগুলি বিবেচনা করতে হবে।


5

এই প্রসঙ্গে প্রশ্ন প্রসঙ্গে সবকিছু। ব্যক্তিগতভাবে আমি ফাঁসগুলি দাঁড়াতে পারি না এবং আমার কোডে তারা ক্রপ হয়ে গেলে তাদের সংশোধন করার জন্য আমি প্রচুর পরিমাণে যাই, তবে একটি ফাঁস ঠিক করা কখনই উপযুক্ত নয় এবং যখন লোকেরা আমাকে উপলক্ষ্যে যে মুহুর্তে আমাকে প্রদান করে are তাদেরকে বলেছিলাম যে তাদের কোডে একটি ফাঁস ঠিক করা আমার জন্য মূল্য নির্ধারণের উপযুক্ত নয়। আমাকে যদি আপনি একটি উদাহরণ দিতে:

আমি একটি প্রকল্প ট্রিবিং করছিলাম, কিছু নিখুঁত কাজ করছিলাম এবং অনেক বাগ ফিক্স করছি। অ্যাপ্লিকেশন প্রারম্ভিককরণের সময় একটি ফাঁস হয়েছিল যা আমি ট্র্যাক করেছি এবং পুরোপুরি বুঝতে পেরেছি। এটি সঠিকভাবে ফিক্স করার জন্য একটি দিন প্রয়োজন হত অথবা অন্যথায় কার্যকরী কোডের একটি অংশকে পুনরুদ্ধার করতে হবে। আমি হ্যাকি কিছু করতে পারতাম (যেমন গ্লোবাল হিসাবে মান পূরণ করা এবং এটি জানতে পারা যে আমি জানি যে এটি আর মুক্ত করা হয়নি) তবে এটি পরবর্তী লোকটির কাছে আরও বিভ্রান্তির কারণ হয়ে পড়েছিল যাকে কোডটি স্পর্শ করতে হয়েছিল।

ব্যক্তিগতভাবে আমি কোডটি প্রথম স্থানে লিখতাম না, তবে আমাদের বেশিরভাগই সবসময় আধ্যাত্মিকভাবে নকশাযুক্ত কোডবেসগুলিতে কাজ করতে পাই না এবং কখনও কখনও আপনাকে এই বিষয়গুলি ব্যবহারিকভাবে দেখতে হয়। আমাকে যে পরিমাণ সময় দিতে হয়েছিল তা ঠিক করতে যে 150 বাইট ফাঁস এর পরিবর্তে অ্যালগরিদমিক উন্নতি করতে ব্যয় করা যেতে পারে যা র‌্যামের মেগাবাইট বন্ধ করে দেয়।

শেষ পর্যন্ত, আমি স্থির করেছিলাম যে একটি অ্যাপ্লিকেশনের জন্য ১৫০ বাইট ফাঁস করা যা একটি গিগের র‌্যামের আশেপাশে ব্যবহৃত হয় এবং একটি উত্সর্গীকৃত মেশিনে দৌড়ে যায় তা সংশোধন করার পক্ষে উপযুক্ত নয়, তাই আমি একটি মন্তব্য লিখেছিলাম যে এটি ফাঁস হয়েছিল, ঠিক করার জন্য কী পরিবর্তন করা দরকার? এটি, এবং কেন এটি সেই সময়ের জন্য উপযুক্ত ছিল না।


স্মার্ট। বিশেষত যেহেতু ফাঁসটি শুরু করার সময় ছিল, যার অর্থ এটি অ্যাপ্লিকেশনটির রানটাইম জুড়ে জমে না।
ডেমি

5

যদিও বেশিরভাগ উত্তরগুলি সত্যিকারের স্মৃতি মেমরি ফাঁসের দিকে মনোনিবেশ করে (যা কখনই ঠিক হয় না, কারণ এগুলি ঝাপটা কোডিংয়ের লক্ষণ), প্রশ্নের এই অংশটি আমার কাছে আরও আকর্ষণীয় বলে মনে হয়:

আপনি যদি কিছু মেমোরি বরাদ্দ করেন এবং আপনার অ্যাপ্লিকেশনটিতে কোডের শেষ লাইন পর্যন্ত এটি ব্যবহার করেন (উদাহরণস্বরূপ, একটি গ্লোবাল অবজেক্টের ডেকনস্ট্রাক্টর)? যতক্ষণ সময়ের সাথে মেমরির খরচ বাড়বে না, আপনার অ্যাপ্লিকেশনটি বন্ধ হয়ে গেলে (উইন্ডোজ, ম্যাক এবং লিনাক্সে) আপনার জন্য আপনার মেমরিটি মুক্ত করতে ওএসকে বিশ্বাস করা ঠিক হবে? এমনকি যদি ওএস দ্বারা মুক্ত না করা পর্যন্ত মেমরিটি ধারাবাহিকভাবে ব্যবহৃত হয়ে থাকে তবে আপনি কি এটি একটি আসল মেমরি ফাঁস বিবেচনা করবেন?

যদি সম্পর্কিত মেমোরি ব্যবহার করা হয় তবে প্রোগ্রামটি শেষ হওয়ার আগে আপনি এটিকে মুক্ত করতে পারবেন না। ফ্রিটি প্রোগ্রামের প্রস্থান দ্বারা বা OS দ্বারা সম্পন্ন হয় তা বিবেচনাধীন নয়। যতক্ষণ এটি নথিভুক্ত করা হয়, ততক্ষণ পরিবর্তনটি আসল মেমরি ফাঁসের পরিচয় দেয় না এবং যতক্ষণ না ছবিতে কোনও সি ++ ডিস্ট্রাক্টর বা সি ক্লিনআপ ফাংশন জড়িত থাকে। কোনও অ-বন্ধ ফাইলটি কোনও ফাঁস হওয়া FILEঅবজেক্টের মাধ্যমে প্রকাশিত হতে পারে , তবে একটি অনুপস্থিত fclose () বাফারটিকে ফ্লাশ না করার কারণ হতে পারে।

সুতরাং, মূল ক্ষেত্রে ফিরে আসা, এটি নিজের মধ্যে আইএমএইচও পুরোপুরি ঠিক আছে, এতটাই যে সর্বাধিক শক্তিশালী লিক ডিটেক্টর, ভ্যালগ্রিন্ড কেবল অনুরোধ করলেই এই ধরনের ফাঁসের আচরণ করবে। ভালগ্রিন্ডে, আপনি যখন কোনও পয়েন্টারটিকে আগেই মুক্ত না করে ওভাররাইট করে ফেলেন, তখন এটি মেমরি ফাঁস হিসাবে বিবেচিত হবে, কারণ এটি আবার ঘটার সম্ভাবনা বেশি এবং অবিচ্ছিন্নভাবে গাদা বাড়ার কারণ।

তারপরে, এনফ্রিড মেমরি ব্লকগুলি নেই যা এখনও অ্যাক্সেসযোগ্য। প্রস্থান করার সময় যে কেউ এই সমস্তটিকে মুক্ত করতে নিশ্চিত করতে পারে তবে এটি নিজের মধ্যে কেবল সময়ের অপচয়। মুল বক্তব্যটি হ'ল যদি তাদের আগে মুক্তি দেওয়া যায় । মেমরির খরচ হ্রাস করা যে কোনও ক্ষেত্রেই কার্যকর।


বাহ ... কেউ জানেন যে মেমরি ফুটো কী।
সাইমন বুচান

4

আমি ভিফিলবির সাথে একমত - এটি নির্ভর করে। উইন্ডোজে আমরা মেমরি ফাঁসকে তুলনামূলকভাবে সিরিস বাগ হিসাবে গণ্য করি। তবে, এটি উপাদানটির উপর নির্ভর করে।

উদাহরণস্বরূপ, মেমোরি ফাঁসগুলি এমন উপাদানগুলির জন্য খুব বেশি গুরুতর নয় যেগুলি খুব কমই চালিত হয় এবং সীমিত সময়ের জন্য। এই উপাদানগুলি চালিত হয়, থায়ারের কাজ করে, তারপরে প্রস্থান করুন। যখন তারা প্রস্থান করেন তাদের সমস্ত স্মৃতি স্পষ্টতই মুক্ত হয়।

তবে পরিষেবাগুলিতে বা অন্যান্য দীর্ঘমেয়াদী উপাদানগুলিতে মেমরি ফাঁস (শেলের মতো) খুব গুরুতর। কারণটি হ'ল এই বাগগুলি সময়ের সাথে সাথে 'চুরি' স্মৃতি করে। এটি পুনরুদ্ধারের একমাত্র উপায় হ'ল উপাদানগুলি পুনরায় চালু করা। বেশিরভাগ লোকেরা কীভাবে কোনও পরিষেবা বা শেল পুনরায় চালু করতে জানেন না - তাই যদি তাদের সিস্টেমের কার্যকারিতা ক্ষতিগ্রস্থ হয় তবে তারা কেবল পুনরায় বুট করে।

সুতরাং, আপনার যদি একটি ফুটো থাকে - এর প্রভাবটি দুটি উপায়ে মূল্যায়ন করুন

  1. আপনার সফ্টওয়্যার এবং আপনার ব্যবহারকারীর অভিজ্ঞতা।
  2. সিস্টেমে (এবং ব্যবহারকারী) সিস্টেমের সংস্থানগুলির সাথে সাথী হওয়ার ক্ষেত্রে।
  3. রক্ষণাবেক্ষণ এবং নির্ভরযোগ্যতার উপর স্থির প্রভাব।
  4. অন্য কোথাও একটি রিগ্রেশন হওয়ার সম্ভাবনা।

Foredecker


৩. সফ্টওয়্যার রক্ষণাবেক্ষণের উপর প্রভাব।
পিটারচেন

3

এমনকি যদি আপনি নিশ্চিত হন যে আপনার 'জ্ঞাত' মেমরি ফুটো হ'ল বিপর্যয় সৃষ্টি করবে না, তা করবেন না। সর্বোপরি, এটি আপনার জন্য একটি ভিন্ন সময় এবং স্থানে অনুরূপ এবং সম্ভবত আরও সমালোচনামূলক ভুল করার একটি পথ প্রশস্ত করবে।

আমার জন্য এটি জিজ্ঞাসা করা প্রশ্ন করার মতো "" কেউ যখন আশেপাশে না থাকে তখন কি সকাল 3 টায় আমি লাল বাতিটি ভাঙতে পারি? " ঠিক আছে, এটি সেই সময়ে কোনও ঝামেলা নাও করতে পারে তবে তাড়াহুড়োয় একই কাজ করার জন্য এটি আপনাকে একটি লিভার সরবরাহ করবে!


3

না, আপনার ওএসের জন্য পরিষ্কার হওয়া উচিত নয়। কারণ (উপরের উত্তরে আমি যতদূর আমি পরীক্ষা করতে পারি) উল্লেখ করা হয়নি তা হ'ল আপনি কখনই জানেন না আপনার মূল () কখন অন্য প্রোগ্রামে ফাংশন / মডিউল হিসাবে পুনরায় ব্যবহৃত হবে । যদি আপনার প্রধান () অন্য ব্যক্তির সফ্টওয়্যারটিতে প্রায়শ কথিত ফাংশন হয়ে যায় - এই সফ্টওয়্যারটির একটি মেমরি ফাঁস হবে যা সময়ের সাথে সাথে স্মৃতি খায়।

KIV


3

আমি মনে করি এটি ঠিক আছে যদি আপনি কোনও প্রোগ্রাম লিখছেন যা মেমরি ফাঁস করার উদ্দেশ্যে বোঝায় (যেমন সিস্টেমের পারফরম্যান্সে মেমরি ফাঁসের প্রভাব পরীক্ষা করে)।


3

মেমরি ফুটো আসলে কী তা সম্পর্কে অনেকগুলি ভুল সংজ্ঞা দেখে আমি অবাক হয়েছি। একটি সুস্পষ্ট সংজ্ঞা ব্যতীত, এটি খারাপ জিনিস কিনা তা নিয়ে আলোচনা কোথাও যাবে না।

কিছু মন্তব্যকারী যথাযথভাবে উল্লেখ করেছেন যে, কোনও প্রক্রিয়া দ্বারা বরাদ্দকৃত স্মৃতি যখন প্রসেসটি আর রেফারেন্স করতে বা মুছতে সক্ষম হয় না তখনই মেমরি ফাঁস হয়।

একটি প্রক্রিয়া যা আরও বেশি স্মৃতি দখল করে চলেছে অগত্যা ফুটো হওয়ার দরকার নেই। যতক্ষণ না এটি সেই স্মৃতিটিকে রেফারেন্স করতে এবং হ্রাস করতে সক্ষম হয়, ততক্ষণে এটি প্রক্রিয়াটির সুস্পষ্ট নিয়ন্ত্রণে থাকে এবং ফাঁস হয় না। প্রক্রিয়াটি খুব খারাপভাবে ডিজাইন করা যেতে পারে, বিশেষত এমন একটি সিস্টেমের প্রসঙ্গে যেখানে মেমরি সীমাবদ্ধ তবে এটি লিকের মতো নয়। বিপরীতে, বলার সুযোগ হারাতে বলুন, একটি 32 বাইট বাফার এখনও ফাঁস, যদিও মেমরি ফাঁসের পরিমাণটি খুব কম। যদি আপনি এইটিকে তুচ্ছ মনে করেন, কেউ আপনার লাইব্রেরি কলের চারপাশে একটি অ্যালগরিদম জড়াল না করে এবং 10,000 বার কল না করা পর্যন্ত অপেক্ষা করুন।

আপনার নিজের কোডটিতে ফাঁস দেওয়ার অনুমতি দেওয়ার কোনও কারণ আমি দেখতে পাচ্ছি না যদিও ছোট। আধুনিক প্রোগ্রামিং ভাষা যেমন সি এবং সি ++ প্রোগ্রামারগুলিকে এই জাতীয় ফুটো রোধে সহায়তা করার জন্য যথেষ্ট পরিমাণে যায় এবং লিক প্রতিরোধের জন্য বিশেষত নির্দিষ্ট ভাষার সুবিধাসমূহের সাথে মিলিত হওয়ার সময় - ভাল প্রোগ্রামিং কৌশলগুলি অবলম্বন না করার পক্ষে খুব ভাল যুক্তি রয়েছে।

বিদ্যমান বা তৃতীয় পক্ষের কোড সম্পর্কিত, যেখানে গুনের তীব্রতার উপর নির্ভর করে গুণমান বা পরিবর্তন করার ক্ষমতার উপর আপনার নিয়ন্ত্রণ অত্যন্ত সীমাবদ্ধ হতে পারে, হ্রাস করতে আপনার প্রক্রিয়াটি নিয়মিত পুনঃসূচনা করার মতো আপনাকে গ্রহণযোগ্যতা বা পদক্ষেপ গ্রহণ করতে বাধ্য করা যেতে পারে ফুটো প্রভাব।

বিদ্যমান (ফাঁস) কোডটি পরিবর্তন বা প্রতিস্থাপন করা সম্ভব নাও হতে পারে এবং তাই আপনি এটি গ্রহণ করতে বাধ্য হতে পারেন। তবে এটি ঠিক আছে তা ঘোষণার মতো নয়।


2

এটি যদি ইচ্ছাকৃতভাবে ফাঁস হয় না এবং এটির সমস্যা না হয় যদি না এটির উল্লেখযোগ্য পরিমাণে স্মৃতি থাকে বা স্মৃতিতে একটি উল্লেখযোগ্য পরিমাণে বৃদ্ধি পেতে পারে। কোনও প্রোগ্রামের জীবদ্দশায় গ্লোবাল বরাদ্দ সাফ না করা মোটামুটি সাধারণ। যদি ফুটোটি কোনও সার্ভারে বা দীর্ঘ চলমান অ্যাপে থাকে, সময়ের সাথে সাথে বৃদ্ধি পায় তবে তার সমস্যা।


2

আমি মনে করি আপনি নিজের প্রশ্নের উত্তর দিয়েছেন। সবচেয়ে বড় অসুবিধা হ'ল তারা কীভাবে মেমরি ফাঁস সনাক্তকরণ সরঞ্জামগুলিতে হস্তক্ষেপ করে, তবে আমি মনে করি যে নির্দিষ্ট প্রকারের অ্যাপ্লিকেশনগুলির জন্য ব্যর্থতা একটি বিশাল ব্যর্থতা।

আমি লিগ্যাসি সার্ভার অ্যাপ্লিকেশনগুলির সাথে কাজ করি যা রক সলিড বলে মনে করা হয় তবে তাদের লিক রয়েছে এবং গ্লোবালগুলি মেমরি সনাক্তকরণ সরঞ্জামগুলির পথে আসে। এটা একটা বড় চুক্তি.

জ্যারেড ডায়মন্ডের "সঙ্কুচিত" বইয়ে লেখক আশ্চর্য হয়েছিলেন যে লোকটি কী ভাবছিল ইস্টার দ্বীপে শেষ গাছটি কেটেছিল, যে গাছটি দ্বীপে নামার জন্য একটি ক্যানো তৈরি করার জন্য তার প্রয়োজন হত। আমি বহু বছর আগে সেই দিনটি সম্পর্কে অবাক হয়েছি যখন সেই প্রথম বিশ্বব্যাপী আমাদের কোডবেজে যুক্ত হয়েছিল। সেদিন ধরা পড়ার কথা ছিল।


2

আমি সমস্ত দৃশ্যপটের প্রশ্নগুলির মতো একই সমস্যাটি দেখতে পাচ্ছি: প্রোগ্রামটি পরিবর্তন হয়ে গেলে কী ঘটে, এবং হঠাৎ সেই ছোট্ট মেমরি ফাঁসকে দশ মিলিয়ন বার বলা হচ্ছে এবং আপনার প্রোগ্রামের শেষটি অন্য কোনও জায়গায় রয়েছে, তাতে কী আসে যায়? যদি এটি কোনও লাইব্রেরিতে থাকে তবে লাইব্রেরি রক্ষণাবেক্ষণকারীদের সাথে একটি বাগ লগ করুন, আপনার নিজের কোডে একটি ফুটো রাখবেন না।


সেক্ষেত্রে মেমরি ফাঁসের প্রভাব পরিবর্তিত হয় এবং আপনার ফুটো প্লাগ করার অগ্রাধিকারটি পুনরায় মূল্যায়ন করতে হবে।
জন ডিবলিং

@ জন: আপনি কমপক্ষে ফাঁসটি নথিভুক্ত করুন। তারপরেও, আমি কাউকে বিশ্বাস করব না যে কোনওভাবেই বড় লাল ফ্ল্যাশিং মন্তব্য এবং অনুলিপি-অনুলিপি ফাঁকা কোডটিকে অনুলিপি করবেন না। আমি কাউকে প্রথমে এটি করার ক্ষমতা না দেওয়া পছন্দ করি।
tloach

2

আমি উত্তর দেব।

তত্ত্ব অনুসারে, আপনি যদি কোনও জগাখিচুড়ি ছেড়ে দেন তবে অপারেটিং সিস্টেমটি পরিষ্কার হয়ে যাবে (এখন এটি কেবল অভদ্র, তবে কম্পিউটারগুলির অনুভূতি না থাকলে এটি গ্রহণযোগ্য হতে পারে)। তবে আপনি যখন আপনার প্রোগ্রামটি চালাবেন তখন ঘটে যাওয়া প্রতিটি সম্ভাব্য পরিস্থিতিটি আপনি অনুমান করতে পারবেন না। অতএব (যদি আপনি কিছু আচরণের আনুষ্ঠানিক প্রমাণ পরিচালনা করতে সক্ষম না হন), মেমরি ফাঁস তৈরি করা পেশাদার দৃষ্টিকোণ থেকে কেবল দায়িত্বজ্ঞানহীন এবং opালু।

যদি কোনও তৃতীয় পক্ষের উপাদান মেমরি ফাঁস করে তবে এটি ব্যবহারের বিরুদ্ধে এটি খুব দৃ argument় যুক্তি, কেবল আসন্ন প্রভাবের কারণে নয় কারণ এটি দেখায় যে প্রোগ্রামাররা slালুভাবে কাজ করে এবং এটি অন্যান্য মেট্রিকগুলিতেও প্রভাব ফেলতে পারে। এখন, লিগ্যাসি সিস্টেমগুলি বিবেচনা করার সময় এটি কঠিন (ওয়েব ব্রাউজিং উপাদানগুলি বিবেচনা করুন: আমার জ্ঞানের কাছে, তারা সমস্ত স্মৃতি ফাঁস করে) তবে এটি আদর্শ হওয়া উচিত।


2

.তিহাসিকভাবে, এটি কিছু প্রবাহের ক্ষেত্রে কিছু অপারেটিং সিস্টেমে গুরুত্ব দেয়। ভবিষ্যতে এই প্রান্তের ঘটনাগুলি উপস্থিত থাকতে পারে।

এখানে উদাহরণস্বরূপ, সূর্য 3 যুগে সুনোস-এ একটি সমস্যা ছিল যদি কোনও প্রক্রিয়া এক্সিকিউট (বা আরও বেশি traditionতিহ্যগতভাবে কাঁটাচামচ এবং তারপরে এক্সিকিউট) ব্যবহার করা হয়, পরবর্তী নতুন প্রক্রিয়াটি পিতামাতার মতো একই মেমরির পদক্ষেপের অধিকারী হয় এবং এটি সঙ্কুচিত হতে পারে না । যদি কোনও পিতামাতার প্রক্রিয়াটি 1/2 গিগ মেমরি বরাদ্দ করে এবং এক্সিকিউটিকে কল করার আগে এটিকে মুক্ত না করে, শিশু প্রক্রিয়া সেই একই 1/2 গিগ ব্যবহার শুরু করবে (যদিও এটি বরাদ্দ করা হয়নি)। এই আচরণটি সানটুলস (তাদের ডিফল্ট উইন্ডোটিং সিস্টেম) দ্বারা সর্বোত্তমভাবে প্রদর্শিত হয়েছিল, যা মেমরি হোগ। প্রতিটি অ্যাপ্লিকেশন এটি তৈরি করেছে তা কাঁটাচলা / এক্সিকিউটের মাধ্যমে তৈরি হয়েছিল এবং সানটুলস পাদদেশের উত্তরাধিকার সূত্রে পেয়েছিল, দ্রুত স্বাপের স্থানটি পূরণ করে।


2

এটি ইতিমধ্যে অ্যাড বমিভাব নিয়ে আলোচনা করা হয়েছিল । নীচের লাইনটি হ'ল মেমরি ফাঁস একটি বাগ এবং এটি অবশ্যই ঠিক করতে হবে। যদি কোনও তৃতীয় পক্ষের গ্রন্থাগার মেমরি ফাঁস করে দেয়, তবে এটির সাথে আরও কী ভুল হয়েছে তা ভাবতে উত্সাহিত করে, না? আপনি যদি একটি গাড়ী তৈরি করছিলেন, আপনি কি এমন একটি ইঞ্জিন ব্যবহার করবেন যা মাঝে মাঝে তেল ফাঁস হয়? সর্বোপরি, অন্য কেউ ইঞ্জিন তৈরি করেছে, তাই এটি আপনার দোষ নয় এবং আপনি এটি ঠিক করতে পারবেন না, তাই না?


তবে আপনার যদি এমন কোনও ইঞ্জিনযুক্ত গাড়ীর মালিকানা থাকে যা মাঝেমধ্যে তেল ফাঁস করে, আপনি কি এটি ঠিক করার জন্য অর্থ ব্যয় করেন, বা আপনি তেলের স্তরগুলিতে নজর রাখছেন এবং সময়ে সময়ে এটি শীর্ষে রেখেছেন? উত্তরটি সমস্ত ধরণের কারণের উপর নির্ভর করে।
পাতলা

এটি একটি গাড়ী মালিকানা সম্পর্কে নয়। এটি একটি গাড়ী নির্মাণ সম্পর্কে। যদি আপনি মেমরি ফাঁস সহ একটি তৃতীয় পক্ষের লাইব্রেরি পেয়ে থাকেন এবং আপনাকে একে একে একে একে ব্যবহার করতে হয় তবে আপনি এটির সাথেই থাকুন। তবে আপনি যদি কোনও সিস্টেম বা একটি গ্রন্থাগার লেখেন তবে এটি বাগ-মুক্ত কিনা তা নিশ্চিত করা আপনার দায়িত্ব।
ডিমা

+1 এটি অন্য কোনও বাগের মতো আচরণ করে। (তার মানে এই নয় "সঙ্গে সঙ্গে ফিক্স" নিশ্চিত "befixed প্রয়োজন" আছে আমার বই কিন্তু)
peterchen

2

সাধারণত স্ট্যান্ড একা অ্যাপ্লিকেশনটিতে একটি মেমরি ফাঁস মারাত্মক নয়, কারণ প্রোগ্রামটি প্রস্থান করার সময় এটি পরিষ্কার হয়ে যায়।

সার্ভার প্রোগ্রামগুলির জন্য আপনি কী করবেন যা ডিজাইন করা হয়েছে যাতে তারা প্রস্থান না করে?

আপনি যদি এমন ধরণের প্রোগ্রামার হন যে কোডটি ডিজাইন করে প্রয়োগ করে না যেখানে সংস্থানগুলি যথাযথভাবে বরাদ্দ করা হয় এবং সঠিকভাবে প্রকাশ করা হয় তবে আমি আপনার বা আপনার কোডের সাথে কিছু করতে চাই না। আপনি যদি আপনার ফাঁস হওয়া স্মৃতি পরিষ্কার করার চিন্তা না করেন তবে আপনার লকগুলির কী হবে? আপনি কি তাদেরও সেখানে ঝুলতে চান? আপনি অস্থায়ী ফাইলগুলির ছোট্ট টারডগুলি বিভিন্ন ডিরেক্টরিতে রেখে দেন?

সেই স্মৃতি ফাঁস করে দিন এবং প্রোগ্রামটি পরিষ্কার করতে দিন? না। এটি একটি খারাপ অভ্যাস, এটি বাগ, বাগ এবং আরও বেশি বাগের দিকে নিয়ে যায়।

নিজের পরে পরিষ্কার করুন। ইয়ো মা এখানে আর কাজ করবে না।


আমি সার্ভার প্রোগ্রামগুলিতে কাজ করেছি যা থ্রেডের পরিবর্তে ইচ্ছাকৃতভাবে প্রক্রিয়াগুলি ব্যবহার করে, যাতে মেমরি ফাঁস এবং বিভাগকরণের ত্রুটিগুলি সীমিত ক্ষতির কারণ হয়ে থাকে।
পাতলা

আকর্ষণীয় পদ্ধতির। আমি প্রসেসগুলি সম্পর্কে কিছুটা উদ্বিগ্ন হব যেগুলি প্রস্থান করতে ব্যর্থ হয় এবং স্মৃতিচারণ করতে থাকবে না।
এভিলটিচ

2

একটি সাধারণ নিয়ম হিসাবে, যদি আপনি মেমরি ফাঁস পেয়ে থাকেন যা আপনার মনে হয় যে আপনি এড়াতে পারবেন না, তবে আপনাকে অবজেক্টের মালিকানা সম্পর্কে আরও কঠোর চিন্তা করতে হবে।

তবে আপনার প্রশ্নের উত্তর, সংক্ষেপে আমার উত্তরটি হ'ল প্রডাকশন কোডে। উন্নয়নের সময়, না । এটি পিছনের দিকে মনে হতে পারে তবে আমার যুক্তিটি এখানে:

আপনি যে পরিস্থিতিতে বর্ণনা করেছেন, যেখানে প্রোগ্রামের শেষ হওয়া পর্যন্ত মেমরিটি রাখা হয়, এটি প্রকাশ না করা একেবারে ঠিক। আপনার প্রক্রিয়াটি শেষ হয়ে গেলে OS ও যাইহোক পরিষ্কার হয়ে যাবে। প্রকৃতপক্ষে, এটি ব্যবহারকারীর অভিজ্ঞতা আরও ভাল করে তুলতে পারে: আমি যে গেমটিতে কাজ করেছি, প্রোগ্রামাররা ভেবেছিলেন যে প্রস্থানটি বের হওয়ার আগে সমস্ত স্মৃতি মেমরি মুক্ত করা পরিষ্কার হবে, যার ফলে প্রোগ্রামটি বন্ধ হয়ে যাওয়ার জন্য আধ মিনিট সময় লাগবে! একটি দ্রুত পরিবর্তন যা কেবলমাত্র প্রস্থান () এর পরিবর্তে প্রক্রিয়াটি তত্ক্ষণাত্ অদৃশ্য হয়ে যায় এবং ব্যবহারকারীকে ডেস্কটপে ফিরিয়ে দেয় যেখানে সে হতে চায়।

তবে, আপনি ডিবাগিং সরঞ্জামগুলি সম্পর্কে ঠিক বলেছেন: এগুলি একটি ফিট নিক্ষেপ করবে এবং সমস্ত মিথ্যা ধনাত্মকতা আপনার আসল স্মৃতি খুঁজে পেতে ব্যথা করে। এবং তার কারণ হিসাবে, সর্বদা ডিবাগিং কোড লিখুন যা মেমরিটিকে মুক্ত করে, এবং যখন আপনি চালিত হন তখন এটি অক্ষম করে।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.