كيف كشف تحليل تفريغات الذاكرة عطلين نادرين في بنية OpenAI
حلل مهندسو OpenAI مجموعة واسعة من أعطال الخوادم، ففصلوا بين خلل عتادي في مضيف واحد وسباق برمجي قديم في مكتبة GNU libunwind.
كيف كشف تحليل تفريغات الذاكرة عطلين نادرين في بنية OpenAI
حلل مهندسو OpenAI مجموعة واسعة من أعطال الخوادم، ففصلوا بين خلل عتادي في مضيف واحد وسباق برمجي قديم في مكتبة GNU libunwind.
عطل بدا مستحيلًا
واجه مهندسو OpenAI انهيارات نادرة داخل خدمات مكتوبة بلغة C++ ضمن بنية بيانات Rockset. كانت بعض العمليات تعود إلى عنوان غير صالح، بينما ظهر في حالات أخرى اختلال بمقدار ثمانية بايتات في مؤشر المكدس. ولم تكن الفرضيات المعتادة تفسر النمطين معًا.
البيانات فصلت بين مشكلتين
بدل الاستمرار في تحليل عينات منفردة، جمع الفريق بيانات واسعة من تفريغات الذاكرة وسجلات الأعطال. أظهر التصنيف أن ما بدا عطلًا واحدًا كان مجموعتين مستقلتين: فسادًا عتاديًا صامتًا في معالج أحد مضيفي Azure، وسباقًا برمجيًا نادرًا في GNU libunwind.
لماذا ظهر خطأ عمره أكثر من 18 عامًا؟
كان السباق موجودًا منذ أول إصدار x86_64 من المكتبة يدعم فك استثناءات C++، لكنه احتاج تزامنًا دقيقًا بين معالجة الإشارات وفك المكدس. معدل الاستثناءات والإشارات المرتفع في خدمة Rockset جعل النافذة النادرة تتكرر بما يكفي لتصبح قابلة للرصد على نطاق الأسطول.
الدرس الهندسي
لا يقدم التحقيق ميزة جديدة للمستخدمين، ولا يعني اكتشاف ثغرة أمنية في نماذج OpenAI. أهميته أنه يوضح كيف يمكن لجمع بيانات أعطال متسقة على نطاق واسع أن يفصل بين أسباب متشابهة ظاهريًا ويحوّل مشكلة غامضة إلى تشخيص قابل للاختبار والإصلاح.
المصادر والتحقق
حالة التحقق: متحقق · درجة الثقة: 98%
المصدر الأصلي