मैं pstack का उपयोग सोलारिससोलारिस कोर डंप विश्लेषण
में कोर डंप फ़ाइलों का विश्लेषण करने के मैं सोलारिस से कोर डंप और कैसे विश्लेषण कर सकते हैं?
ऐसा करने के लिए किन आदेशों का उपयोग किया जा सकता है?
डंप से अन्य जानकारी क्या उपलब्ध होगी?
आप सोलारिस मॉड्यूलर डीबगर, एमडीबी, या डीबीएक्स का उपयोग कर सकते हैं। एमडीबी SUNWmdb (या 64 बिट्स संस्करण के लिए SUNWmdb एक्स) पैकेज के साथ आता है।
एक कोर फ़ाइल क्रैश होने पर आपकी चल रही प्रक्रिया की छवि है।
इस पर निर्भर करता है कि आपका एप्लिकेशन डीबग झंडे के साथ संकलित किया गया था या नहीं, तो आप स्टैक की एक छवि को देखने में सक्षम होंगे, इसलिए यह जानने के लिए कि कौन सा फ़ंक्शन कोर का कारण बनता है, उस पैरामीटर का मान प्राप्त करने के लिए फ़ंक्शन, वेरिएबल्स का मान, आवंटित मेमोरी जोन ...
हाल के सौर संस्करणों पर, आप कॉन्फ़िगर कर सकते हैं कि मूल फ़ाइल कोरडम कमांड के साथ क्या होगी; उदाहरण के लिए, आपके पास मैप किए गए मेमोरी सेगमेंट हो सकते हैं, प्रक्रिया को संलग्न किया गया था।
MDB documentation और dbx documentation का संदर्भ लें। एक बार जब आप जीडीबी की मूल बातें जानते हैं तो GDB quick reference कार्ड भी सहायक होता है।
जीडीबी का उपयोग किया जा सकता है।
यह डंप से पहले किए गए कॉल को दे सकता है।
http://en.wikipedia.org/wiki/GDB
होने स्रोत महान है और अगर आप त्रुटियों और भी बेहतर प्रजनन कर सकते हैं जैसा कि आप इस का उपयोग कर सकते यह डिबग करने के लिए।
अतीत में मेरे लिए बहुत अच्छा काम किया।
pflags कमांड राज्य को निर्धारित करने के लिए भी उपयोगी होता है जब प्रत्येक थ्रेड कोर डंप किया जाता है। इस तरह आप अक्सर समस्या को इंगित कर सकते हैं।
dbx [executable_file_name] [coredump_file_name]
यह निष्पादन के लिए कोई परिवर्तन नहीं थे के बाद से कोर फेंक दिया गया था महत्वपूर्ण है (यानी यह नहीं था:
dbx डिबगर का उपयोग कर प्रक्रिया छवि के लिए संलग्न टी पुनर्निर्मित)।
आप यह देखने के लिए स्टैक ट्रेस देख सकते हैं कि प्रोग्राम dbx कमांड "कहां" के साथ दुर्घटनाग्रस्त हो गया है।
आप "अप" और "डाउन" कमांड के साथ स्टैक को ऊपर और नीचे ले जा सकते हैं, या "फ्रेम" संख्या "के साथ सटीक स्टैक फ्रेम पर कूद सकते हैं," जहां "के आउटपुट में देखे गए नंबरों के साथ।
आप "प्रिंट [expr]" कमांड के साथ चर या अभिव्यक्तियों के मान को प्रिंट कर सकते हैं।
मज़े करें।
यदि कोर डंप आपके द्वारा लिखे गए या बनाए गए प्रोग्राम से है, तो जो भी डीबगर आप आम तौर पर चल रहे एप्लिकेशन को डीबग करने के लिए उपयोग करेंगे, उसका उपयोग करें। वे सभी कोर फाइलों को लोड करने में सक्षम होना चाहिए। यदि आप डिबगर्स के बारे में पसंद नहीं करते हैं, और आप सोलारिस का उपयोग कर रहे हैं, तो मैं डीबीएक्स की सिफारिश करूंगा। इससे पैच के साथ सन स्टूडियो का नवीनतम एफसीएस संस्करण, या फिर सन स्टूडियो का नवीनतम एक्सप्रेस संस्करण प्राप्त करने में मदद मिलेगी। यह भी बहुत उपयोगी है अगर आप कोर फ़ाइल को उसी सिस्टम पर डीबगर में लोड कर सकते हैं जहां मूल फ़ाइल बनाई गई थी। यदि पुस्तकालयों में कोड कोर फ़ाइल बनने से अलग होता है, तो पुस्तकालयों के माध्यम से स्टैक ट्रेस उपयोगी नहीं होगा। डिबगर्स भी libthread और रनटाइम लिंकर डेटा संरचनाओं को समझने के लिए ओएस हेल्पर पुस्तकालयों का उपयोग करते हैं, इसलिए यदि आपको कोर फ़ाइल को एक अलग मशीन पर लोड करने की आवश्यकता है, तो आप यह सुनिश्चित करना चाहते हैं कि ओएस पर स्थापित सहायक लाइब्रेरी सिस्टम डेटा संरचनाओं से मेल खाते हैं ओएस आप कुछ साल पहले लिखे गए एक श्वेत पत्र में इन सिस्टम पुस्तकालयों के बारे में कभी भी जानना नहीं चाहते थे।
http://developers.sun.com/solaris/articles/DebugLibraries/DebugLibraries_content.html
pstack काम पूरा हो जाता है। –
मुझे लगता है कि इस सवाल का कोई भी जवाब एक सरल नुस्खा साथ शुरू करना चाहिए:
dbx के लिए, नुस्खा है:
% dbx a.out core
(dbx) where
(dbx) threads
(dbx) thread [email protected]
(dbx) where
मैं पर मेरे सोलारिस 86 बॉक्स पर dbx पाया
/opt/SUNWspro/bin/dbx
चीयर्स!
मैं पहले जीडीबी की कोशिश करने का सुझाव दूंगा क्योंकि मेरी राय में मूल सोलारिस डीबगर्स की तुलना में बुनियादी कार्यों को सीखना आसान है।
सोलार्स मॉड्यूलर डीबगर शानदार है और जब libumem के साथ उपयोग किया जाता है तो यह एक बहुत ही शक्तिशाली टूल है। http://blogs.sun.com/pnayak/entry/finding_memory_leaks_within_solaris – Matt
यह ब्लॉग आपको सोलारिस में एक कॉर्डम्प का विश्लेषण करने के लिए एमडीबी का उपयोग करने में मदद करता है: http://cuddletech.com/blog/pivot/entry.php?id=965 –