| VALGRIND(1) | دستورات عمومی کاربر | VALGRIND(1) |
نام (NAME)
valgrind - مجموعهای از ابزارها برای اشکالزدایی و تحلیل کارایی برنامهها
خلاصه دستور (SYNOPSIS)
valgrind [valgrind-options] [your-program] [your-program-options]
توضیحات (DESCRIPTION)
Valgrind برنامهای انعطافپذیر برای اشکالزدایی و تحلیل کارایی (پروفایلینگ) فایلهای اجرایی لینوکس است. این برنامه از یک هسته، که یک پردازنده شبیهسازیشده نرمافزاری ارائه میدهد، و مجموعهای از ابزارهای اشکالزدایی و تحلیل کارایی تشکیل شده است. معماری آن ماژولار است، به طوری که ابزارهای جدید میتوانند به سادگی و بدون برهم زدن ساختار موجود ایجاد شوند.
برخی از گزینههای شرح دادهشده در ادامه با تمام ابزارهای والگریند کار میکنند و برخی دیگر تنها با چند ابزار یا یک ابزار خاص کارایی دارند. بخش «گزینههای ممچک (MEMCHECK OPTIONS)» و بخشهای پس از آن، گزینههای مختص هر ابزار را توضیح میدهند.
این صفحه راهنما تنها نحوه استفاده و گزینههای پایه را پوشش میدهد. برای اطلاعات جامعتر، لطفاً مستندات HTML موجود بر روی سیستم خود را در $INSTALL/share/doc/valgrind/html/index.html یا به صورت برخط در http://www.valgrind.org/docs/manual/index.html مشاهده کنید.
گزینههای انتخاب ابزار (TOOL SELECTION OPTIONS)
مهمترین گزینه منفرد.
--tool=<toolname> [default: memcheck]
گزینههای پایه (BASIC OPTIONS)
این گزینهها با تمام ابزارها کار میکنند.
-h --help
--help-debug
--version
-q, --quiet
-v, --verbose
--trace-children=<yes|no> [default: no]
توجه داشته باشید که والگریند پردازش فرزند ناشی از fork را ردگیری میکند (انجام ندادن آن دشوار خواهد بود، چرا که fork یک کپی همسان از پردازش میسازد)، بنابراین نامگذاری این گزینه شاید چندان دقیق نباشد. با این حال، اکثر فرزندان فراخوانیهای fork بلافاصله فراخوانی exec را اجرا میکنند.
--trace-children-skip=patt1,patt2,...
این امر میتواند برای هرس کردن شاخههای نامربوط از درخت پردازشهای در حال اجرا بر روی والگریند مفید باشد. اما هنگام استفاده از آن باید احتیاط کنید. وقتی والگریند از ردگیری به درون یک فایل اجرایی صرفنظر میکند، نهتنها از ردگیری آن فایل اجرایی، بلکه از ردگیری تمامی پردازشهای فرزند آن فایل اجرایی نیز صرفنظر میکند. به عبارت دیگر، این فلگ صرفاً مانع توقف ردگیری در فایلهای اجرایی مشخصشده نمیشود -- بلکه از ردگیری کل زیردرختهای پردازش که ریشه در هر یک از فایلهای اجرایی مشخصشده دارند، صرفنظر میکند.
--trace-children-skip-by-arg=patt1,patt2,...
--child-silent-after-fork=<yes|no> [default: no]
--vgdb=<no|yes|full> [default: yes]
اگر gdbserver داخلی فعال باشد اما در حال حاضر هیچ gdbای مورد استفاده قرار نگرفته باشد، ابزار خط فرمان vgdb میتواند «دستورات نظارتی» (monitor commands) را از یک شل به والگریند ارسال کند. هسته والگریند مجموعهای از دستورات نظارتی والگریند را ارائه میدهد. یک ابزار میتواند بهطور اختیاری دستورات نظارتی ویژه آن ابزار را ارائه دهد که در فصل مربوط به ابزار مستند شدهاند.
--vgdb-error=<number> [default: 999999999]
--vgdb-stop-at=<set> [default: none]
مقادیر startup exit valgrindabexit به ترتیب نشاندهنده فراخوانی gdbserver پیش از اجرای برنامه، پس از آخرین دستورالعمل برنامه، و هنگام خروج غیرعادی والگریند (مانند خطای داخلی، اتمام حافظه، و غیره) هستند.
گزینه abexit مشابه exit است، اما تعیین میکند که gdbserver تنها زمانی فراخوانی شود که برنامه شما به طور غیرعادی خارج شود (یعنی با کد خروجی غیر از صفر).
نکته: startup و --vgdb-error=0 هر دو باعث میشوند سرور gdb والگریند پیش از اجرای برنامه شما فراخوانی شود. گزینه --vgdb-error=0 علاوه بر این باعث میشود برنامه شما روی تمامی خطاهای بعدی متوقف گردد.
--track-fds=<yes|no|all> [default: no]
--modify-fds=<no|high> [default: no]
--time-stamp=<yes|no> [default: no]
--log-fd=<number> [default: 2, stderr]
--log-file=<filename>
%p با شناسه پردازش فعلی (PID) جایگزین میشود. این برای برنامههایی که چندین پردازش را فراخوانی میکنند بسیار مفید است. هشدار: اگر از --trace-children=yes استفاده میکنید و برنامه شما چندین پردازش را فراخوانی میکند، یا برنامه شما فرآیند fork انجام میدهد بدون اینکه پس از آن exec را فراخوانی کند، و شما از این مشخصهکننده (یا مشخصهکننده %q در زیر) استفاده نکنید، خروجی والگریند از تمام آن پردازشها به یک فایل ریخته میشود که احتمالاً درهمریخته و ناقص خواهد بود. نکته: اگر برنامه fork کند و پس از آن exec را فراخوانی کند، خروجی والگریند برای فرزند در بازه زمانی بین fork و exec از دست خواهد رفت. خوشبختانه این شکاف برای اکثر برنامهها بسیار ناچیز است؛ و برنامههای امروزی در هر صورت از posix_spawn استفاده میکنند.
%n با یک شماره ترتیبی فایل که برای این پردازش یکتا است جایگزین میشود. این برای پردازشهایی مفید است که چندین فایل از یک الگوی نام فایل یکسان تولید میکنند.
%q{FOO} با محتوای متغیر محیطی FOO جایگزین میشود. اگر بخش {FOO} نادرست باشد، باعث لغو اجرا میشود. این مشخصهکننده به ندرت مورد نیاز است، اما در شرایط خاص (مثلاً هنگام اجرای برنامههای MPI) بسیار کاربردی است. ایده این است که متغیری را مشخص کنید که برای هر پردازش در کار مقدار متفاوتی داشته باشد، برای مثال BPROC_RANK یا هر متغیر دیگری که در پیکربندی MPI شما صدق میکند. اگر متغیر محیطی نامبرده تنظیم نشده باشد، باعث لغو اجرا میشود. توجه داشته باشید که در برخی شلها، ممکن است نیاز باشد نویسههای { و } با یک بکاسلش اسکیپ شوند.
%% با % جایگزین میشود.
اگر به دنبال % هر نویسه دیگری بیاید، باعث لغو اجرا خواهد شد.
اگر نام فایل یک نام فایل نسبی باشد، در دایرکتوری کاری اولیه برنامه قرار میگیرد: این دایرکتوری جاری در لحظه شروع اجرای برنامه پس از fork یا exec است. اگر یک نام فایل مطلق را مشخص کند (یعنی با '/' شروع شود)، در همان مسیر قرار میگیرد.
--log-socket=<ip-address:port-number>
--enable-debuginfod=<no|yes> [default: yes]
گزینههای مرتبط با خطا (ERROR-RELATED OPTIONS)
این گزینهها توسط تمام ابزارهایی که میتوانند خطاها را گزارش کنند، مانند Memcheck (و نه Cachegrind)، استفاده میشوند.
--xml=<yes|no> [default: no]
پیامهای کماهمیتتر همچنان به صورت متن ساده چاپ میشوند، اما از آنجا که خروجی XML و خروجی متن ساده به کانالهای خروجی متفاوتی ارسال میشوند (مقصد خروجی متن ساده همچنان توسط --log-fd، --log-file و --log-socket) کنترل میشود) این موضوع نباید مشکلی ایجاد کند.
هدف این گزینه آسانتر کردن کار برای ابزارهایی است که خروجی والگریند را به عنوان ورودی مصرف میکنند، مانند رابطهای کاربری گرافیکی (GUI). در حال حاضر این گزینه با Memcheck، Helgrind و DRD کار میکند. قالب خروجی در فایل docs/internals/xml-output-protocol4.txt در درخت کد منبع برای Valgrind 3.5.0 یا بالاتر مشخص شده است.
گزینههای پیشنهادی برای ارسال توسط یک رابط گرافیکی (GUI)، هنگام درخواست خروجی XML، عبارتند از: --xml=yes برای فعال کردن خروجی XML، --xml-file برای ارسال خروجی XML به یک فایل (احتمالاً انتخابشده توسط GUI)، --log-file برای ارسال خروجی متن ساده به فایل دوم انتخابشده توسط GUI، --child-silent-after-fork=yes، و -q برای محدود کردن خروجی متن ساده به پیامهای خطای بحرانی ایجادشده توسط خود والگریند. برای مثال، ناتوانی در خواندن یک فایل سرکوب (suppressions) مشخصشده یک پیام خطای بحرانی محسوب میشود. بدین ترتیب، برای یک اجرای موفق، فایل خروجی متنی خالی خواهد بود؛ اما اگر خالی نباشد، حاوی اطلاعات مهمی است که کاربر رابط گرافیکی باید از آن آگاه شود.
--xml-fd=<number> [default: -1, disabled]
--xml-file=<filename>
--xml-socket=<ip-address:port-number>
--xml-user-comment=<string>
--demangle=<yes|no> [default: yes]
یک نکته مهم درباره رمزگشایی نامها این است که نام توابع ذکرشده در فایلهای سرکوب باید به شکل تغییرنامیافته (mangled) باشند. والگریند هنگام جستجو برای سرکوبهای قابلاعمال، نام توابع را رمزگشایی نمیکند، زیرا در غیر این صورت محتوای فایل سرکوب به وضعیت سازوکار رمزگشایی والگریند وابسته شده و همچنین سرعت تطبیق سرکوبها کاهش مییابد.
--num-callers=<number> [default: 12]
حداکثر مقدار برای این گزینه ۵۰۰ است. توجه داشته باشید که مقادیر بالاتر باعث میشوند والگریند کمی کندتر اجرا شود و حافظه کمی بیشتری مصرف کند، اما هنگام کار با برنامههایی با زنجیرههای فراخوانی عمیقاً تو در تو میتواند مفید باشد.
--unw-stack-scan-thresh=<number> [default: 0] , --unw-stack-scan-frames=<number> [default: 5]
این گزینهها باز کردن پشته (stack unwinding) از طریق پیمایش پشته را فعال و کنترل میکنند. هنگامی که سازوکارهای عادی باز کردن پشته -- استفاده از رکوردهای Dwarf CFI و دنبال کردن اشارهگر فریم (frame-pointer) -- با شکست مواجه شوند، پیمایش پشته ممکن است بتواند ردگیری پشته را بازیابی کند.
توجه داشته باشید که پیمایش پشته یک سازوکار تقریبی و اکتشافی است که ممکن است نتایج بسیار گمراهکننده یا حتی هیچ نتیجهای ارائه ندهد. این ویژگی تنها باید در شرایط اضطراری استفاده شود؛ یعنی زمانی که باز کردن عادی پشته شکست میخورد اما داشتن ردگیری پشته با این وجود حائز اهمیت است.
پیمایش پشته یک روش ساده است: بخش بازکننده پشته، کلمات (words) را از پشته میخواند و سعی میکند با بررسی اینکه آیا آنها دقیقاً به بعد از دستورالعملهای فراخوانی ARM یا Thumb اشاره دارند یا خیر، حدس بزند کدامیک ممکن است نشانی بازگشت باشند. در صورت تطابق، آن کلمه به ردگیری برگشتی (backtrace) اضافه میشود.
خطر اصلی زمانی رخ میدهد که یک فراخوانی تابع بازمیگردد و نشانی بازگشت آن بر روی پشته باقی میماند، سپس تابع جدیدی فراخوانی میشود اما تابع جدید نشانی قدیمی را بازنویسی نمیکند. نتیجه این است که ردگیری برگشتی ممکن است حاوی مدخلهایی برای توابعی باشد که قبلاً بازگشتهاند و بنابراین بسیار گیجکننده باشد.
محدودیت دوم این پیادهسازی این است که تنها صفحهای (معمولاً ۴ کیلوبایت) را که شامل اشارهگر پشته اولیه است پیمایش میکند. اگر فریمهای پشته بزرگ باشند، ممکن است تنها تعداد انگشتشماری (یا حتی هیچ مدخلی) در ردگیری حاضر باشند. همچنین، اگر بدشانس باشید و اشارهگر پشته اولیه نزدیک انتهای صفحه حاوی آن باشد، ممکن است پیمایش تمام فریمهای مهم را از دست بدهد.
به طور پیشفرض، پیمایش پشته غیرفعال است. کاربرد عادی آن این است که وقتی یک ردگیری پشته در حالت عادی بسیار کوتاه میشود، آن را درخواست کنید. بنابراین برای فعالسازی آن، از --unw-stack-scan-thresh=number استفاده کنید. این درخواست از والگریند میخواهد تا از پیمایش پشته برای «گسترش» ردگیریهای پشتهای که کمتر از number فریم دارند، استفاده کند.
اگر پیمایش پشته انجام شود، حداکثر به تعداد فریمهای مشخصشده توسط --unw-stack-scan-frames تولید خواهد کرد. معمولاً پیمایش پشته آنچنان مدخلهای بیهودهای تولید میکند که این مقدار به طور پیشفرض روی مقدار پایینی (۵) تنظیم شده است. در هیچ حالتی ردگیری پشتهای بزرگتر از مقدار مشخصشده توسط --num-callers ایجاد نخواهد شد.
--error-limit=<yes|no> [default: yes]
--error-exitcode=<number> [default: 0]
--exit-on-first-error=<yes|no> [default: no]
--error-markers=<begin>,<end> [default: none]
چنین خطوط نشانهگذاری، جستجو برای خطاها و/یا استخراج خطاها را در یک فایل خروجی که حاوی خطاهای والگریند آمیخته با خروجی برنامه است، تسهیل میکنند.
توجه داشته باشید که نشانهگذارهای خالی نیز پذیرفته میشوند. بنابراین، استفاده از تنها یک نشانهگذار شروع (یا پایان) امکانپذیر است.
--show-error-list=no|yes|all [default: no]
توجه داشته باشید که در سطح پرگویی (verbosity) ۲ و بالاتر، والگریند به طور خودکار فهرست خطاهای شناساییشده و فهرست سرکوبهای استفادهشده را در هنگام خروج نمایش میدهد، مگر اینکه --show-error-list=no انتخاب شده باشد.
-s
--sigill-diagnostics=<yes|no> [default: yes]
در صورت فعال بودن، هر زمان که دستورالعملی مشاهده شود که والگریند قادر به رمزگشایی یا ترجمه آن نیست، پیش از ارسال سیگنال SIGILL به برنامه، یک پیام هشدار همراه با برخی اطلاعات عیبیابی چاپ میشود. اغلب یک دستورالعمل غیرمجاز نشاندهنده یک باگ در برنامه یا عدم پشتیبانی والگریند از آن دستورالعمل خاص است. اما برخی برنامهها عمداً تلاش میکنند دستورالعملی را اجرا کنند که ممکن است پشتیبانی نشود و سیگنال SIGILL را دریافت (trap) کنند تا قابلیتهای پردازنده را شناسایی نمایند. استفاده از این گزینه اجتناب از خروجیهای عیبیابی را که در چنین مواردی دریافت میکردید، ممکن میسازد.
--keep-debuginfo=<yes|no> [default: no]
برخی ابزارها و برخی قابلیتها پشتیبانی محدودی از اطلاعات اشکالزدایی آرشیوشده دارند. ابزار Memcheck به طور کامل از آن پشتیبانی میکند. به طور کلی، ابزارهایی که خطاها را گزارش میدهند میتوانند از اطلاعات اشکالزدایی آرشیوشده برای نمایش ردگیریهای پشته خطا استفاده کنند. محدودیتهای شناختهشده عبارتند از: ردگیری پشته دسترسی قبلی به شرایط مسابقه (race condition) در Helgrind از اطلاعات اشکالزدایی آرشیوشده استفاده نمیکند. ابزار Massif (و به طور کلیتر قالب خروجی xtree Massif) از اطلاعات اشکالزدایی آرشیوشده استفاده نمیکند. تنها Memcheck تا حدی با --keep-debuginfo=yes آزمایش شده است، بنابراین سایر ابزارها ممکن است محدودیتهای ناشناختهای داشته باشند.
--show-below-main=<yes|no> [default: no]
در صورت فعال بودن این گزینه، تمام مدخلهای ردگیری پشته نمایش داده خواهند شد و توابع شبه main نرمالسازی نمیشوند.
--fullpath-after=<string> [default: don't show source paths]
به عنوان مثال، فایلی به نام /home/janedoe/blah/src/foo/bar/xyzzy.c را در نظر بگیرید. تعیین --fullpath-after=/home/janedoe/blah/src/ باعث میشود والگریند نام را به صورت foo/bar/xyzzy.c نمایش دهد.
از آنجا که الزامی نیست رشته یک پیشوند باشد، گزینه --fullpath-after=src/ همان خروجی را تولید خواهد کرد. این ویژگی زمانی مفید است که مسیر حاوی کاراکترهای دلخواه تولیدشده توسط ماشین باشد. برای مثال، مسیر /my/build/dir/C32A1B47/blah/src/foo/xyzzy میتواند با استفاده از --fullpath-after=/blah/src/ به foo/xyzzy کوتاه شود.
اگر صرفاً میخواهید مسیر کامل را مشاهده کنید، کافی است یک رشته خالی تعیین کنید: --fullpath-after=. این یک حالت خاص نیست، بلکه صرفاً یک پیامد منطقی از قوانین فوق است.
در نهایت، شما میتوانید از --fullpath-after چندین بار استفاده کنید. هر بار استفاده از آن باعث میشود والگریند به حالت تولید مسیرهای کامل سوییچ کرده و قانون پالایش فوق را اعمال کند. هر مسیر تولیدشده با تمام رشتههای مشخصشده توسط --fullpath-after، به ترتیبی که تعیین شدهاند، مقایسه میشود. اولین رشتهای که مطابقت داشته باشد، باعث کوتاه شدن مسیر به روش شرحدادهشده در بالا میشود. اگر هیچکدام مطابقت نداشته باشند، مسیر کامل نمایش داده میشود. این کار حذف پیشوندها را در مواردی که منابع از چندین دایرکتوری نامرتبط گرفته شدهاند تسهیل میکند.
--extra-debuginfo-path=<path> [default: undefined and unused]
با این حال، ممکن است سناریوهایی وجود داشته باشد که در آنها مایل باشید اشیاء اشکالزدایی را در مکانی دلخواه قرار دهید، مانند یک حافظه خارجی هنگام اجرای والگریند بر روی دستگاه همراه با حافظه محلی محدود. مثال دیگر میتواند وضعیتی باشد که در آن مجوز نصب بستههای اشیاء اشکالزدایی را بر روی سیستمی که والگریند را روی آن اجرا میکنید ندارید.
در این سناریوها، میتوانید با مشخص کردن --extra-debuginfo-path=/path/to/debug/objects یک مسیر مطلق را به عنوان مکانی اضافی و نهایی برای جستجوی اشیاء اشکالزدایی توسط والگریند ارائه دهید. مسیر ارائهشده به ابتدای نام مسیر مطلق شیء مورد جستجو الحاق خواهد شد. به عنوان مثال، اگر والگریند به دنبال اطلاعات اشکالزدایی برای /w/x/y/zz.so باشد و --extra-debuginfo-path=/a/b/c مشخص شده باشد، در مسیر /a/b/c/w/x/y/zz.so به دنبال شیء اشکالزدایی خواهد گشت.
این گزینه تنها باید یک بار مشخص شود. اگر چندین بار مشخص شود، تنها آخرین مورد اعمال خواهد شد.
--debuginfo-server=ipaddr:port [default: undefined and unused]
در برخی سناریوها ممکن است خواندن اطلاعات اشکالزدایی از اشیاء ذخیرهشده در یک ماشین دیگر راحتتر باشد. با این گزینه، والگریند در صورتی که نتواند شیء اشکالزدایی را در سامانه فایل محلی پیدا کند، از یک کارساز (سرور) debuginfo که روی ipaddr اجرا میشود و به درگاه port گوش میدهد، استعلام خواهد کرد.
کارساز debuginfo باید اتصالات TCP را روی درگاه port بپذیرد. کارساز debuginfo در فایل منبع auxprogs/valgrind-di-server.c قرار دارد. این برنامه تنها فایلها را از دایرکتوریای که در آن اجرا شده است ارائه میدهد. در صورت عدم تعیین، درگاه port هم در کلاینت و هم در سرور به طور پیشفرض ۱۵۰۰ است.
اگر والگریند با استفاده از کارساز debuginfo به دنبال اطلاعات اشکالزدایی برای /w/x/y/zz.so بگردد، بخشهای مسیر فایل را حذف کرده و صرفاً zz.so را از سرور درخواست میکند. سرور نیز به نوبه خود تنها در دایرکتوری کاری فعلی خود به دنبال شیء اشکالزدایی منطبق خواهد گشت.
دادههای debuginfo به درخواست والگریند در قطعات کوچک (۸ کیلوبایت) منتقل میشوند. هر بلوک با استفاده از LZO فشرده میشود تا زمان انتقال کاهش یابد. این پیادهسازی برای بهترین کارایی بر روی یک پیوند شبکه تکمرحلهای 802.11g (WiFi) تنظیم شده است.
توجه داشته باشید که بررسیها برای تطابق اشیاء اصلی در برابر اشیاء اشکالزدایی، با استفاده از طرحواره GNU debuglink CRC، حتی هنگام استفاده از سرور debuginfo نیز انجام میشود. برای غیرفعال کردن چنین بررسیای، باید گزینه --allow-mismatched-debuginfo=yes را نیز تعیین کنید.
به طور پیشفرض سیستم ساخت والگریند برنامه valgrind-di-server را برای پلتفرم هدف (target) میسازد، که مسلماً آن چیزی نیست که شما میخواهید. تا کنون نتوانستهایم دریابیم که چگونه automake/autoconf را وادار کنیم آن را برای پلتفرم ساخت (build) بسازد. اگر میخواهید از آن استفاده کنید، باید با استفاده از دستور نمایشدادهشده در بالای فایل auxprogs/valgrind-di-server.c آن را به صورت دستی دوباره کامپایل کنید.
والگریند همچنین میتواند اطلاعات اشکالزدایی را از طریق debuginfod بارگیری کند. برای اطلاعات بیشتر بخش DEBUGINFOD را ببینید.
--allow-mismatched-debuginfo=no|yes [no]
این بررسی را میتوان با استفاده از --allow-mismatched-debuginfo=yes لغو کرد. این کار ممکن است در مواردی مفید باشد که اشیاء debuginfo و اصلی به روش مناسب از یکدیگر تفکیک نشده باشند. با این حال هنگام استفاده از آن محتاط باشید: این کار تمام بررسیهای یکپارچگی را غیرفعال میکند و مشاهده شده است که والگریند هنگام عدم تطابق اشیاء اصلی و اشکالزدایی دچار فروپاشی میشود.
--suppressions=<filename> [default: $PREFIX/lib/valgrind/default.supp]
--gen-suppressions=<yes|no|all> [default: no]
---- Print suppression ? --- [Return/N/n/Y/y/C/c] ----
فشردن کلید Ret، یا N Ret یا n Ret، باعث میشود والگریند بدون چاپ سرکوب برای این خطا، به اجرای خود ادامه دهد.
فشردن کلید Y Ret یا y Ret باعث میشود والگریند یک رکورد سرکوب برای این خطا بنویسد. سپس میتوانید آن را کپی کرده و در یک فایل سرکوب جایگذاری کنید تا در آینده دیگر درباره این خطا پیامی دریافت نکنید.
هنگامی که روی all تنظیم شود، والگریند برای هر خطای گزارششده، بدون پرسش از کاربر، یک رکورد سرکوب چاپ میکند.
این گزینه به ویژه برای برنامههای C++ بسیار کاربردی است، زیرا سرکوبها را دقیقاً همانطور که نیاز است با نامهای تغییرنامیافته (mangled) چاپ میکند.
توجه داشته باشید که سرکوبهای چاپشده تا حد امکان خاص و دقیق هستند. ممکن است بخواهید موارد مشابه را با افزودن نویسههای عمومی (wildcards) به نام توابع و استفاده از نویسههای عمومی در سطح فریم، یکی کنید (ادغام نمایید). امکانات نویسههای عمومی قدرتمند و در عین حال انعطافپذیر هستند و با کمی ویرایش دقیق، میتوانید یک خانواده کامل از خطاهای مرتبط را تنها با چند رکورد سرکوب، مهار کنید.
گاهی اوقات دو خطای متفاوت با یک رکورد سرکوب یکسان مهار میشوند؛ در این حالت والگریند سرکوب را بیش از یک بار در خروجی میآورَد، اما شما تنها به داشتن یک نسخه در فایل سرکوب خود نیاز دارید (البته داشتن بیش از یک مورد نیز مشکلی ایجاد نخواهد کرد). همچنین نام سرکوب به صورت <insert a suppression name here> داده میشود؛ این نام اهمیت چندانی ندارد و صرفاً همراه با گزینه -v که تمام رکوردهای سرکوب استفادهشده را چاپ میکند، استفاده میشود.
--input-fd=<number> [default: 0, stdin]
--dsymutil=no|yes [yes]
سیستمعامل macOS از یک طرح پیوند اطلاعات اشکالزدایی (debuginfo) به تعویق افتاده استفاده میکند. هنگامی که فایلهای شیء حاوی اطلاعات اشکالزدایی در یک .dylib یا یک فایل اجرایی پیوند داده میشوند، اطلاعات اشکالزدایی در فایل نهایی کپی نمیشوند. در عوض، اطلاعات اشکالزدایی باید به صورت دستی با اجرای dsymutil (یک ابزار ارائهشده توسط سیستم) روی فایل اجرایی یا .dylib پیوند داده شوند. اطلاعات اشکالزدایی ترکیبشده حاصل در پوشهای در کنار فایل اجرایی یا .dylib، اما با پسوند .dSYM قرار میگیرد.
با تنظیم --dsymutil=no، والگریند مواردی را که در آنها پوشه .dSYM یا وجود ندارد، یا وجود دارد اما به نظر میرسد با فایل اجرایی یا .dylib مرتبط مطابقت ندارد (به احتمال زیاد به دلیل قدیمی بودن)، شناسایی میکند. در این موارد، والگریند یک پیام هشدار چاپ میکند اما هیچ اقدام دیگری انجام نمیدهد.
با تنظیم --dsymutil=yes، والگریند در چنین مواردی به طور خودکار dsymutil را بر حسب نیاز اجرا میکند تا اطلاعات اشکالزدایی را بهروز کند. از تمام جهات کاربردی، اگر همیشه از --dsymutil=yes استفاده کنید، دیگر هیچ نیازی به اجرای دستی dsymutil یا اجرای آن به عنوان بخشی از سیستم ساخت برنامه شما وجود نخواهد داشت، زیرا والگریند آن را در صورت لزوم اجرا خواهد کرد.
والگریند برای اجرای dsymutil روی هیچ فایل اجرایی یا کتابخانهای در پوشههای /usr، /bin، /sbin، /opt، /sw، /System، /Library یا /Applications تلاش نخواهد کرد، زیرا dsymutil در چنین شرایطی همیشه با شکست مواجه میشود. این شکست هم به این دلیل است که اطلاعات اشکالزدایی برای چنین مؤلفههای سیستمی پیشنصبشدهای در هیچ کجا موجود نیست، و هم به این دلیل که به مجوز نوشتن در آن دایرکتوریها نیاز خواهد داشت.
هنگام استفاده از --dsymutil=yes محتاط باشید، زیرا باعث میشود پوشههای .dSYM قبلی بدون اخطار حذف شده و دوباره ایجاد شوند. همچنین توجه داشته باشید که dsymutil بسیار کند است و گاهی این کندی بیش از حد است.
--max-stackframe=<number> [default: 2000000]
اگر برنامه شما آرایههای بزرگی دارد که روی پشته تخصیص داده شدهاند، ممکن است لازم باشد از این گزینه استفاده کنید. والگریند اشارهگر پشته برنامه شما را ردیابی میکند. اگر این مقدار بیشتر از مقدار آستانه تغییر کند، والگریند فرض میکند که برنامه شما به پشته متفاوتی سوییچ میکند و Memcheck رفتاری متفاوت با زمانی که تغییر اشارهگر پشته کمتر از آستانه است، نشان میدهد. معمولاً این روش اکتشافی به خوبی کار میکند. با این حال، اگر برنامه شما ساختارهای بزرگی را روی پشته تخصیص دهد، این روش اکتشافی به اشتباه میافتد و متعاقباً Memcheck تعداد زیادی دسترسی نامعتبر به پشته را گزارش خواهد داد. این گزینه به شما امکان میدهد این آستانه را به مقدار متفاوتی تغییر دهید.
تنها در صورتی باید استفاده از این گزینه را مد نظر قرار دهید که خروجی اشکالزدایی والگریند به شما دستور این کار را بدهد. در این حالت، خروجی مقدار آستانه جدیدی را که باید مشخص کنید به شما خواهد گفت.
به طور کلی، تخصیص ساختارهای بزرگ روی پشته ایده بدی است، زیرا به راحتی ممکن است با کمبود فضای پشته مواجه شوید، به ویژه در سیستمهایی با حافظه محدود یا سیستمهایی که انتظار میرود تعداد زیادی ریسه (thread) را که هر کدام پشته کوچکی دارند پشتیبانی کنند، و همچنین به این دلیل که بررسی خطای انجامشده توسط Memcheck برای دادههای تخصیصیافته در هیپ (heap) مؤثرتر از دادههای تخصیصیافته در پشته است. اگر مجبور به استفاده از این گزینه شدید، ممکن است بخواهید بازنویسی کد خود را برای تخصیص روی هیپ به جای پشته مد نظر قرار دهید.
--main-stacksize=<number> [default: use current 'ulimit' value]
برای سادهسازی مدیریت حافظه خود، والگریند تمام فضای مورد نیاز برای پشته ریسه اصلی را در زمان راهاندازی رزرو میکند. این بدان معناست که باید اندازه پشته مورد نیاز را در ابتدای راهاندازی بداند.
به طور پیشفرض، والگریند از مقدار فعلی «ulimit» برای اندازه پشته، یا ۱۶ مگابایت (هر کدام که کمتر باشد) استفاده میکند. در بسیاری از موارد این امر اندازهای در محدوده ۸ تا ۱۶ مگابایت به پشته میدهد که تقریباً برای اکثر برنامهها هرگز سرریز نمیشود.
اگر به اندازه پشته کلی بزرگتری نیاز دارید، از --main-stacksize برای تعیین آن استفاده کنید. آن را تنها به اندازهای که واقعاً نیاز دارید بالا ببرید، زیرا رزرو فضایی بسیار بیشتر از نیاز شما (یعنی صدها مگابایت بیشتر از حد نیاز) تخصیصدهندههای حافظه والگریند را محدود کرده و ممکن است مقدار کل حافظهای را که والگریند میتواند استفاده کند کاهش دهد. این موضوع در عمل تنها در ماشینهای ۳۲ بیتی اهمیت دارد.
در لینوکس، میتوانید پشتهای به اندازه حداکثر ۲ گیگابایت درخواست کنید. در صورتی که پشته نتواند تخصیص یابد، والگریند با یک پیام عیبیابی متوقف خواهد شد.
گزینه --main-stacksize تنها بر اندازه پشته برای ریسه اولیه برنامه تأثیر میگذارد. این گزینه هیچ ارتباطی با اندازه پشته سایر ریسهها ندارد، زیرا والگریند آنها را تخصیص نمیدهد.
ممکن است لازم باشد از هر دو گزینه --main-stacksize و --max-stackframe به صورت توأم استفاده کنید. درک این نکته مهم است که --main-stacksize حداکثر اندازه کل پشته را تعیین میکند، در حالی که --max-stackframe بزرگترین اندازه هر تکفریم پشته را مشخص میسازد. شما باید مقدار --main-stacksize را خودتان محاسبه و تعیین کنید (معمولاً اگر برنامه شما خطای segfault دهد). اما والگریند در صورت نیاز، اندازه مورد نیاز --max-stackframe را به شما خواهد گفت.
همانطور که در توضیحات --max-stackframe نیز بحث شد، نیاز به یک پشته بزرگ نشانهای از مشکلات احتمالی سازگاری و حملپذیری است. بهترین توصیه این است که تمام دادههای حجیم را در حافظه تخصیصیافته در هیپ قرار دهید.
--max-threads=<number> [default: 500]
--realloc-zero-bytes-frees=yes|no [default: yes for glibc no otherwise]
به عنوان مثال، اگر از والگریندی استفاده میکنید که از طریق یک بسته روی یک توزیع لینوکس مبتنی بر GNU libc نصب شده است اما برنامه آزمایشی خود را با musl libc یا کتابخانه JEMalloc پیوند میدهید، استفاده از --realloc-zero-bytes-frees=no را مد نظر قرار دهید.
ابزار Address Sanitizer گزینه مشابه و حتی طولانیتری به نام allocator_frees_and_returns_null_on_realloc_zero دارد.
گزینههای مرتبط با ()MALLOC (MALLOC()-RELATED OPTIONS)
برای ابزارهایی که از نسخه اختصاصی خود برای malloc استفاده میکنند (مانند Memcheck، Massif، Helgrind و DRD)، گزینههای زیر اعمال میشوند.
--alignment=<number> [default: 8 or 16, depending on the platform]
--redzone-size=<number> [default: depends on the tool]
افزایش اندازه منطقه قرمز، تشخیص سرریزهای با فواصل بزرگتر را ممکن میسازد، اما مقدار حافظه مصرفی والگریند را افزایش میدهد. کاهش اندازه منطقه قرمز حافظه مورد نیاز والگریند را کاهش میدهد اما شانس شناسایی سرریزها یا زیرریزها را نیز کم میکند، بنابراین توصیه نمیشود.
--xtree-memory=none|allocs|full [none]
هنگامی که روی none تنظیم شود، هیچ درخت اجرای حافظهای تولید نمیشود.
هنگامی که روی allocs تنظیم شود، درخت اجرای حافظه تعداد فعلی بایتهای تخصیصیافته و تعداد فعلی بلوکهای تخصیصیافته را ارائه میدهد.
هنگامی که روی full تنظیم شود، درخت اجرای حافظه ۶ اندازهگیری مختلف را ارائه میدهد: تعداد فعلی بایتها و بلوکهای تخصیصیافته (مقادیر یکسان با allocs)، تعداد کل بایتها و بلوکهای تخصیصیافته، و تعداد کل بایتها و بلوکهای آزادشده.
توجه داشته باشید که سربار پردازنده (cpu) و حافظه برای تولید یک xtree به ابزار بستگی دارد. سربار پردازنده برای مقدار allocs کم است، زیرا اطلاعات مورد نیاز برای تولید این گزارش در هر صورت توسط ابزار نگهداری میشود. برای massif و helgrind، مشخص کردن full به معنای ثبت یک ردگیری پشته برای هر عملیات آزادسازی (free) است، در حالی که این ابزارها در حالت عادی تنها یک ردگیری پشته برای تخصیص (allocation) ثبت میکنند. برای Memcheck، سربار پردازنده برای مقدار full کم است، زیرا این گزینه تنها میتواند در ترکیب با --keep-stacktraces=alloc-and-free یا --keep-stacktraces=alloc-then-free استفاده شود، که خود از قبل یک ردگیری پشته را برای هر عملیات آزادسازی ثبت میکند. سربار حافظه بین ۵ تا ۱۰ کلمه (word) به ازای هر ردگیری پشته یکتا در xtree متغیر است، به علاوه حافظه مورد نیاز برای ثبت ردگیری پشته برای عملیاتهای آزادسازی، در صورتی که به طور خاص برای xtree مورد نیاز باشد.
--xtree-memory-file=<filename> [default: xtmemory.kcg.%p]
اگر نام فایل حاوی پسوند .ms باشد، آنگاه قالب فایل تولیدشده قالب خروجی massif خواهد بود. اگر نام فایل حاوی پسوند .kcg باشد یا هیچ پسوندی ارائه نشده یا شناسایی نشود، آنگاه قالب فایل تولیدشده قالب خروجی callgrind خواهد بود.
برای توضیح دقیق درباره قالبهای درخت اجرا، بخش Execution Trees را ببینید.
گزینههای غیرمعمول (UNCOMMON OPTIONS)
این گزینهها برای تمام ابزارها اعمال میشوند، زیرا بر برخی سازوکارهای درونی و کمترشناختهشده هسته والگریند تأثیر میگذارند. بیشتر افراد نیازی به استفاده از آنها نخواهند داشت.
--smc-check=<none|stack|all|all-non-file> [default: all-non-file for x86/amd64/s390x, stack for other archs]
برای معماریهای «مدرن» -- یعنی هر معماری به غیر از x86، amd64 یا s390x -- مقدار پیشفرض stack است. دلیل این امر آن است که یک برنامه صحیح باید پس از اصلاح کد، اقدامی صریح برای برقراری مجدد همدوسی حافظه پنهان D-I (دستورالعمل و داده) انجام دهد. والگریند چنین اقداماتی را مشاهده کرده و رعایت میکند، که نتیجه آن مدیریت شفاف کد خودتغییردهنده بدون هیچ هزینه اضافی است.
برای x86، amd64 و s390x، نیازی نیست برنامه به سختافزار اعلام کند که هماهنگسازی همدوسی D-I لازم است. از این رو مقدار پیشفرض all-non-file است، که حالت معمول تولید کد در یک ناحیه ناشناس (غیروابسته به فایل) نگاشتشده با mmap را پوشش میدهد.
معانی چهار مقدار موجود به شرح زیر است: بدون تشخیص (none)، تشخیص کد خودتغییردهنده روی پشته (که توسط GCC برای پیادهسازی توابع تو در تو استفاده میشود) (stack)، تشخیص کد خودتغییردهنده در همهجا (all)، و تشخیص کد خودتغییردهنده در همهجا به جز در نگاشتهای متکی به فایل (all-non-file).
اجرا با گزینه all سرعت والگریند را به طور محسوسی کاهش میدهد. اجرا با none به ندرت باعث افزایش سرعت میشود، چرا که در بیشتر برنامهها مقدار بسیار کمی کد به صورت پویا تولید میشود. درخواست کلاینت VALGRIND_DISCARD_TRANSLATIONS جایگزینی برای --smc-check=all و --smc-check=all-non-file است که به تلاش بیشتری از سوی برنامهنویس نیاز دارد اما به والگریند اجازه میدهد برنامه شما را سریعتر اجرا کند، زیرا دقیقاً به آن اطلاع میدهد چه زمانی باید ترجمهها مجدداً ساخته شوند.
--smc-check=all-non-file نسخهای کمهزینهتر اما محدودتر از --smc-check=all ارائه میدهد. این گزینه به هر ترجمهای که منشأ آن نگاشتهای حافظه مبتنی بر فایل نباشد، بررسیهایی اضافه میکند. برنامههای کاربردی شاخصی که کد تولید میکنند، به عنوان مثال JITها در مرورگرهای وب، کد را در نواحی mmap ناشناس تولید میکنند، در حالی که کد «ثابت» مرورگر همواره در نگاشتهای متکی به فایل قرار دارد. --smc-check=all-non-file از این ویژگی بهره میبرد و سربار بررسی را به کدهایی محدود میکند که احتمالاً توسط JIT تولید شدهاند.
--read-inline-info=<yes|no> [default: see below]
==15380== Conditional jump or move depends on uninitialised value(s) ==15380== at 0x80484EA: main (inlinfo.c:6) ==15380== ==15380== Conditional jump or move depends on uninitialised value(s) ==15380== at 0x8048550: fun_noninline (inlinfo.c:6) ==15380== by 0x804850E: main (inlinfo.c:34) ==15380== ==15380== Conditional jump or move depends on uninitialised value(s) ==15380== at 0x8048520: main (inlinfo.c:6)
و در اینجا همان خطاها با --read-inline-info=yes:
==15377== Conditional jump or move depends on uninitialised value(s) ==15377== at 0x80484EA: fun_d (inlinfo.c:6) ==15377== by 0x80484EA: fun_c (inlinfo.c:14) ==15377== by 0x80484EA: fun_b (inlinfo.c:20) ==15377== by 0x80484EA: fun_a (inlinfo.c:26) ==15377== by 0x80484EA: main (inlinfo.c:33) ==15377== ==15377== Conditional jump or move depends on uninitialised value(s) ==15377== at 0x8048550: fun_d (inlinfo.c:6) ==15377== by 0x8048550: fun_noninline (inlinfo.c:41) ==15377== by 0x804850E: main (inlinfo.c:34) ==15377== ==15377== Conditional jump or move depends on uninitialised value(s) ==15377== at 0x8048520: fun_d (inlinfo.c:6) ==15377== by 0x8048520: main (inlinfo.c:35)
--read-var-info=<yes|no> [default: no]
==15363== Uninitialised byte(s) found during client check request ==15363== at 0x80484A9: croak (varinfo1.c:28) ==15363== by 0x8048544: main (varinfo1.c:55) ==15363== Address 0x80497f7 is 7 bytes inside data symbol "global_i2" ==15363== ==15363== Uninitialised byte(s) found during client check request ==15363== at 0x80484A9: croak (varinfo1.c:28) ==15363== by 0x8048550: main (varinfo1.c:56) ==15363== Address 0xbea0d0cc is on thread 1's stack ==15363== in frame #1, created by main (varinfo1.c:45)
و در اینجا همان خطاها با --read-var-info=yes:
==15370== Uninitialised byte(s) found during client check request ==15370== at 0x80484A9: croak (varinfo1.c:28) ==15370== by 0x8048544: main (varinfo1.c:55) ==15370== Location 0x80497f7 is 0 bytes inside global_i2[7], ==15370== a global variable declared at varinfo1.c:41 ==15370== ==15370== Uninitialised byte(s) found during client check request ==15370== at 0x80484A9: croak (varinfo1.c:28) ==15370== by 0x8048550: main (varinfo1.c:56) ==15370== Location 0xbeb4a0cc is 0 bytes inside local var "local" ==15370== declared at varinfo1.c:46, in frame #1 of thread 1
--vgdb-poll=<number> [default: 5000]
--vgdb-shadow-registers=no|yes [default: no]
--vgdb-prefix=<prefix> [default: /tmp/vgdb-pipe]
--run-libc-freeres=<yes|no> [default: yes]
کتابخانه C گنو (libc.so) که توسط تمام برنامهها استفاده میشود، ممکن است برای کاربردهای داخلی خود حافظه تخصیص دهد. معمولاً هنگام پایان برنامه زحمت آزادسازی آن حافظه را به خود نمیدهد—چرا که فایدهای ندارد، زیرا هسته لینوکس در هر حال با خروج پردازه تمام منابع آن را بازپس میگیرد، بنابراین این کار تنها سرعت را کاهش میدهد.
توسعهدهندگان glibc متوجه شدند که این رفتار باعث میشود ابزارهای بررسی نشت حافظه، مانند والگریند، در هنگام خروج برنامه نشتهایی را به اشتباه در glibc گزارش کنند. برای جلوگیری از این مشکل، آنها تابعی به نام __libc_freeres را به طور ویژه فراهم کردند تا glibc تمام حافظهای را که تخصیص داده است آزاد کند. از این رو Memcheck تلاش میکند در هنگام خروج برنامه تابع __libc_freeres را اجرا کند.
متأسفانه در برخی نسخههای بسیار قدیمی glibc، تابع __libc_freeres به قدری دارای اشکال است که باعث بروز خطای نقض قطعهبندی (segmentation fault) میشود. این موضوع به ویژه در Red Hat 7.1 مشهود بود. بنابراین این گزینه به منظور جلوگیری از اجرای __libc_freeres فراهم شده است. اگر برنامه شما به نظر میرسد روی والگریند به خوبی اجرا میشود اما در هنگام خروج با خطای سگفالت متوقف میشود، ممکن است متوجه شوید که --run-libc-freeres=no آن را برطرف میکند، هرچند به قیمت احتمال گزارش نادرست نشت حافظه در libc.so.
--run-cxx-freeres=<yes|no> [default: yes]
کتابخانه استاندارد C++ گنو (libstdc++.so) که توسط تمام برنامههای C++ کامپایلشده با g++ استفاده میشود، ممکن است برای مقاصد خود حافظه تخصیص دهد. معمولاً هنگام پایان برنامه زحمت آزادسازی آن حافظه را به خود نمیدهد—چرا که فایدهای ندارد، زیرا هسته در هر حال هنگام خروج پردازه تمام منابع آن را بازپس میگیرد، بنابراین این کار فقط سرعت را کاهش میدهد.
توسعهدهندگان gcc دریافتند که این رفتار موجب میشود ابزارهای بررسی نشت، مانند والگریند، در پایان برنامه نشتهایی را به غلط در libstdc++ گزارش دهند. به منظور جلوگیری از این امر، آنها تابعی به نام __gnu_cxx::__freeres را اختصاصاً فراهم کردند تا libstdc++ تمام حافظهای را که تخصیص داده است آزاد کند. بنابراین Memcheck سعی میکند __gnu_cxx::__freeres را در هنگام خروج اجرا نماید.
به دلیل انعطافپذیری و مشکلات پیشبینینشده در رابطه با __gnu_cxx::__freeres، گزینه --run-cxx-freeres=no وجود دارد، اگرچه به بهای احتمال گزارش نادرست نشت فضا در libstdc++.so.
--sim-hints=hint1,hint2,...
کتابخانه GNU glibc pthread (libpthread.so) که توسط برنامههای چندنخی pthread استفاده میشود، حافظه پنهانی (cache) از پشتههای pthread نگه میدارد. هنگامی که یک pthread پایان مییابد، حافظه مورد استفاده برای پشته pthread و برخی ساختارهای داده مرتبط با حافظه محلی نخ (thread local storage) همیشه بلافاصله آزاد نمیشوند. این حافظه در یک حافظه پنهان (تا اندازهای مشخص) نگهداری میشود و در صورت شروع یک نخ جدید دوباره استفاده میشود.
این حافظه پنهان باعث میشود ابزار helgrind برخی خطاهای مثبت کاذب در رابطه با شرایط رقابت (race condition) را روی این حافظه پنهانشده گزارش کند، زیرا helgrind متدهای اولیه همگامسازی داخلی حافظه پنهان glibc را درک نمیکند. بنابراین، هنگام استفاده از helgrind، غیرفعال کردن این حافظه پنهان به جلوگیری از خطاهای مثبت کاذب شرایط رقابت کمک میکند، به ویژه هنگام استفاده از متغیرهای حافظه محلی نخ (مانند متغیرهایی که از توصیفکننده __thread استفاده میکنند).
هنگام استفاده از ابزار memcheck، غیرفعال کردن حافظه پنهان اطمینان حاصل میکند که حافظه استفادهشده توسط glibc برای مدیریت متغیرهای __thread در هنگام پایان کار یک نخ مستقیماً آزاد میشود.
توجه: والگریند این حافظه پنهان را با استفاده از برخی آگاهیهای داخلی از پیادهسازی کش پشته glibc و با بررسی اطلاعات اشکالزدایی کتابخانه pthread غیرفعال میکند. بنابراین این تکنیک تا حدی شکننده است و ممکن است برای تمام نسخههای glibc کار نکند. این قابلیت با موفقیت بر روی نسخههای مختلف glibc (مانند 2.11، 2.16، 2.18) در پلتفرمهای مختلف آزمایش شده است.
--scheduling-quantum=<number> [default: 100000]
--fair-sched=<no|yes|try> [default: no]
اگر برنامهای چندنخی و تعاملی مانند یک مرورگر وب را روی والگریند اجرا میکنید، ممکن است متوجه شوید که این تنظیم پاسخدهی کلی برنامه را بهبود میبخشد.
--kernel-variant=variant1,variant2,...
--merge-recursive-frames=<number> [default: 0]
گزینه --merge-recursive-frames=<number> به والگریند دستور میدهد چرخههای فراخوانی بازگشتی با اندازه تا سقف <number> فریم را شناسایی و ادغام کند. هنگامی که چنین چرخهای شناسایی میشود، والگریند چرخه را در ردگیری پشته به عنوان یک شمارنده برنامه منحصربهفرد ثبت میکند.
مقدار 0 (پیشفرض) باعث عدم ادغام فراخوانیهای بازگشتی میشود. مقدار 1 باعث فشردهسازی ردگیری پشته الگوریتمهای بازگشتی ساده (به عنوان مثال، پیادهسازی فاکتوریل) خواهد شد. مقدار 2 معمولاً برای ادغام ردگیریهای پشته تولیدشده توسط الگوریتمهای بازگشتی مانند درختهای دودویی، مرتبسازی سریع و غیره مورد نیاز است. برای الگوریتمهای بازگشتی پیچیدهتر ممکن است مقادیر بالاتری لازم باشد.
توجه: فراخوانیهای بازگشتی از طریق تحلیل مقادیر شمارنده برنامه شناسایی میشوند. آنها از روی بررسی نام توابع شناسایی نمیشوند.
--num-transtab-sectors=<number> [default: 6 for Android platforms, 16 for all others]
--avg-transtab-entry-size=<number> [default: 0, meaning use tool provided default]
--aspace-minaddr=<address> [default: depends on the platform]
--valgrind-stacksize=<number> [default: 1MB]
در صورتی که چنین هشدار (بعیدی) صادر شد، یا والگریند به دلیل خطای نقض قطعهبندی متوقف گردید، از گزینه --valgrind-stacksize استفاده کنید. چنین خطاهای نقض قطعهبندی هنگام ابهامزدایی (demangling) از نمادهای عظیم C++ مشاهده شده است.
اگر برنامه کاربردی شما از نخهای زیادی استفاده میکند و به حافظه زیادی نیاز دارد، میتوانید با کاهش اندازه این پشتههای والگریند با استفاده از گزینه --valgrind-stacksize مقداری حافظه آزاد به دست آورید.
--show-emwarns=<yes|no> [default: no]
--require-text-symbol=:sonamepatt:fnnamepatt
هر دو الگوی sonamepatt و fnnamepatt را میتوان با استفاده از نویسههای عمومی معمول ? و * نوشت. برای مثال: ":*libc.so*:foo?bar". میتوانید از نویسههایی غیر از دو نقطه برای جدا کردن دو الگو استفاده کنید. تنها نکته مهم این است که نویسه اول و نویسه جداکننده یکسان باشند. به عنوان مثال، نمونه بالا را میتوان به این صورت نیز نوشت: "Q*libc.so*Qfoo?bar". استفاده از چندین فلگ --require-text-symbol مجاز است، که در این صورت اشیاء اشتراکی بارگذاریشده در پردازه در برابر همه آنها بررسی خواهند شد.
هدف از این کار، پشتیبانی از استفاده مطمئن از کتابخانههای نشانهگذاریشده است. برای مثال، فرض کنید نسخهای از کتابخانه GCC با نام libgomp.so داریم که با حاشیهنویسیهایی برای پشتیبانی از Helgrind نشانهگذاری شده است. بسیار آسان و گیجکننده است که نسخه اشتباه و بدون حاشیهنویسی libgomp.so در برنامه بارگذاری شود. بنابراین ایده این است: یک نماد متنی به کتابخانه نشانهگذاریشده اضافه کنید، به عنوان مثال annotated_for_helgrind_3_6، و سپس فلگ --require-text-symbol=:*libgomp*so*:annotated_for_helgrind_3_6 را تعیین کنید تا هنگامی که libgomp.so بارگذاری شد، والگریند جدول نمادهای آن را پیمایش کند، و اگر نماد وجود نداشت اجرا متوقف شود، به جای اینکه بدون هشدار با کتابخانه نشانهگذارینشده ادامه دهد. توجه داشته باشید که باید کل فلگ را درون گیومه قرار دهید تا از بسط دادن نویسههای عمومی * و ? توسط پوسته جلوگیری شود.
--soname-synonyms=syn1=pattern1,syn2=pattern2,...
در حال حاضر، این انعطافپذیری تنها برای توابع مرتبط با malloc و با استفاده از مترادف somalloc مجاز است. این مترادف برای تمام ابزارهایی که جایگزینی استاندارد توابع مربوط به malloc را انجام میدهند قابل استفاده است (مانند memcheck، helgrind، drd، massif، dhat).
توجه: soname یک کتابخانه اشتراکی elf را میتوان با استفاده از ابزار readelf به دست آورد.
--progress-interval=<number> [default: 0, meaning 'disabled']
هنگامی که number روی یک مقدار غیر صفر تنظیم شود، والگریند خلاصهای از پیشرفت را در یک خط در هر number ثانیه چاپ میکند. مقادیر معتبر برای number بین 0 و 3600 (شامل هر دو) است. در اینجا یک نمونه خروجی با مقدار number برابر ۱۰ آمده است:
PROGRESS: U 110s, W 113s, 97.3% CPU, EvC 414.79M, TIn 616.7k, TOut 0.5k, #thr 67 PROGRESS: U 120s, W 124s, 96.8% CPU, EvC 505.27M, TIn 636.6k, TOut 3.0k, #thr 64 PROGRESS: U 130s, W 134s, 97.0% CPU, EvC 574.90M, TIn 657.5k, TOut 3.0k, #thr 63
هر خط نشاندهنده موارد زیر است:
از روند پیشرفت این مقادیر، میتوان موارد زیر را مشاهده کرد:
گزینههای اشکالزدایی والگریند (DEBUGGING VALGRIND OPTIONS)
همچنین گزینههایی برای اشکالزدایی خود والگریند وجود دارد. در روال معمول کارها نباید نیازی به استفاده از آنها داشته باشید. اگر مایل به دیدن این فهرست هستید، از گزینه --help-debug استفاده کنید.
گزینههای ممچک (MEMCHECK OPTIONS)
--leak-check=<no|summary|yes|full> [default: summary]
اگر --xml=yes داده شود، ممچک به طور خودکار مقدار --leak-check=full را استفاده خواهد کرد. میتوانید از --show-leak-kinds=none برای کاهش اندازه خروجی xml استفاده کنید، چنانچه به نتایج نشت حافظه علاقهای ندارید.
--leak-resolution=<low|med|high> [default: high]
برای اشکالزدایی دقیق و موشکافانه نشت حافظه، احتمالاً مایل خواهید بود از --leak-resolution=high همراه با --num-callers=40 یا عددی به همین اندازه بزرگ استفاده کنید.
توجه داشته باشید که تنظیم --leak-resolution بر توانایی ممچک در یافتن نشتهای حافظه تأثیری نمیگذارد. این گزینه تنها نحوه ارائه و نمایش نتایج را تغییر میدهد.
--show-leak-kinds=<set> [default: definite,possible]
--errors-for-leak-kinds=<set> [default: definite,possible]
--leak-check-heuristics=<set> [default: all]
توجه داشته باشید که این روشهای مکاشفهای به چیدمان اشیاء تولیدشده توسط کامپایلر ++C وابسته هستند. آنها با برخی از نسخههای gcc (مانند 4.4 و 4.7) آزمایش شدهاند. ممکن است با سایر کامپایلرهای ++C به درستی کار نکنند.
--show-reachable=<yes|no> , --show-possibly-lost=<yes|no>
توجه داشته باشید که --show-possibly-lost=no در صورتی که --show-reachable=yes تعیین شده باشد، هیچ اثری ندارد.
--xtree-leak=<no|yes> [no]
افزایش یا کاهش تمامی رویدادهای بالا نیز در فایل خروجی درج خواهد شد تا تغییرات تفاضلی (دلتا: افزایش یا کاهش) بین ۲ جستجوی متوالی نشت حافظه ارائه شود. برای مثال، iRB میزان افزایش در رویداد RB است، و dPBk میزان کاهش در رویداد PBk است. مقادیر مربوط به رویدادهای افزایش و کاهش برای اولین جستجوی نشت انجامشده صفر خواهند بود.
برای توضیحات دقیق پیرامون درختهای اجرا، بخش درختهای اجرا (Execution Trees) را ببینید.
--xtree-leak-file=<filename> [default: xtleak.kcg.%p]
برای توضیحات دقیق درباره قالبهای درختهای اجرا، بخش درختهای اجرا (Execution Trees) را ببینید.
--undef-value-errors=<yes|no> [default: yes]
--track-origins=<yes|no> [default: no]
هنگامی که روی yes تنظیم شود، ممچک منشأ تمام متغیرهای تعریفنشده را ثبت و ردگیری میکند. سپس، هنگامی که خطایی مرتبط با متغیرهای تعریفنشده گزارش میشود، ممچک تلاش خواهد کرد تا منشأ آن مقدار را نمایش دهد. منشأ میتواند یکی از چهار مورد زیر باشد: یک بلوک هیپ (heap block)، یک تخصیص در استک (stack allocation)، یک درخواست کلاینت (client request)، یا سایر منابع متفرقه (مانند یک فراخوانی به brk).
برای متغیرهای تعریفنشدهای که از یک بلوک هیپ منشأ میگیرند، ممچک نشان میدهد که آن بلوک در کجا تخصیص یافته است. برای متغیرهای تعریفنشدهای که از یک تخصیص در استک نشأت میگیرند، ممچک میتواند به شما بگوید کدام تابع آن مقدار را تخصیص داده است، اما نه بیشتر از آن -- به طور معمول مکان دقیق آکولاد بازکننده تابع در کد مبدأ را به شما نشان میدهد. بنابراین باید با دقت بررسی کنید که تمامی متغیرهای محلی آن تابع به درستی مقداردهی اولیه شده باشند.
سربار کارایی: ردگیری منشأ هزینهبر و سنگین است. سرعت اجرای ممچک را نصف میکند و مصرف حافظه را حداقل ۱۰۰ مگابایت و چه بسا بیشتر افزایش میدهد. با این حال، میتواند تلاش لازم برای شناسایی علت ریشهای خطاهای متغیرهای تعریفنشده را به شدت کاهش دهد و بنابراین علیرغم اجرای کندتر، اغلب باعث صرفهجویی چشمگیر در وقت و افزایش بهرهوری برنامهنویس میشود.
دقت: ممچک منشأها را با دقت بسیار بالایی ردگیری میکند. به منظور پرهیز از سربارهای بسیار سنگین زمانی و فضایی، برخی تقریبها اعمال میشوند. این احتمال وجود دارد، هرچند بعید، که ممچک یک منشأ نادرست را گزارش کند یا اصلاً نتواند هیچ منشأیی را شناسایی نماید.
توجه داشته باشید که ترکیب همزمان دو گزینه --track-origins=yes و --undef-value-errors=no بیمعنی و نامفهوم است. ممچک هنگام شروع به کار، این ترکیب را بررسی کرده و آن را رد مینماید.
--partial-loads-ok=<yes|no> [default: yes]
در صورت تنظیم روی no، بارگذاریها از آدرسهای تا حدی نامعتبر، همانند بارگذاری از آدرسهای کاملاً نامعتبر رفتار خواهند شد: یک خطای دسترسی غیرمجاز به آدرس صادر میشود و بایتهای حاصل به عنوان مقداردهیشده علامت میخورند.
توجه داشته باشید کدی که به این شکل رفتار میکند استانداردهای ISO C/C++ را نقض کرده و باید کدی خراب تلقی شود. در صورت امکان، چنین کدی باید حتماً اصلاح گردد.
--expensive-definedness-checks=<no|auto|yes> [default: auto]
انتخاب --expensive-definedness-checks=yes باعث میشود ممچک از دقیقترین تحلیل ممکن استفاده کند. این کار نرخ خطاهای کاذب را به حداقل میرساند، اما میتواند تا ۳۰٪ افت کارایی ایجاد کند.
انتخاب --expensive-definedness-checks=no باعث میشود ممچک از کمهزینهترین ابزار دقیقسازی ممکن استفاده کند. این کار کارایی را به حداکثر میرساند، اما معمولاً نرخ هشدارهای کاذب بسیار بالا و غیرقابل استفادهای ارائه خواهد داد.
تنظیم پیشفرض، یعنی --expensive-definedness-checks=auto، اکیداً توصیه میشود. این کار سبب میشود ممچک از حداقل ابزار دقیقسازی پرهزینه لازم جهت دستیابی به همان نرخ خطای کاذبِ حاصل از --expensive-definedness-checks=yes استفاده کند. همچنین یک مرحله تحلیل در زمان ابزار دقیقسازی را فعال میکند که هدف آن کاهش بیشتر هزینههای ابزار دقیقسازی دقیق است. در مجموع، افت کارایی در مقایسه با --expensive-definedness-checks=no عموماً در حدود ۵٪ است، هرچند که این میزان به شدت به بار کاری (workload) برنامه وابسته است. توجه داشته باشید که تنظیمات دقیق ابزار دقیقسازی در این حالت به معماری سیستم بستگی دارد.
--keep-stacktraces=alloc|free|alloc-and-free|alloc-then-free|none [default: alloc-and-free]
با گزینه alloc-then-free، یک ردگیری استک در زمان تخصیص ثبت شده و با بلوک مرتبط میشود. هنگامی که بلوک آزاد میشود، یک ردگیری استک دوم ثبت میگردد و این ردگیری جایگزین ردگیری استک تخصیص میشود. در نتیجه، هرگونه خطای «استفاده پس از آزادسازی» (use after free) در رابطه با این بلوک تنها میتواند ردگیری استک مکانی را نشان دهد که بلوک در آن آزاد شده است.
با گزینه alloc-and-free، ردگیری استک هر دو مرحله تخصیص و آزادسازی برای بلوک ذخیره میشود. بنابراین یک خطای «استفاده پس از آزادسازی» هر دو را نشان میدهد، که ممکن است خطایابی را سادهتر کند. در مقایسه با alloc-then-free، این تنظیم مصرف حافظه والگریند را کمی افزایش میدهد زیرا هر بلوک به جای یک مرجع، شامل دو مرجع است.
با گزینه alloc، فقط ردگیری استک زمان تخصیص ثبت (و گزارش) میشود. با گزینه free، فقط ردگیری استک زمان آزادسازی ثبت (و گزارش) میشود. این مقادیر تا حدی مصرف حافظه و cpu والگریند را کاهش میدهند. این گزینهها بسته به نوع خطاهایی که در جستجوی آنها هستید و سطح جزئیاتی که برای تحلیل آنها نیاز دارید میتوانند مفید واقع شوند. برای مثال، اگر تنها به خطاهای نشت حافظه علاقهمند هستید، ثبت ردگیریهای استک زمان تخصیص کافی خواهد بود.
با گزینه none، هیچ ردگیری استکی برای عملیات malloc و free ثبت نمیشود. اگر برنامه شما تعداد زیادی بلوک تخصیص میدهد و/یا از ردگیریهای استک بسیار متفاوتی تخصیص/آزادسازی را به انجام میرساند، این تنظیم میتواند مصرف cpu و/یا حافظه مورد نیاز را به طرز چشمگیری کاهش دهد. البته، در این حالت جزئیات ناچیزی برای خطاهای مرتبط با بلوکهای حافظه هیپ گزارش خواهد شد.
توجه داشته باشید که پس از ثبت یک ردگیری استک، والگریند آن ردگیری را در حافظه نگه میدارد حتی اگر هیچ بلوکی به آن ارجاع ندهد. برخی برنامهها (به عنوان مثال الگوریتمهای بازگشتی) میتوانند تعداد سرسامآوری از ردگیریهای استک تولید کنند. چنانچه والگریند در چنین شرایطی حافظه بسیار زیادی مصرف کند، میتوانید با گزینههای --keep-stacktraces و/یا با استفاده از مقداری کوچکتر برای گزینه --num-callers، حافظه مورد نیاز را کاهش دهید.
اگر میخواهید از تحلیل پروفایل حافظه با --xtree-memory=full (بخش درختهای اجرا (Execution Trees) را ببینید) استفاده کنید، نمیتوانید --keep-stacktraces=free یا --keep-stacktraces=none را مشخص نمایید.
--freelist-vol=<number> [default: 20000000]
این گزینه حداکثر اندازه کل بلوکهای موجود در صف را بر حسب بایت مشخص میکند. مقدار پیشفرض آن بیست میلیون بایت است. افزایش این مقدار، کل حافظه مصرفی ممچک را بالا میبرد اما ممکن است دسترسی غیرمجاز به بلوکهای آزادشده را کشف کند که در غیر این صورت شناسایی نمیشدند.
--freelist-big-blocks=<number> [default: 1000000]
تنظیم مقدار 0 به این معنی است که تمام بلوکها به ترتیب ورود و خروج (FIFO) بازچرخانی میشوند.
--workaround-gcc296-bugs=<yes|no> [default: no]
همچنین ممکن است هنگام کار با GCC 3.X یا 4.X در لینوکس ۳۲ بیتی PowerPC نیاز به استفاده از این گزینه داشته باشید. این به آن دلیل است که GCC کدی تولید میکند که گهگاه به زیر اشارهگر استک دسترسی پیدا میکند، بهویژه در تبدیلات ممیز شناور به/از عدد صحیح. این رفتار ناقض مشخصات ELF در PowerPC ۳۲ بیتی است، چرا که در این مشخصات هیچ پیشبینی برای مجاز بودن دسترسی به مکانهای زیر اشارهگر استک صورت نگرفته است.
این گزینه از نسخه ۳.۱۲ منسوخ شده است و ممکن است در نسخههای آتی حذف گردد. در عوض باید از گزینه --ignore-range-below-sp برای تعیین بازه دقیق آفستهای زیر اشارهگر استک که باید نادیده گرفته شوند استفاده نمایید. یک معادل مناسب عبارت است از --ignore-range-below-sp=1024-1.
--ignore-range-below-sp=<number>-<number>
--show-mismatched-frees=<yes|no> [default: yes]
با این وجود، سناریویی وجود دارد که در آن نمیتوان از چنین عدم تطابقهایی جلوگیری کرد. آن سناریو زمانی است که کاربر پیادهسازیهایی از new/new[] ارائه میدهد که malloc را فراخوانی میکنند و پیادهسازیهایی از delete/delete[] که free را فراخوانی مینمایند، و این توابع به صورت نامتقارن درونخطی (inlined) میشوند. به عنوان مثال، تصور کنید که delete[] درونخطی شود ولی new[] درونخطی نشود. نتیجه این است که ممچک تمامی فراخوانیهای delete[] را به عنوان فراخوانی مستقیم به free «میبیند»، حتی زمانی که کد مبدأ برنامه فاقد هرگونه فراخوانی ناهمخوان باشد.
این امر منجر به تعداد زیادی گزارش خطای گیجکننده و نامربوط میگردد. گزینه --show-mismatched-frees=no این بررسیها را غیرفعال میکند. با این وجود، به طور کلی غیرفعال کردن آنها توصیه نمیشود، زیرا در این صورت ممکن است خطاهای واقعی را از دست بدهید.
--show-realloc-size-zero=<yes|no> [default: yes]
--ignore-ranges=0xPP-0xQQ[,0xRR-0xSS]
--malloc-fill=<hexnumber>
--free-fill=<hexnumber>
گزینههای کشگریند (CACHEGRIND OPTIONS)
--cachegrind-out-file=<file>
--cache-sim=no|yes [no]
--branch-sim=no|yes [no]
--instr-at-start=no|yes [yes]
--I1=<size>,<associativity>,<line size>
--D1=<size>,<associativity>,<line size>
--LL=<size>,<associativity>,<line size>
گزینههای کالگریند (CALLGRIND OPTIONS)
--callgrind-out-file=<file>
--dump-line=<no|yes> [default: yes]
--dump-instr=<no|yes> [default: no]
--compress-strings=<no|yes> [default: yes]
--compress-pos=<no|yes> [default: yes]
--combine-dumps=<no|yes> [default: no]
--dump-every-bb=<count> [default: 0, never]
--dump-before=<function>
--zero-before=<function>
--dump-after=<function>
--instr-atstart=<yes|no> [default: yes]
توجه داشته باشید که گراف فراخوانی حاصل به احتمال زیاد شامل main نخواهد بود، اما شامل تمامی توابعی است که پس از فعال شدن ابزار دقیقسازی اجرا شدهاند. ابزار دقیقسازی را میتوان همچنین بهصورت برنامهنویسیشده فعال یا غیرفعال کرد. برای اطلاع از ماکرویی که باید در کد منبع خود به کار ببرید، فایل سرآیند کالگریند callgrind.h را مشاهده کنید.
برای شبیهسازی حافظه پنهان، در صورت فعال کردن ابزار دقیقسازی در مراحل بعدی اجرای برنامه، دقت نتایج کمتر خواهد بود، زیرا شبیهساز در آن لحظه با یک حافظه پنهان خالی آغاز به کار میکند. برای غلبه بر این خطا، جمعآوری رویدادها را بعداً فعال نمایید.
--collect-atstart=<yes|no> [default: yes]
برای بررسی تنها بخشهایی از برنامه خود، دو امکان دارید:
در صورتی که بخش مورد نظر برنامه بارها فراخوانی شود، میتوان از گزینه دوم استفاده کرد. گزینه ۱، یعنی ایجاد تعداد زیادی فایل تخلیه (دامپ)، در اینجا کاربردی نیست.
وضعیت جمعآوری را میتوان در هنگام ورود و خروج یک تابع مشخص با گزینه --toggle-collect تغییر وضعیت داد (ضامن زد). اگر از این گزینه استفاده کنید، وضعیت جمعآوری در ابتدا باید غیرفعال باشد. توجه داشته باشید که تعیین گزینه --toggle-collect به طور ضمنی --collect-state=no را تنظیم میکند.
همچنین میتوان وضعیت جمعآوری را با درج درخواست کلاینت CALLGRIND_TOGGLE_COLLECT ; در موقعیتهای مورد نیاز از کد تغییر وضعیت داد.
--toggle-collect=<function>
--collect-jumps=<no|yes> [default: no]
--collect-systime=<no|yes|msec|usec|nsec> [default: no]
مقدار no نشاندهنده عدم ثبت هرگونه اطلاعات فراخوانی سیستمی است.
سایر مقادیر نشاندهنده ثبت تعداد فراخوانیهای سیستمی انجامشده (رویداد sysCount) و زمان سپریشده (رویداد sysTime) در فراخوانیهای سیستمی است. مقدار --collect-systime واحد استفادهشده برای sysTime را مشخص میکند: میلیثانیه، میکروثانیه یا نانوثانیه. با مقدار nsec، کالگریند زمان پردازنده (CPU) مصرفشده در طول فراخوانیهای سیستمی (sysCpuTime) را نیز ثبت میکند.
مقدار yes مترادف msec است. مقدار nsec در سامانه داروین (Darwin) پشتیبانی نمیشود.
--collect-bus=<no|yes> [default: no]
--cache-sim=<yes|no> [default: no]
--branch-sim=<yes|no> [default: no]
گزینههای هلگریند (HELGRIND OPTIONS)
--free-is-write=no|yes [default: no]
این قابلیت در والگریند ۳.۷.۰ جدید است و آزمایشی تلقی میشود. این ویژگی به طور پیشفرض فعال نیست زیرا تعامل آن با تخصیصدهندههای حافظه سفارشی در حال حاضر به خوبی شناخته نشده است. از بازخورد کاربران استقبال میشود.
--track-lockorders=no|yes [default: yes]
--history-level=none|approx|full [default: full]
جمعآوری چنین اطلاعاتی هم از نظر سرعت و هم از نظر مصرف حافظه پرهزینه است، بهویژه برای برنامههایی که رویدادهای همگامسازی بینریسهای فراوانی انجام میدهند (قفلها، باز کردن قفلها و غیره). بدون چنین اطلاعاتی، پیگیری و یافتن علل ریشهای شرایط رقابتی دشوارتر است. با این وجود، ممکن است در شرایطی که تنها میخواهید وجود یا عدم وجود شرایط رقابتی را بررسی کنید، نیازی به آن نداشته باشید؛ برای مثال هنگام انجام آزمون رگرسیون روی برنامهای که قبلاً عاری از شرایط رقابتی بوده است.
گزینه --history-level=none نقطه افراطی مقابل است. این گزینه سبب میشود هلگریند هیچ اطلاعاتی درباره دسترسیهای قبلی جمعآوری نکند. این حالت میتواند به طور چشمگیری سریعتر از --history-level=full باشد.
گزینه --history-level=approx سازشی میان این دو نقطه افراطی فراهم میکند. این گزینه سبب میشود هلگریند یک ردپای کامل برای دسترسی بعدی و اطلاعاتی تقریبی درباره دسترسی قبلی نشان دهد. این اطلاعات تقریبی شامل دو پشته است، و تضمین میشود که دسترسی قبلی در جایی بین نقاطی از برنامه که توسط این دو پشته مشخص شدهاند رخ داده است. این حالت به اندازه نمایش پشته دقیق برای دسترسی قبلی (آنگونه که --history-level=full انجام میدهد) سودمند نیست، اما بهتر از هیچ است و تقریباً به همان سرعت --history-level=none میباشد.
--history-backtrace-size=<number> [default: 8]
--delta-stacktrace=no|yes [default: yes on linux amd64/x86]
گزینه --delta-stacktrace روشی را که هلگریند ردپای پشته را برای گزینه --history-level=full ثبت میکند پیکربندی مینماید. چنین ردپای پشتهای معمولاً هر بار که بخش جدیدی از حافظه در یک بلوک پایه از دستورالعملها خوانده یا نوشته میشود، مورد نیاز است.
مقدار --delta-stacktrace=no باعث میشود هلگریند هر بار که به ردپای پشته نیاز است، یک ردپای پشته تاریخچه کامل را از روی اطلاعات بازپیچی (unwind) محاسبه کند.
مقدار --delta-stacktrace=yes به هلگریند اعلام میکند که تا زمانی که هیچ دستورالعمل فراخوانی، دستورالعمل بازگشت یا هر دستورالعمل دیگری که پشته فراخوانی را از زمان ثبت آخرین ردپای پشته تغییر دهد وجود نداشته باشد، ردپای پشته جدید را از روی ردپای قبلی مشتق کند. اگر چنین دستورالعملی اجرا نشده باشد، ردپای جدید پشته میتواند تنها با تغییر فریم بالایی به شمارنده فعلی برنامه (program counter) از روی ردپای قبلی به دست آید. این گزینه هنگام استفاده از --history-level=full میتواند سرعت هلگریند را تا ۲۵٪ افزایش دهد.
هنگام استفاده از --delta-stacktrace=yes باید جنبههای زیر را در نظر گرفت:
--conflict-cache-size=N [default: 1000000]
اطلاعات مربوط به دسترسیهای متناقض «قدیمی» در یک حافظه پنهان با اندازه محدود و با مدیریت به سبک LRU ذخیره میشود. این کار ضروری است زیرا ذخیره یک ردپای پشته برای تکتک دسترسیهای حافظه انجامشده توسط برنامه امکانپذیر و عملی نیست. اطلاعات پیشین درباره مکانهایی که اخیراً مورد دسترسی قرار نگرفتهاند بهطور دورهای دور ریخته میشوند تا فضا در حافظه پنهان آزاد شود.
این گزینه اندازه حافظه پنهان را بر حسب تعداد آدرسهای حافظه متفاوتی که اطلاعات دسترسیهای متناقض برای آنها ذخیره میشود، کنترل میکند. اگر متوجه شدید که هلگریند خطاهای شرایط رقابتی را تنها با یک پشته به جای دو پشته مورد انتظار نشان میدهد، افزایش این مقدار را امتحان کنید.
حداقل مقدار ۱۰۰۰۰ و حداکثر ۳۰۰۰۰۰۰۰ (سی برابر مقدار پیشفرض) است. افزایش مقدار به اندازه ۱ نیاز حافظه هلگریند را بسیار تقریبی حدود ۱۰۰ بایت افزایش میدهد، بنابراین حداکثر مقدار به سادگی حدود سه گیگابایت یا بیشتر حافظه اضافی مصرف خواهد کرد.
--check-stack-refs=no|yes [default: yes]
--ignore-thread-creation=<yes|no> [default: no]
همچنین حافظه جدید تخصیصیافته در حین ایجاد ریسه ردگیری نمیشود، یعنی گزارش شرایط رقابتی در آنجا سرکوب میگردد. ابزار DRD نیز همین کار را به صورت ضمنی انجام میدهد. این امر ضروری است زیرا libc سولاریس بسیاری از اشیاء را کش میکند و آنها را برای ریسههای مختلف دوباره به کار میبرد و این موضوع هلگریند را سردرگم میسازد.
گزینههای دیآردی (DRD OPTIONS)
--check-stack-var=<yes|no> [default: no]
--exclusive-threshold=<n> [default: off]
--join-list-vol=<n> [default: 10]
--first-race-only=<yes|no> [default: no]
--free-is-write=<yes|no> [default: no]
--report-signal-unlocked=<yes|no> [default: yes]
--segment-merging=<yes|no> [default: yes]
--segment-merging-interval=<n> [default: 10]
--shared-threshold=<n> [default: off]
--show-confl-seg=<yes|no> [default: yes]
--show-stack-usage=<yes|no> [default: no]
--ignore-thread-creation=<yes|no> [default: no]
--trace-addr=<address> [default: none]
--ptrace-addr=<address> [default: none]
--trace-alloc=<yes|no> [default: no]
--trace-barrier=<yes|no> [default: no]
--trace-cond=<yes|no> [default: no]
--trace-fork-join=<yes|no> [default: no]
--trace-hb=<yes|no> [default: no]
--trace-mutex=<yes|no> [default: no]
--trace-rwlock=<yes|no> [default: no]
--trace-semaphore=<yes|no> [default: no]
گزینههای ماسیف (MASSIF OPTIONS)
--heap=<yes|no> [default: yes]
--heap-admin=<size> [default: 8]
--stacks=<yes|no> [default: no]
اگر حداقل ۴ آرگومان پرگویی -v ارائه دهید، ماسیف برای هر افزایش و کاهش پشته یک ردگیری تولید میکند. ردگیری افزایش پشته شامل آدرس IP (اشارهگر دستورالعمل) است که پشته را افزایش داده است. توجه داشته باشید که برای دریافت آدرس کاملاً دقیق IP، باید گزینههای -px-default=unwindregs-at-mem-access --px-file-backed=unwindregs-at-mem-access را مشخص کنید.
--pages-as-heap=<yes|no> [default: no]
--depth=<number> [default: 30]
--alloc-fn=<name>
توجه داشته باشید که با تابع نامبرده تنها زمانی به این شیوه رفتار میشود که بالاترین مدخل در ردگیری پشته باشد، یا دقیقاً زیر تابع دیگری قرار داشته باشد که با آن به این شیوه رفتار شده است. برای مثال، اگر تابعی به نام malloc1 داشته باشید که malloc را پوشش میدهد، و malloc2 که malloc1 را پوشش میدهد، تنها تعیین کردن --alloc-fn=malloc2 هیچ اثری نخواهد داشت. شما باید --alloc-fn=malloc1 را نیز تعیین کنید. این موضوع کمی ناخوشایند است، اما دلیل آن این است که بررسی توابع تخصیص کند است، و اگر ماسیف بتواند به محض یافتن مدخلی که مطابقت ندارد جستجو در مدخلهای ردگیری پشته را متوقف کند، زمان بسیار زیادی صرفهجویی میشود تا اینکه مجبور باشد تمام مدخلها را پیمایش کند.
توجه داشته باشید که نامهای ++C به صورت demangle شده (نامهای اصلی پیش از درهمریزی) هستند. همچنین توجه داشته باشید که نامهای چندریختی (overloaded) در ++C باید به طور کامل نوشته شوند. ممکن است استفاده از نقلقولهای تکی برای جلوگیری از تفکیک آنها توسط شل لازم باشد. برای مثال:
--alloc-fn='operator new(unsigned, std::nothrow_t const&)'
آرگومانهایی از نوع size_t باید در بسترهای ۶۴ بیتی با unsigned long و در بسترهای ۳۲ بیتی با unsigned جایگزین شوند.
گزینه --alloc-fn با توابع درونخطی (inline) نیز کار خواهد کرد. نامهای توابع درونخطی درهمریخته (mangled) نمیشوند، به این معنی که فقط باید نام تابع را مشخص کنید و نیازی به ذکر فهرست آرگومانها نیست.
گزینه --alloc-fn از نویسههای عام (wildcards) پشتیبانی نمیکند.
--ignore-fn=<name>
هرگونه realloc بر روی یک بلوک نادیدهگرفتهشده نیز نادیده گرفته خواهد شد، حتی اگر فراخوانی realloc در یک تابع نادیدهگرفتهشده رخ ندهد. این کار از احتمال منفی شدن اندازه هیپ در صورتی که بلوکهای نادیدهگرفتهشده با realloc کوچک شوند، جلوگیری میکند.
قوانین نوشتن نام توابع ++C همانند قوانین مربوط به --alloc-fn در بالا است.
--threshold=<m.n> [default: 1.0]
--peak-inaccuracy=<m.n> [default: 1.0]
--time-unit=<i|ms|B> [default: i]
--detailed-freq=<n> [default: 10]
--max-snapshots=<n> [default: 100]
--massif-out-file=<file> [default: massif.out.%p]
گزینههای بیبیوی (BBV OPTIONS)
--bb-out-file=<name> [default: bb.out.%p]
--pc-out-file=<name> [default: pc.out.%p]
--interval-size=<number> [default: 100000000]
--instr-count-only [default: no]
گزینههای لاکی (LACKEY OPTIONS)
--basic-counts=<no|yes> [default: yes]
--detailed-counts=<no|yes> [default: no]
--trace-mem=<no|yes> [default: no]
--trace-superblocks=<no|yes> [default: no]
--fnname=<name> [default: main]
دباگاینفود (DEBUGINFOD)
والگریند از بارگیری فایلهای اطلاعات اشکالزدایی (debuginfo) از طریق debuginfod پشتیبانی میکند؛ یک کارساز HTTP برای توزیع اطلاعات اشکالزدایی ELF/DWARF. هنگامی که یک فایل debuginfo را نتوان به صورت محلی پیدا کرد، والگریند میتواند با استفاده از شناسه ساخت (build-id) فایل، از کارسازهای debuginfod برای دریافت آن فایل استعلام بگیرد.
به منظور استفاده از این قابلیت، باید debuginfod-find نصب شده باشد و متغیر محیطی $DEBUGINFOD_URLS حاوی نشانیهای وب (URLهای) کارسازهای debuginfod باشد که با فاصله از یکدیگر جدا شدهاند. والگریند از خروجی پرجزئیات debuginfod-find که معمولاً با $DEBUGINFOD_PROGRESS و $DEBUGINFOD_VERBOSE فعال میشود پشتیبانی نمیکند. این متغیرهای محیطی نادیده گرفته خواهند شد. این قابلیت تنها بر روی لینوکس پشتیبانی میشود.
برای کسب اطلاعات بیشتر پیرامون debuginfod، بخش Elfutils Debuginfod[1] را ببینید.
همچنین ببینید (SEE ALSO)
cg_annotate(1), callgrind_annotate(1), callgrind_control(1), ms_print(1), $INSTALL/share/doc/valgrind/html/index.html یا http://www.valgrind.org/docs/manual/index.html, Debugging your program using Valgrind's gdbserver and GDB[2] vgdb[3], Valgrind monitor commands[4], The Commentary[5], Scheduling and Multi-Thread Performance[6], Cachegrind: a cache and branch-prediction profiler[7]. Execution Trees[8]
نویسنده (AUTHOR)
برای مشاهده فهرست جامع نویسندگان، فایل AUTHORS را در توزیع والگریند ببینید.
این صفحه راهنما توسط Andres Roldan <aroldan@debian.org> و توسعهدهندگان والگریند نوشته شده است.
یادداشتها (NOTES)
- 1.
- Elfutils Debuginfod
- 2.
- Debugging your program using Valgrind's gdbserver and GDB
- 3.
- vgdb
- 4.
- Valgrind monitor commands
- 5.
- The Commentary
- 6.
- Scheduling and Multi-Thread Performance
- 7.
- Cachegrind: a cache and branch-prediction profiler
- 8.
- Execution Trees
| 08/11/2026 | Release 3.25.1 |