2011-11-24 20 views
7

हमारे पास एक एमआईपी कोर पर चल रहे लिनक्स कर्नेल का एक एम्बेडेड संस्करण है। हमने जो कार्यक्रम लिखा है वह एक विशेष परीक्षण सूट चलाता है। तनाव परीक्षणों में से एक के दौरान (लगभग 12 घंटे तक चलता है) हमें सीजी गलती मिलती है। यह बदले में कोर डंप उत्पन्न करता है।लिनक्स को सी प्रोग्राम में क्रैश होने पर बेहतर डीबग प्राप्त करना

दुर्भाग्यवश कोर डंप बहुत उपयोगी नहीं है। क्रैश कुछ सिस्टम लाइब्रेरी में है जो गतिशील रूप से जुड़ा हुआ है (शायद pthread या glibc)। क्योंकि यह केवल दुर्घटना बिंदु पता चलता है और कोई अन्य कॉल कोर डंप में पश्व-अनुरेखन उपयोगी नहीं है (हमारे उपयोगकर्ता अंतरिक्ष अनुप्रयोग जी -O0 साथ बनाया गया है, लेकिन अभी भी कोई वापस ट्रेस जानकारी):

Cannot access memory at address 0x2aab1004 
(gdb) bt 
#0 0x2ab05d18 in ??() 
warning: GDB can't find the start of the function at 0x2ab05d18. 

    GDB is unable to find the start of the function at 0x2ab05d18 
and thus can't determine the size of that function's stack frame. 
This means that GDB may be unable to access that stack frame, or 
the frames below it. 
    This problem is most likely caused by an invalid program counter or 
stack pointer. 
    However, if you think GDB should simply search farther back 
from 0x2ab05d18 for code which looks like the beginning of a 
function, you can increase the range of the search using the `set 
heuristic-fence-post' command. 

एक और दुर्भाग्यपूर्ण -नेस यह है कि हम gdb/gdbserver नहीं चला सकते हैं। gdb/gdbserver __nptl_create_event पर तोड़ता रहता है। यह देखते हुए कि परीक्षण धागे, टाइमर बनाता है और हर 5s को नष्ट करता है, उन पर जारी रखने के लिए लंबे समय तक बैठना लगभग असंभव है।

संपादित करें: एक और नोट, बैकट्रैक और बैकट्रैक_सिम्बोल्स हमारे टूलचेन पर समर्थित नहीं है।

इसलिए

:

  1. वहाँ SEG गलती और अधिक पश्व-अनुरेखन डेटा उत्पन्न, ढेर संकेत, कॉल स्टैक, आदि फँसाने का एक तरीका है?

  2. क्या कोई .so फ़ाइल में क्रैश होने वाले कोर डंप से अधिक डेटा प्राप्त करने का कोई तरीका है?

धन्यवाद।

+0

यदि संभव हो तो आप 'SIGSEGV 'को संभालने का प्रयास कर सकते हैं? इसकी कभी सिफारिश नहीं की जाती है, लेकिन मुझे लगता है कि इस स्थिति में आपकी मदद कर सकता है। – Stark07

उत्तर

1

यदि अन्य सभी विफलता डीबगर का उपयोग कर कमांड चलाते हैं!

बस अपने सामान्य प्रारंभ कमांड के रूप में "gdb" डालें और प्रक्रिया को चलाने के लिए "c" ontinue दर्ज करें। जब कार्य segfaults यह कोर डंप के बजाय इंटरैक्टिव जीडीबी संकेत पर वापस आ जाएगा। इसके बाद आपको अधिक सार्थक स्टैक निशान आदि प्राप्त करने में सक्षम होना चाहिए।

एक और विकल्प "ट्रस" का उपयोग करना है यदि यह उपलब्ध हो। यह आपको बताएगा कि अपमान के समय कौन सी सिस्टम कॉल का इस्तेमाल किया जा रहा था।

+0

मुझे लगता है कि यह संभव नहीं है। कार्यक्रम एम्बेडेड सिस्टम पर चल रहा है, और पूछने वाले ने gdberver के साथ gdb का उपयोग करने का प्रयास कर लिया है। – daxelrod

+0

उम्म, जितना मैं 'सी' को धक्का देने का आनंद लेता हूं, इसके परिणामस्वरूप लगभग 8640 बार मुझे क्रैश होने से पहले 'सी' को धक्का देना होगा :) सोलारिस और लिनक्स के लिए ट्रस के बारे में मुझे एकमात्र चीज मिल सकती थी। जहां तक ​​मुझे पता है वहां स्ट्रेस वास्तव में यहां मदद नहीं करेगा। धन्यवाद। – user626201

+0

@ user626201 - सी = अगले ब्रेकपॉइंट तक जारी रखें। अपवाद की आवश्यकता होने तक कोई ब्रेकपॉइंट्स कोई संकेत नहीं देता है। –

1

GDB 0x2ab05d18

क्या क्रैश के समय जो उस पते पर है पर समारोह के शुरू होने से नहीं मिल सकता है?

info shared करें, और पता लगाएं कि उस पुस्तकालय में कोई पता है या नहीं।

आपकी परेशानियों का सबसे अधिक संभावित कारण: क्या आपने इसे अपने लक्ष्य पर अपलोड करने से पहले strip libpthread.so.0 चलाया था? ऐसा न करें: जीडीबी को libpthread.so.0 से को छीनने की आवश्यकता है। यदि आपके टूलचेन में libpthread.so.0 डीबग प्रतीकों (और इस प्रकार लक्ष्य के लिए बहुत बड़ा) है, तो strip -g चलाएं, पूर्ण strip पर नहीं।

अद्यतन:

info shared उत्पादित पते पर स्मृति तक नहीं पहुंच पा 0x2ab05d18

इसका मतलब है कि GDB साझा लाइब्रेरी सूची (जो तब गायब स्टैक ट्रेस की व्याख्या करता है) का उपयोग नहीं कर सकते हैं। सबसे सामान्य कारण: वास्तव में core उत्पादित द्विआधारी जीडीबी को दी गई बाइनरी से मेल नहीं खाती है। एक कम आम कारण: आपके कोर डंप को छोटा कर दिया गया था (शायद ulimit -c बहुत कम सेट होने के कारण)।

+0

हाय, साझा की गई जानकारी 'पता 0x2ab05d18' पर स्मृति तक नहीं पहुंच सकता है। हमने .so फ़ाइलों को छुआ नहीं है। – user626201

+0

यह सुनिश्चित नहीं है कि यह मायने रखता है लेकिन दूसरा रन पता को libc में दिखाता है: 'जानकारी साझा की गई से लेकर समानार्थी शब्द साझा करें लाइब्रेरी 0x2aaf7e70 0x2ab461f0 हां /opt/nfsroot_bcm97335_stblinux-2.6.18-7.7_be/lib/libc.so। 0' – user626201