چطور یه باگ گزارش کنیم که واقعاً حل بشه
خلاصهٔ کاملتر
نویسنده این مقاله ماجرای یه باگ واقعی رو تعریف میکنه: لاگهای یه سرویس پروداکشن پر شده بودن از هشدار نشتی حافظه تو ByteBuf کتابخونهٔ Netty (کتابخونهٔ شبکهای که SDK آژور اوپنایآی روش ساخته شده). از همینجا نُه قدم برای رسیدن به یه گزارش باگ درستوحسابی رو مرحلهبهمرحله شرح میده.
قدم اول اینه که همیشه فرض کنی مشکل از کد خودته، نه کتابخونهای که هزاران شرکت دیگه هم ازش استفاده میکنن. قدم بعدی دترمینیستیککردن باگه: چون Netty فقط وقتی گاربجکالکتور یه بافر رو جمع میکنه نشتی رو گزارش میده، نویسنده صد درخواست همزمان اجرا کرد و بهصورت دستی System.gc() رو صدا زد تا نشتی همیشه قابل مشاهده بشه.
بعدش با تکنیک بایسکت (شبیه git bisect ولی روی نسخههای کتابخونه) بین نسخههای reactor-netty-http جلو و عقب رفت تا دقیقاً نسخهای که باگ توش شروع شده رو پیدا کرد. برای اثبات مستقل باگ، یه ریپازیتوری عمومی و کوچیک با یه تست ساده و نسخههای پینشده ساخت که هم مشکل رو بدون دادههای خصوصی نشون میداد، هم بعداً برای تأیید فیکس استفاده شد.
نویسنده میگه گزارش رو اول جایی ثبت کرد که شواهد نشونش میداد (reactor-netty)، و بعد از اینکه اونجا رد شد، ردش رو تا منبع واقعی یعنی SDK آژور برای جاوا دنبال کرد. قبل از گزارش نهایی هم تو تیکتهای قدیمی گشت و یه تغییر پنجماه قبل رو پیدا کرد که ظاهراً همین مشکل رو حل کرده بود ولی فقط خطاش رو خاموش کرده بود، نه خود نشتی رو. گزارش نهایی شامل ادعای دقیق، تاریخچه، لاگ کامل و همون ریپازیتوری تکرارپذیر بود.
به گفتهٔ نویسنده، همکاری با نگهدارندهها و صداقت تو جوابدادن به سوالهاشون باعث شد یه روز بعد فیکس نوشته بشه؛ خودش هم فیکس رو با همون ریپازیتوری تست کرد و بعد از انتشار نسخهٔ جدید، تو پروداکشن هم اعمالش کرد.
نکات کلیدی:
- نویسنده نشتی حافظه رو تو ByteBuf کتابخونهٔ Netty پیدا کرد که SDK آژور اوپنایآی روش ساخته شده
- با بایسکت بین نسخهها، نسخهٔ دقیق شروع باگ یعنی reactor-netty-http نسخهٔ 1.1.24 پیدا شد
- یه ریپازیتوری عمومی و کوچیک برای اثبات و بعداً تست فیکس ساخته شد
- گزارش نهایی تو تیکتردیاب SDK آژور برای جاوا ثبت شد و یه روز بعد فیکس اومد
- گشتن تو تیکتهای قدیمی (پنج ماه قبل) نشون داد یه فیکس قبلی فقط خطا رو خاموش کرده بود، نه خود نشتی رو
