گنجه

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

یکی از روش‌های نسبتاً متفاوت هم‌گردان⁰ها برای بهینه‌سازی¹، روش «بهینه‌سازی هدایت‌شده با سابقه»² است که گاهی اون رو کوتاهانه³ 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 [↩]

با پرهیز از Java و ‎.NET (در مقابل C++‎ و C) در روند گرمایش زمین سهم کم‌تری داشته باشیم.