گنجه

مبنای بحث در این مطلب، زبان‌های C++‎ و C هستند، ولی مطالعهٔ آن برای برنامه‌نویسان هر زبانی که در معرض ایراد⁰های فساد حافظه¹ است و حتی هر برنامه‌نویسی، احتمالاً خالی از سود نخواهد بود.

برنامه‌ای نوشته‌اید که ایراد داره. اون رو حسابی آزموده‌اید و هر ایراد منطقی² رو که فکر می‌کنید ممکن هست وجود داشته باشه بررسی و رفع کرده‌اید، ولی هنوز برنامه ایراد داره!
برنامهٔ شما رفتارهای عجیبی از خودش نشون می‌ده. مثلاً اگر در حالت ایرادزدایی³ بسازیدش⁴ کار می‌کنه، ولی در حالت انتشار⁵ یا اشتباه کار می‌کنه، یا کار نمی‌کنه و دچار سانحه⁶ می‌شه. یا مثلاً با ورودی‌های مختلف، در جاهای کاملاً متفاوت و نسبتاً بی‌ربط از کد دچار سانحه می‌شه. یا مثلاً همیشه در پایان یک تابع⁷ بعد از همهٔ عملیات، ولی قبل از بازگشت (یعنی دقیقاً روی { !!!) دچار سانحه می‌شه.
در چنین شرایطی هست که شما حدس می‌زنید برنامه‌تون دچار ایراد فساد حافظه¹ شده.
اگر برنامه همیشه در یک تابع خاص دچار سانحه می‌شه، حدس می‌زنیم که در یکی از متغیرهای محلی همون تابع خراب‌کاری شده و پشته⁸ خراب شده؛ به همین دلیل در هنگام جمع کردن قاب پشتهٔ⁹ تابع از روی پشته، به علت فساد نشانی بازگشت¹⁰، برنامه دچار سانحه می‌شه¹¹.¹² معمولاً با خوندن دقیق همون تابع، ایراد یافت و حل می‌شه. اگر نشد، متغیرهای محلی که روی پشته هستند رو به کومه¹³ منتقل می‌کنیم (با استفاده از new یا malloc) و می‌ریم به سراغ روش‌های مربوط به فساد کومه که الان می‌خواهیم بگیم.
اولین قدم برای یافتن ایرادهای فساد حافظهٔ کومه، استمداد از حضرت Valgrind است (که در دبین¹⁴ بسته‌اش valgrind است)):

% valgrind --leak-check=full --leak-resolution=high ./buggy

برنامه با سرعتی بسیار کم‌تر از حد معمول اجرا می‌شه و هر دست‌رسی به حافظهٔ کومه که خارج از حافظهٔ تخصیص‌یافته¹⁵ باشه، با نام تابع و (در حالت ایرادزدایی) شمارهٔ خط کد منبع¹⁶ گزارش می‌شه. البته Valgrind بسیار جای حرف و معرفی و ستایش و غیره داره که از موضوع این مطلب خارجه!
اگر Valgrind مشکل رو یافت و ایراد رفع شد که خدا رو شکر می‌کنیم! اما اگر نه، با یک مورد بدخیم (!) طرف هستیم. یعنی دست‌رسی‌هایی داریم که به رغم ایراد داشتنشون، داخل حافظهٔ تخصیص‌یافته قرار گرفته‌اند. مثلاً دو آرایهٔ ۱۰۰تایی پشت سر هم در کومه گرفته‌ایم و به عنصر ۱۲۵ام از آرایهٔ اول دست زده‌ایم! دست‌رسی هنوز داخل حافظهٔ پردازهٔ¹⁷ خودمان است، ولی نادرست و ایراددار. اگر کسی تا این جای مطلب رو خونده باشه تعجب می‌کنم! البته کسی به جز خودم!
ان‌شاء الله در مطلب بعدی شیوه‌ای برای یافتن این موارد بدخیم معرفی خواهد شد که از یکی از هم‌کاران باتجربه‌ترم (حفظه الله) آموخته‌ام.

0. Bug [↩]
1. Memory corruption [↩] [↩]
2. Logical [↩]
3. Debug [↩]
4. Build [↩]
5. Release [↩]
6. Crash [↩]
7. Function [↩]
8. Stack [↩]
9. Stack frame [↩]
10. Return address [↩]
11. نوعی سرریز میان‌گیر (Buffer overflow) [↩]
12. البته این رفتار سانحه‌آمیز (!) بستگی به هم‌گردان داره، ولی هم‌گردان‌های جدید مثل GCCهای ۴ به بعد (و شاید بعضی قدیمی‌ترها)، به علت داشتن روش‌هایی برای مقابله با خرابی پشته، عمداً برنامه‌ای تولید می‌کنند که در این شرایط دچار سانحه بشه [↩]
13. Heap [↩]
14. Debian [↩]
15. Allocated [↩]
16. Source code [↩]
17. Process [↩]

