ماذا تعني رسالة التتبع العكسي لـ GDB "0x0000000000000000 في ؟؟()" يقصد؟

Question

ماذا يعني عندما يعطي أثرًا خلفيًا بالمخرجات التالية؟

#0  0x00000008009c991c in pthread_testcancel () from /lib/libpthread.so.2
#1  0x00000008009b8120 in sigaction () from /lib/libpthread.so.2
#2  0x00000008009c211a in pthread_mutexattr_init () from /lib/libpthread.so.2
#3  0x0000000000000000 in ?? ()

لقد تعطل البرنامج بسبب الإشارة القياسية 11، خطأ التجزئة.تطبيقي عبارة عن برنامج FastCGI C++ متعدد الخيوط يعمل على FreeBSD 6.3، باستخدام pthread كمكتبة ترابط.

لقد تم تجميعه باستخدام -g وتم تحميل كافة جداول الرموز الخاصة بالمصدر الخاص بي، وفقًا لمصادر المعلومات.

كما هو واضح، لا يظهر أي من التعليمات البرمجية الفعلية الخاصة بي في التتبع ولكن بدلاً من ذلك يبدو أن الخطأ نشأ من مكتبات pthread القياسية.وعلى وجه الخصوص ما هو؟؟() ؟؟؟؟

يحرر:في النهاية قمت بتتبع التعطل وصولاً إلى وصول قياسي غير صالح للذاكرة في الكود الرئيسي الخاص بي.لا يفسر سبب تلف تتبع المكدس، ولكن هذا سؤال ليوم آخر :)

Answer 1

لم يتمكن gdb من استخراج عنوان الإرجاع المناسب من pthread_mutexattr_init؛حصلت على عنوان 0.ال "؟؟" هو نتيجة البحث عن العنوان 0 في جدول الرمز.لا يمكنه العثور على اسم رمزي، لذلك يقوم بطباعة الافتراضي "؟؟"

لسوء الحظ، لا أعرف لماذا لم يتمكن من استخراج عنوان المرسل الصحيح.

Answer 2

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

Answer 3

تأكد من تجميع رموز التصحيح.(بالنسبة لدول مجلس التعاون الخليجي أعتقد أن هذا هو الخيار -g).إذن يجب أن تكون قادرًا على الحصول على معلومات أكثر إثارة للاهتمام من GDB.لا تنس إيقاف تشغيله عند تجميع إصدار الإنتاج.

Answer 4

من الممكن أن أفتقد شيئًا ما، لكن ألا يدل هذا على استخدام شخص ما NULL كمؤشر وظيفة؟

#include <stdio.h>

typedef int (*funcptr)(void);

int
func_caller(funcptr f)
{
    return (*f)();
}

int
main()
{
    return func_caller(NULL);
}

ينتج عن ذلك نفس نمط التتبع الخلفي إذا قمت بتشغيله في gdb:

rivendell$ gcc -g -O0 foo.c -o foo
rivendell$ gdb --quiet foo
Reading symbols for shared libraries .. done
(gdb) r
Starting program: ...
Reading symbols for shared libraries . done

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000000
0x00000000 in ?? ()
(gdb) bt
#0    0x00000000 in ?? ()
#1    0x00001f9d in func_caller (f=0) at foo.c:8
#2    0x00001fb1 in main () at foo.c:14

على الرغم من أن هذا حادث تحطم غريب جدًا ... pthread_mutexattr_init نادرًا ما يفعل أي شيء أكثر من تخصيص بنية البيانات و memset هو - هي.سأبحث عن شيء آخر يحدث.هل هناك احتمال لوجود مكتبات ترابط غير متطابقة أو شيء من هذا القبيل.معرفتي بـ BSD قديمة بعض الشيء، ولكن كانت هناك مشكلات حول هذا الأمر.

Answer 5

ربما يكون الخطأ الذي تسبب في العطل قد أدى إلى كسر المكدس (الأجزاء التي تم استبدالها بالمكدس)؟في هذه الحالة، قد يكون التتبع الخلفي عديم الفائدة؛لا فكرة عما يجب فعله في هذه الحالة..