لا يجب أن يكون تعطل التطبيق هذا هو نهاية الرحلة! تعلم أساسيات استخدام GDB ، مصحح جنو القوي وتعرف على كيفية تصحيح أخطاء تفريغ النواة على لينكس. مثالية للمستخدمين النهائيين وتصحيح أخطاء القادمين الجدد على حد سواء.
ما هو GDB ؟
أداة GDB هي أداة تصحيح أخطاء قديمة ومحترمة للغاية في Linux GNU Toolset. يوفر سطر الأوامر الخاص به ، ومجموعة واسعة من الأوامر والوظائف ، وتنفيذ البرنامج خطوة بخطوة (رمز الكمبيوتر) وحتى وظائف التعديل.
بدأ التطوير على GDB في مكان ما في 1986-1988 ، وفي عام 1988 أصبحت الأداة جزءًا من مؤسسة البرمجيات الحرة. إنه مجاني تمامًا ويمكن تثبيته بسهولة على جميع توزيعات Linux الرئيسية.
إذا كنت تستخدم Windows ، فقد ترغب في قراءة Windows Memory Dumps: ما هي بالضبط؟ في حين أن!
هذا موقف شائع ، وسيجد معظم المستخدمين المتقدمين في وقت أو آخر أنفسهم يقومون بتصحيح أخطاء التطبيق. تساعد معرفة GDB بشكل كبير في هذه المهمة. المزيد عن هذا أدناه.
ما هو التفريغ الأساسي ؟
إذا سبق لك أن شاهدت Star Trek وسمعت الكابتن Picard (أو Janeway!) يعطي تعليمات لـ “تفريغ قلب الاعوجاج” ، فستحصل على صورة جيدة إلى حد ما لما قد يبدو عليه تفريغ النواة. كان في الأساس المكون الأساسي (جوهر الاعوجاج) الذي تم إخراجه نتيجة لبعض الفشل أو المشكلة المتصورة. كان من المحتمل أن يكون ذلك بمثابة لعبة تورية على إغراق نواة Linux.
بغض النظر عن المتعة ، فإن تفريغ النواة هو ببساطة ملف تم إنشاؤه بالحالة (الكاملة أو الجزئية) (والذاكرة) لتطبيق ما ، في وقت تعطله.
تثبيت GDB
لتثبيت GDB على توزيعة Linux القائمة على Debian / Apt (مثل Ubuntu و Mint) ، قم بتنفيذ الأمر التالي في جهازك:
sudo apt install gdb
لتثبيت GDB على توزيعة Linux التي تستند إلى RedHat / Yum (مثل RHEL و Centos و Fedora) ، قم بتنفيذ الأمر التالي في جهازك:
sudo yum install gdb
مواقع التفريغ الأساسية وإمكانية إعادة الإنتاج
بمجرد تمكين عمليات التفريغ الأساسية وتثبيت GDB ، فقد حان الوقت للعثور على ملف التفريغ الأساسي وقراءته (الملف الذي تم إنشاؤه بواسطة نظام التشغيل عند تعطل تطبيقك) باستخدام GDB.
إذا قمت بتكوين نظامك لتفريغ النواة بعد تعطل التطبيق الخاص بك ، فمن المحتمل إلى حد ما أنه لا يوجد تفريغ أساسي متاح للعطل السابق. حاول واتبع نفس الخطوات في التطبيق الخاص بك لإعادة إنتاج الأعطال / المشكلات.
بمجرد حدوث ذلك ، تحقق من الموقع الافتراضي لتفريغ النواة على توزيع Linux الخاص بك (مثل /var/crashأو /var/lib/systemd/coredump/على Ubuntu / Mint و Centos أو /var/spool/abrtعلى RedHat). بشكل منتظم ، وفي بعض الأحيان اعتمادًا على الإعدادات التي تم إجراؤها ، قد يتم أيضًا كتابة ملف تفريغ أساسي في الدليل حيث يوجد الملف الثنائي (التطبيق) (على الأرجح) ، أو إلى دليل العمل الرئيسي (أقل احتمالًا إلى حد ما).
أخيرًا ، نحن نتعامل مع تطبيق معطل في حالة غير معروفة ، وليس من الممكن دائمًا كتابة مثل هذه الحالة على القرص. من الإنصاف القول إن المرء قد يتوقع قضاء بعض الوقت في جعل الإغراق الأساسي يعمل بشكل موثوق ومستمر على نظام معين. ثم يقودنا هذا إلى موضوع إعادة إنتاج المشكلة.
قراءة Core Dump مع GDB
الآن بعد أن أصبح لديك تفريغ أساسي متاح لتطبيق معطل معين ، وقمت بتثبيت GDB ، يمكنك بسهولة استدعاء GDB:
gdb ./myapp ./core
هنا لدينا تطبيق يسمى myappالذي يتعطل بمجرد بدء تشغيله. في نظام Ubuntu هذا ، تم تمكين عمليات التفريغ الأساسية ببساطة عن طريق تعيين ulimit -cرقم أعلى كجذر ثم بدء تشغيل التطبيق. والنتيجة هي تفريغ أساسي تم إنشاؤه كـ ./core.
نستدعي gdb بخيارين. الخيار الأول هو التطبيق / الثنائي / القابل للتنفيذ الذي تسبب في حدوث عطل. والثاني هو التفريغ الأساسي الناتج عن نظام التشغيل نتيجة تعطل التطبيق.
التحليل الأولي للتفريغ الأساسي
عندما يبدأ GDB ، كما يتضح من إخراج GDB في الصورة أعلاه ، فإنه يوفر عددًا كبيرًا من المعلومات. يمكن أن توفر لنا المراجعة الدقيقة لهذا الأمر الكثير من المعلومات حول المشكلة التي واجهها نظامك والتي أدت إلى تعطل التطبيق.
على سبيل المثال ، نلاحظ على الفور أن البرنامج تم إنهاؤه بسبب SIGFPEخطأ ، وهو استثناء حسابي. نؤكد أيضًا أن GDB قد حددت الملف التنفيذي بشكل صحيح من خلال Core was generated by `./myapp'السطر.
نرى أيضًا السطر / الفكرة المثيرة للاهتمام No debugging symbols found in ./myappالتي تشير إلى أن رموز التصحيح لا يمكن قراءتها من البرنامج الثنائي للتطبيق. رموز التصحيح هي المكان الذي يمكن أن تصبح فيه الأشياء غامضة بسرعة. معظم الثنائيات المحسّنة / مستوى الإصدار (والتي ستكون معظم التطبيقات التي تقوم بتشغيلها يومًا بعد يوم) ستحتوي على معلومات رمز تصحيح الأخطاء من الملف الثنائي الناتج لتوفير مساحة وزيادة أوقات تشغيل التطبيق / كفاءة العمل.
اعتمادًا على مقدار ما تم تجريده من optimizedالثنائي الناتج ، حتى أسماء الوظائف البسيطة قد لا تكون متاحة. في حالتنا ، لا تزال أسماء الوظائف مرئية ، كما يمكن ملاحظته من do_the_maths()مرجع اسم الوظيفة. ومع ذلك ، لا توجد متغيرات مرئية وهذا ما كان يشير إليه GDB No debugging symbols found in ./myappبالملاحظة. عندما لا تتوفر أسماء الوظائف ، سيتم عرض مراجع اسم الوظيفة ??بدلاً من اسم الوظيفة.
يمكننا أن نرى إلا ما هو تحطمها اسم إطار / وظيفة: #0 do_the_maths(). قد تتساءل ما هو الإطار . أفضل طريقة لوصف الإطار والتفكير فيه هي التفكير في الوظائف ، على سبيل المثال do_the_maths()، في برنامج كمبيوتر. الإطار الفردي هو وظيفة واحدة.
وبالتالي ، إذا كان البرنامج يتقدم عبر وظائف مختلفة ، على سبيل المثال main()الوظيفة في برنامج C أو C ++ والتي بدورها قد تستدعي وظيفة تسمى math_function()والتي do_the_maths()ستؤدي في النهاية إلى ثلاثة إطارات ، مع الإطار #0( الإطار النهائي الناتج والإطار المتعطل) هو do_the_maths()الوظيفة ، يكون الإطار #1هو math_function()والإطار رقم 2 (أول إطار يسمى ، مع أعلى رقم) هو main()الوظيفة.
ليس من غير المألوف رؤية 10-20 إطارًا stackفي بعض برامج الكمبيوتر ، ومن stackالممكن جدًا وجود 40 أو 50 إطارًا عرضيًا في برامج قواعد البيانات على سبيل المثال. لاحظ أن ترتيب الإطارات معكوس ؛ تحطم الإطار برقم الإطار #0أولاً ، ثم الانتقال من هناك إلى الإطار الأول. هذا منطقي عندما تفكر من منظور مصحح الأخطاء / تفريغ النواة ؛ لقد بدأت من النقطة التي تحطمت فيها ، ثم عملت على العودة إلى الإطارات على طول الطريق إلى main()الوظيفة.
يجب أن يكون مصطلح مكدس الإطار الآن أكثر وضوحًا ؛ كومة من الإطارات ، من الأكثر تحديدًا (أي do_the_maths) إلى الأقل تحديدًا (أي main()) والتي ستوجهنا في تقييم ما حدث. لذا ، هل يمكننا رؤية مكدس المكدس / الإطارات هذا في GDB لمشكلتنا الحالية؟ نحن بالتأكيد نستطيع.
وقت التتبع الخلفي!
بمجرد وصولنا إلى موجه gdb ، يمكننا إصدار btأمر backtrace . سيقوم هذا الأمر – بالنسبة إلى الخيط الحالي فقط (والذي غالبًا ما يكون الخيط المتعطل ؛ يكتشف GDB تلقائيًا الخيوط المتعطلة ويضعنا تلقائيًا في هذا الخيط ، على الرغم من أنه لا يتم تصحيحه دائمًا) – تفريغ التتبع الخلفي للإطار المكدس ، الذي ناقشناه أعلاه. بعبارة أخرى ، سنتمكن من رؤية الوظائف المتدفقة التي مر بها البرنامج حتى لحظة تعطله.
هنا قمنا بتنفيذ btالأمر ، والذي يعطينا مكدس استدعاء لطيف ، أو مكدس إطارات ، أو مكدس ، أو تتبع خلفي – مهما كانت الكلمة التي تفضلها ، فكلها تعني نفس الشيء تمامًا. يمكننا أن نرى ما main()يسمى math_functionبدوره يسمى do_the_maths()الوظيفة.
كما نرى ، لا يتم عرض أسماء المتغيرات في هذا الإخراج المحدد ، وقد أبلغنا GDB أن رموز التصحيح غير متوفرة. على الرغم من أن الملف الثنائي الناتج لا يزال يحتوي على مستوى معين من معلومات التصحيح ، حيث تم عرض جميع أسماء الإطارات / الوظائف بشكل صحيح ولم يتم عرض أي إطارات كـ ??.
لذلك أعدت ترجمة التطبيق من المصدر باستخدام -ggdbالخيار إلى gcc(كما في gcc -ggdb ...) ولاحظ كيف يتوفر المزيد من المعلومات:
هذه المرة يمكننا أن نرى بوضوح أن GDB يقرأ الرموز (كما هو موضح بواسطة Reading symbols from ./myapp...) ، وأنه يمكننا رؤية أسماء المتغيرات مثل xو y. شريطة أن يتوفر كود المصدر ، يمكننا حتى رؤية سطر كود المصدر الدقيق حيث حدثت المشكلة (كما هو مشار إليه 3 o=x/y;). يمكننا أيضًا رؤية خطوط التعليمات البرمجية المصدر لجميع الإطارات.
عند دراسة المخرجات قليلاً ، ندرك على الفور الخطأ. متغير oويتم تعيين إلى متغير xيجري تقسيمها من قبل y. ومع ذلك ، عند النظر عن كثب إلى مدخلات الوظيفة (كما هو موضح بواسطة (x=1, y=0)) ، نرى أن التطبيق حاول قسمة رقم على صفر ، وهو أمر مستحيل رياضي ، مما أدى إلى SIGFPEإشارة (استثناء حسابي).
وبالتالي فإن مشكلتنا لا تختلف عن الكتابة 1مقسومة 0على الآلة الحاسبة الخاصة بك ؛ هو أيضا سوف يشتكي ، وإن لم يتحطم