مبنای بحث در این مطلب، زبان‌های 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

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

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

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

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

رایانه رو روشن کردم و در کمال ناباوری دیدم داره کار می‌کنه! با نرم‌افزار 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

یکی از روش‌های نسبتاً متفاوت هم‌گردان⁰ها برای بهینه‌سازی¹، روش «بهینه‌سازی هدایت‌شده با سابقه»² است که گاهی اون رو کوتاهانه³ PGO هم می‌گویند.

مؤثر بودن این روش رو می‌شه به چشم دید. مثلاً اگر از مرورگر Firefox هم در لینوکس⁴ و هم در ویندوز⁵ استفاده کرده باشید، حتماً تفاوت فاحش کارآیی⁶ رو حس کرده‌اید. دلیل این تفاوت فاحش، استفاده از PGO در ساخت⁷ پروندهٔ⁸ اجرایی⁹ ویندوز و عدم استفاده ازش در ساخت اجرایی لینوکس بیان شده.

خوب، حالا که به اندازهٔ کافی انگیزوندمتون (!)، ببینیم این روش اصلاً چی هست و چه‌جوری می‌تونیم ازش استفاده کنیم.

اساس این روش، استفاده از اطلاعات کسب‌شده در زمان اجرا¹⁰ی برنامه، برای بهینه‌سازی در زمان هم‌گردانی¹¹ هست. پس هم‌گردانی با این روش، سه مرحله خواهد داشت:

۱. هم‌گردانی برای تولید اجرایی مخصوص جمع‌آوری اطلاعات مورد نیاز برای بهینه‌سازی
۲. اجرای برنامهٔ تولیدشده در مرحلهٔ ۱ و استفاده از موارد کاربرد¹² مورد نظر برای بهینه‌سازی
۳. هم‌گردانی با بهینه‌سازی به کمک اطلاعات جمع‌آوری‌شده در مرحلهٔ ۲

هم‌گردان‌ها برای مراحل ۱ و ۳ گزینه‌های مخصوصی دارند که این‌جا فقط GCC رو می‌بینیم.

درGCC برای مرحلهٔ ۱ از گزینهٔ ‎-fprofile-generate و برای مرحلهٔ ۳ از گزینهٔ ‎-fprofile-use استفاده می‌کنیم. دقت کنید که گزینهٔ ‎-fprofile-generate رو هم باید برای هم‌گردانی¹³ بدید، و هم برای پیوند¹⁴.

من که معمولاً از CMake به عنوان سامانهٔ ساخت¹⁵ استفاده می‌کنم، برای به کارگیری این روش، این چند خط رو به CMakeLists.txt اضافه می‌کنم:

# profile::generate
#set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} --profile-generate")
#set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} --profile-generate")
#set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} --profile-generate")
# profile::use
#set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} --profile-use")
#set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} --profile-use")
#set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} --profile-use")

برای مرحلهٔ ۱، سه تا set اول و برای مرحلهٔ ۳، سه تا set دوم رو فعال می‌کنم. راستی دقت کردید که به جای ‎-fprofile-folan می‌شه از ‎-profile-folan- استفاده کرد؟!

0. Compiler
1. Optimization
2. Profile-Guided Optimization
3. به یاد استاد روحانی رانکوهی!
4. Linux
5. Windows
6. Performance
7. Build
8. File
9. Executable
10. Run-time
11. Compile-time
12. Use case
13. Compiling
14. Linking
15. Build System

دبیَن⁰ سامانهٔ عامل¹ محبوب من هست.

موج زدن روح آزادی نرم‌افزار رو توی دبین حس می‌کنم.

بخش عظیمی از همهٔ نرم‌افزارهای آزاد دنیا رو می‌شه توی مخزن²های دبین، آمادهٔ نصب پیدا کرد؛ الان حدود ۲۰۰۰۰ تا بسته³ در مخازن رسمی⁴ هست.

سامانهٔ مدیریت بسته‌هاش⁵، به نام APT (مخفف «ابزار بسته‌بندی پیش‌رفته»⁶)، بسیار تمیز و خوش‌دست هست.

اگر سامانه‌ای حقیقتاً پایدار⁷ بخوام، دبین stable رو نصب می‌کنم. اگر پایداری برام کم‌تر از به‌روز⁸ بودن نرم‌افزارها مهم باشه (مثلاً برای رایانهٔ منزل)، دبین unstable + experimental رو نصب می‌کنم. اگر روی سامانهٔ پایدارم آخرین نسخهٔ بسته‌های خاصی رو بخوام هم به سادگی می‌تونم بسته‌های deb رو جدا بگیرم و نصب کنم، یا با تنظیم ‎/etc/apt/preferences کار رو به دست استاد APT بسپارم (به man apt_preferences مراجعه کنید).