متشکرم⁰:
از آقای سید ابراهیم رئیسی، معاون اول رییس قوهٔ قضاییه، برای جلوگیری شجاعانه از آزاد کردن شهرام جزایری (یا فراری دادنش¹)،
از کیهان و آقای حسین شریعت‌مداری، برای افشای فاجعهٔ مذکور²،
از بر و بچه‌های مرکز بررسی جرایم سازمان‌یافتهٔ سپاه پاسداران، برای پاک کردن اینترنت از لوث چند پایگاه عفت‌ستیز، حیاستیز و دین‌ستیز و دست‌گیری عواملشون.

0. فارغ از همهٔ سیاست‌بازی‌های رایج [↩]
1. اگر تکذیب آزاد کردنش راست باشه [↩]
2. در سرمقالهٔ کیهان در تاریخ ۱۳۸۸/۱/۲۲ [↩]

باخت اصلی، جست‌وجوی بُرد در زمین فوت‌بال است.

این مطلب در مورد زنده کردن لوح‌های سخت‌شدهٔ دل‌هامون به کمک موعظه یا چیزی شبیه اون نیست! (البته متأسفانه)

لوح سختی⁰ دارم که خراب شده بود. وقتی رایانه¹ رو روشن می‌کردم، هی سعی می‌کرد راه بیفته ولی موفق نمی‌شد و اصلاً دور بر نمی‌داشت². در نتیجه رایانه هم همون اول کار، توی مرحلهٔ شناسایی لوح‌های سخت، گیر می‌کرد و راه‌اندازی³ نمی‌شد. تقریباً ازش قطع امید کرده بودم.

طبق معمول قبل از هر گونه تصمیم‌گیری، سری به اینترنت زدم تا ببینم ملت در این باره چی گفته‌اند. بعد از کمی جست‌وجو، با راه‌کاری غیرمنتظره مواجه شدم: لوح سخت رو بگذارید تو یخ‌زن⁴! بله، گفته بودند که بعد از سرد کردن لوح سخت، باید بلافاصله اون رو به رایانه بزنید. اگر قسمت باشه⁵ چند دقیقه فرصت دارید تا داده‌های مهم‌ترتون رو بر دارید.

از اون جا که چیز زیادی برای از دست دادن نداشتم، و در ضمن از این جور انگولک‌کردن‌ها خوشم می‌آد، تصمیم گرفتم این کار رو بکنم. لوح سخت رو توی یک کیسه پیچیدم تا برفک نزنه و خیس نشه و بعد داخل یخ‌زن گذاشتم. بعد از چند ساعت که لوح سخت قصهٔ ما حسابی یخ زد، درش آوردم و سریع به رایانه وصلش کردم.

رایانه رو روشن کردم و در کمال ناباوری دیدم داره کار می‌کنه! با نرم‌افزار PowerMax آزمون سریع SMART⁶ رو انجام دادم و دیدم واقعاً سالمه⁷. با خودم گفتم شاید اگر در حالت خاموش گرم بشه، دوباره به همون روز بیفته. برای همین، رایانه رو خاموش نکردم و گذاشتم لوح سخت دائماً کار کنه تا در حال چرخش گرم بشه، باشد که سالم بمونه. نمی‌دونم کار این فکر بود یا نه، ولی هر چی بود جواب داد! برای این که مطمئن بشم که لوح سخت برای طولانی‌مدت سالم شده، رایانه رو خاموش کردم تا لوح کمی خنک بشه و بعد دوباره روشنش کردم. دوباره آزمودمش و دیدم که سالمه.

برای اطمینان از سلامت داده‌ها، از توی سامانهٔ عامل⁸، چند تا پرونده⁹ رو خوندم و بررسی کردم که شکر خدا سالم بودند.

سپاس خدای راست

0. Hard Disk [↩]
1. Computer [↩]
2. این‌ها رو با لمس کردن لوح سخت می‌شه فهمید [↩]
3. boot [↩]
4. Freezer [↩]
5. این تیکه‌اش رو اون‌ها این‌جوری نگفته بودند! [↩]
6. Self-Monitoring, Analysis and Reporting Technology [↩]
7. کلیدواژه‌ها رو برای خنده نمی‌دم! برای این می‌دم که بتونی باهاش جست‌وجو کنی [↩]
8. Operating System [↩]
9. File [↩]