تتبع فساد الذاكرة على خادم Linux الإنتاج

Question

الرجال، هل يمكن أن يوصي أداة لإظهار تلف الذاكرة على خادم إنتاج متعدد المراقب المدمج مع C ++ والعمل تحت Linux X86_64؟ أنا حاليا مواجهة المشكلة التالية: كل عدة ساعات تعطل الخادم الخاص بي مع segfault ويبلغ التفريغ الأساسي هذا الخطأ يحدث في malloc / calloc وهو بالتأكيد علامة على الذاكرة تالفة في مكان ما.

في الواقع لقد حاولت بالفعل بعض الأدوات دون الكثير من الحظ. هنا تجربتي حتى الآن:

• Valgrind هو أداة رائعة (كنت أفضل حتى أفضل) ولكنها تبطئ الخادم كثيرا مما يجعله غير قابل للاستخدام في الإنتاج. لقد جربته على خادم المرحلة وساعدني حقا في العثور على بعض المشكلات ذات الصلة بالذاكرة ولكن حتى بعد إصلاحها، ما زلت أحطم على خادم الإنتاج. ركضت خادم المرحلة تحت Valgrind لعدة ساعات ولكن لا يزال بإمكانك اكتشاف أي أخطاء خطيرة.

• يقال إن الكهرباء هو خنزير ذاكرة حقيقية لكنني لم أستطع حتى الحصول عليها بشكل صحيح. إنها Segfaults على الفور تقريبا على خادم المرحلة في أماكن غريبة عشوائية حيث لم تظهر Valgrind أي مشاكل على الإطلاق. ربما لا يدعم الكهرباء الخيوط جيدا؟ .. ليس لدي أي فكرة.

• دوما - نفس القصة كضاعة كهربائية ولكنها أسوأ. بينما أنتج EF مقالب الأساسية مع خبراء الدعم القابل للقراءة DUMA يظهر لي فقط "؟؟؟؟؟" (و Yes server مبني مع -g علم بالتأكيد)

• DMALLOC - قمت بتكوين الخادم لاستخدامه بدلا من إجراءات Malloc القياسية ومع ذلك، فإنه توقف بعد عدة دقائق. إرفاق GDB بالعملية تكشف أنه معلق في مكان ما في Dmalloc :(

أنا متدرج تدريجيا ولا أعرف ما يجب القيام به بعد ذلك. لدي الأدوات التالية التي يجب تجربتها: MTRACE، MPATLOL ولكن ربما شخص ما لديه فكرة أفضل؟

كنت أقدر بشكل كبير أي مساعدة في هذه المسألة.

تحديث: تمكنت من العثور على مصدر الخطأ. ومع ذلك، وجدت ذلك على خادم المرحلة وليس الإنتاج واحد باستخدام Helgrind / DRD / TSAN - كان هناك Datarace بين العديد من الخيوط التي أسفرت عن تلف الذاكرة. كان المفتاح هو استخدام إكمال Valgrind المناسب لأن هذه الأدوات أظهرت الكثير من الإيجابيات الخاطئة. ما زلت لا أعرف حقا كيف يمكن اكتشاف ذلك على خادم الإنتاج دون أي تباطؤ مهم ...

Answer 1

الناس، لقد تمكنت من العثور على مصدر الخطأ. ومع ذلك، وجدت أنه على خادم المرحلة باستخدام Helgrind / drd / Tsan - كان هناك Datarace بين العديد من المواضيع التي أسفرت عن تلف الذاكرة. كان المفتاح للاستخدام لائق تبرز Valgrind لأن هذه الأدوات أظهرت الكثير من الإيجابيات الخاطئة. ما زلت لا أعرف حقا كيف يمكن اكتشاف ذلك على خادم الإنتاج دون أي تباطؤ مهم ...

Answer 2

نعم، مشاكل فساد ذاكرة C / C ++ صعبة. واستخدمت أيضا عدة مرات Valgrind، وأحيانا كشفت المشكلة وأحيانا لا.

أثناء فحص إخراج Valgrind لا يميل إلى تجاهل نتائجه بسرعة كبيرة. في بعض الأحيان بعد أن أمضى وقت كبير، سترى أن Valgrind أعطاك فكرة في المقام الأول، لكنك تجاهلتها.

نصيحة أخرى هي مقارنة التغييرات في التعليمات البرمجية عن الإصدار المستقر المعروف سابقا. إنها ليست مشكلة إذا كنت تستخدم نوع من نظام النسخة المصدر (مثل SVN). فحص جميع الوظائف المتعلقة بالذاكرة (مثل MEMCPY، MemSet، Sprintf، جديد، حذف / حذف []).

Answer 3

ترجمة البرنامج الخاص بك مع دول مجلس التعاون الخليجي 4.1 ومفاتيح -Fstack - جميع التبديل. إذا كان يسبب تلف الذاكرة بسبب مكدس تحطيم هذا يجب أن يكون قادرا على اكتشافه. قد تحتاج إلى اللعب مع بعض المعلمات الإضافية لسمس.

Answer 4

هل حاولت -fmudflap.ب (قم بالتمرير فوق بعض الأسطر لرؤية الخيارات المتاحة).

Answer 5

يمكنك تجربة تنقية IBM، لكنني أخشى أن غير مفتوح ..

Answer 6

Google Perftools --- وهو مصدر مفتوح --- قد يكون من المساعدة، راجع مدقق كومة توثيق.

Answer 7

جرب هذه:http://www.hexco.de/rmdebug/لقد استخدمتها على نطاق واسع، لها تأثير منخفض في الأداء (معظمها يؤثر على كمية ذاكرة الوصول العشوائي في الغالب) ولكن خوارزمية التخصيص هي نفسها. ثبت دائما بما يكفي للعثور على أي أخطاء تخصيص. سيعطل البرنامج الخاص بك بمجرد حدوث الخطأ، ولديه سجل مفصل.

Answer 8

لست متأكدا مما إذا كان قد اشتعلت علة خاصة، ولكن MALLOC_CHECK_ متغيرات البيئة (malloc رجل صفحة) يتحول إلى فحص إضافي في Linux الافتراضي malloc التنفيذ، وعادة ما لا يكون لديك تكلفة وقت تشغيل كبير.