قبل از این که خبر انتشار KDE 4.2 توی پایگاه رسمی KDE اعلام بشه، بسته‌های KDE 4.2 توی مخزن دبین experimental بود و داشتم نصبش می‌کردم!

نرم‌افزارهای دوست‌داشتنی‌ای مثل VirtualBox رو که هم ویرایش آزاد دارند، و هم ویرایش غیرآزاد، و البته گاهی در پایگاه⁹ رسمیشون ایران عزیز رو تحریم کرده‌اند، از مخازن دبین به راحتی نصب می‌کنم بدون این که نگران تحریم و یا آلوده شدن رایانه‌ام به نسخهٔ غیرآزادشون باشم. همهٔ نرم‌افزارهای بخش¹⁰ main، آزاد هستند و به هیچ نرم‌افزار غیرآزادی وابستگی¹¹ ندارند.

بعضی نرم‌افزارهای غیرآزاد مثل افزونهٔ¹² Flash، که ناچار از استفاده‌شون هستم رو می‌تونم بدون به هم زدن یک‌پارچگی سامانه‌ام نصب کنم. بخش‌های contrib و non-free حاوی بعضی از نرم‌افزارهای غیرآزاد پراستفاده هستند.

یادم نره بگم که دبین برای تعداد زیادی معماری¹³ مختلف رایانه وجود داره. از x86 و AMD64 بگیر تا MIPS و ARM و PowerPC و SPARC و Alpha و … (برای فهرست کاملش http://www.debian.org/ports/‎ رو ببینید)

با دبین به هستهٔ لینوکس¹⁴ محدود نیستم؛ می‌شه دبین رو با هستهٔ¹⁵ FreeBSD¹⁶ یا NetBSD¹⁷ یا Hurd¹⁸ یا OpenSolaris¹⁹ یا حتی²⁰ Darwin/XNU (هستهٔ Mac OS X) استفاده کرد! شما رو نمی‌دونم، ولی این برای من خیلی مهم و هم‌چنین خیلی هیجان‌انگیزه! مثلاً به این فکر کنید که می‌تونید توی محیط آشنا و دوست‌داشتنی دبین، به کامل‌ترین پیاده‌سازی سامانهٔ پروندهٔ²¹ قدرت‌مند ZFS که توی OpenSolaris هست دست‌رسی داشته باشید.

راستی یادمون نره که اوبونتو²² بچهٔ دبین هست.

این‌جوری‌هاست که بهش می‌گم حضرت دبین!

0. Debian
1. Operating System
2. Repository
3. Package
4. Official
5. Package Management
6. Advanced Packaging Tool
7. Stable
8. Up-to-date
9. Site
10. Section
11. Dependency
12. Plugin
13. Architecture
14. Linux
15. Kernel
16. Debian GNU/kFreeBSD
17. Debian GNU/NetBSD
18. Debian GNU/Hurd
19. Nexenta
20. GNU-Darwin
21. File System
22. Ubuntu

با این افزونهٔ Firefox می‌شه در طرف مخدوم²، به هر صفحه‌ای کدهای JavaScript دل‌خواه رو اضافه کرد. علاوه بر کلی دست‌نوشتهٔ³ آماده که توی http://userscripts.org براش وجود داره، خودمون هم می‌تونیم به راحتی براش دست‌نوشته بنویسیم. حالا اگر قدرت JavaScript رو بیاری تو ذهنت می‌بینی که چه کارها می‌شه به کمک این میمون چرب (!) کرد.

برای شروع ماجراجویی، کمی از http://diveintogreasemonkey.org رو خوندم. نقطهٔ شروع بسیار خوبی بود.

یک دست‌نوشته به نام فارسنده یا Persianizer که به شیوهٔ بِکَن-بچسبون⁴ ساخته‌ام، همهٔ رقم‌های انگلیسی و «ي» و «ك»های عربی توی صفحهٔ بارگذاری شده رو به معادل فارسیشون تبدیل می‌کنه. بس که اون صفحه‌های فارسی پر از «ي» حالم رو بد می‌کنه! فقط موقع استفاده حواست باشه پایگاه‌هایی که قراره فارسنده روشون کار بکنه رو خوب انتخاب کنی؛ پیش‌فرض‌هاش خوب نیستند.

البته یکی از شرایط من (و خیلی‌های دیگر) برای استفاده از یک فن‌آوری، انحصاری نبودنش هست که خوش‌بختانه افزونه‌هایی سازگار با Greasemonkey برای مرورگرهای مهم دیگه (از جمله Konqueror) هم وجود داره.

نکتهٔ پایانی این که اگر کاربر Greasemonkey باشی، افزونهٔ Greasefire هم احتمالاً برات جالب هست.

این هم فهرست دست‌نوشته‌های محبوب من:
http://userscripts.org/users/73214/favorites

1. Web
2. Client Side
3. Script
4. Copy-Paste

اگر برنامه‌نویس C++‎ باشی، حتماً تا حالا مورد آزار و اذیت پیغام‌های خطای سرسام‌آور هم‌گردان⁰ در مورد STL قرار گرفته‌ای. مثلاً این:

testmm2.cpp:31: error: no matching function for call to ‘std::multimap<int*, int, std::less<int*>, std::allocator<std::pair<int* const, int> > >::insert(int)’
/usr/include/c++/4.3/bits/stl_multimap.h:407: note: candidates are: typename std::_Rb_tree<_Key, std::pair<const _Key, _Tp>, std::_Select1st<std::pair<const_Key, _Tp> >, _Compare, typename _Alloc::rebind<std::pair<const _Key, _Tp> >::other>::iterator std::multimap<_Key, _Tp, _Compare, _Alloc>::insert(const std::pair<const _Key, _Tp>&) [with _Key = int*, _Tp = int, _Compare = std::less<int*>, _Alloc = std::allocator<std::pair<int* const, int> >]
/usr/include/c++/4.3/bits/stl_multimap.h:431: note:                 typename std::_Rb_tree<_Key, std::pair<const _Key, _Tp>, std::_Select1st<std::pair<const _Key, _Tp> >, _Compare, typename _Alloc::rebind<std::pair<const _Key, _Tp> >::other>::iterator std::multimap<_Key, _Tp, _Compare, _Alloc>::insert(typename std::_Rb_tree<_Key, std::pair<const _Key, _Tp>, std::_Select1st<std::pair<const _Key, _Tp> >, _Compare, typename _Alloc::rebind<std::pair<const _Key, _Tp> >::other>::iterator, const std::pair<const _Key, _Tp>&) [with _Key = int*, _Tp = int, _Compare = std::less<int*>, _Alloc = std::allocator<std::pair<int* const, int> >]

‎
حالا این یکی بود. وقتی ده-پونزده تا از این‌ها یک‌جا رخ می‌ده، خیلی افتضاح می‌شه.

مدت‌ها با این مشکل کنار اومده بودم و دردش رو تحمل می‌کردم. اما اخیراً یک راه نجات یافتم: ابزاری به نام STLFilt. یک نرم‌افزار آزاد هست که خروجی هم‌گردان C++‎ رو می‌گیره و اون پیغام‌های وحشت‌ناک رو مهربون می‌کنه. مثلاً پیغام بالا رو تبدیل می‌کنه به این:

testmm2.cpp:31: error: No match for ‘multimap<int *, int>::insert(int)’
stl_multimap.h:407: candidates are: map<int *, int>::iter multimap<int *, int>
    ::insert(const pair<const int *, int> &)
stl_multimap.h:431: map<
        int *, int
    >::iter multimap<
        int *, int
    >::insert(map<int *, int>::iter, const pair<const int *, int> &)

آخش! حالا می‌شه خوندش!

برای استفاده از STLFilt اول باید بستهٔ مربوط به هم‌گردانت رو بگیری. مثلاً gstlfilt.zip برای G++‎. توش کلی پرونده هست که همه رو بی‌خیال می‌شی به جز gSTLFilt.pl که اصل کار رو انجام می‌ده. از stdin می‌خونه و توی stdout می‌نویسه. کاری که من کردم این بود¹:

sudo su
F=/usr/local/bin/stlfilt.pl
echo '#!/usr/bin/perl' >$F
cat gSTLFilt.pl >>$F
chmod +x $F

و برای استفاده:

make 2>&1 | stlfilt.pl

برای این که هر بار نخوام stderr دستور ساخت² (مثلاً make) رو به stdoutش redirect³ کنم، دست‌نوشتهٔ⁴ /usr/local/bin/stlfilt رو با این محتوا ساختم:

#!/bin/sh
"$@" 2>&1 | stlfilt.pl

و chmod +x هم یادم نره.
حالا این‌جوری استفاده می‌شه:

stlfilt make

با دست‌نوشته‌ها زندگی زیباتره!

ویرایش: امید آن می‌رود که با معرفی «مفهوم»⁵ها در C++0x (به زودی!) کل مشکل از بیخ حل بشه و دیگه نیازی به ابزار اضافی نباشه.

0. Compiler
1. مثل همیشه نقل به مضمون و آزمایش‌نشده
2. Build
3. معادل خوبی براش داری بگو
4. Script
5. Concept