कोर डंप किया गया, लेकिन कोर फ़ाइल वर्तमान निर्देशिका में नहीं है?

Question

C प्रोग्राम चलाते समय, यह कहता है "(कोर डंप किया गया") लेकिन मैं वर्तमान पथ के तहत कोई भी फाइल नहीं देख सकता।

मैंने सेट और सत्यापित किया है ulimit:

ulimit -c unlimited 
ulimit -a 

मैंने "कोर" नामक एक फ़ाइल खोजने की कोशिश की, लेकिन कोर डंप की गई फ़ाइल नहीं मिली?
कोई मदद, मेरी कोर फ़ाइल कहाँ है?

Comments

क्या कार्यक्रम कुछ बिंदु पर chdir आह्वान करता है? यदि हां, तो वहां देखें।

— विलियम पर्ससेल

क्या कार्यक्रम अपनी कार्यशील निर्देशिका को बदलता है? वहाँ देखो।

— रिचर्ड पेनिंगटन

मैं हाल ही की फ़ाइल के लिए पूरी हार्डड्राइव

— खोजूंगा

उफ़ नहीं इसकी कोई बात नहीं ... मैंने इसे चेक किया ..program chdir to / mnt और / i दोनों निर्देशिकाओं की जाँच की, लेकिन फ़ाइल नहीं मिली। मैंने भी पाया / / -नाम "* कोर।" यहां तक ​​कि इसने मुझे फाइल नहीं दिखाई। कार्यक्रम C + sqlite का उपयोग करता है, मूल्यों को सम्मिलित करते समय यह कोर डंप करता है। इसने कहा कि पहली बार त्रुटि == 0 और दूसरी बार त्रुटि = 101 ..

— webminal.org

हां, यदि आप /proc/sys/kernel/core_patternएक स्ट्रिंग के साथ ओवरराइड करते हैं /tmpतो उसी के साथ शुरू होता है, जहां आपका कोर डंप होगा।

— १४:४३ में

Answer 1

/Usr/src/linux/Documentation/sysctl/kernel.txt पढ़ें ।

[/ proc / sys / कर्नेल /] core_pattern का उपयोग कोर डंपफाइल पैटर्न नाम निर्दिष्ट करने के लिए किया जाता है।

• यदि पैटर्न का पहला वर्ण '|' है, तो कर्नेल को चलाने के लिए एक कमांड के रूप में बाकी पैटर्न का इलाज करेगा। कोर डंप को फ़ाइल के बजाय उस प्रोग्राम के मानक इनपुट पर लिखा जाएगा।

डिस्क पर कोर डंप लिखने के बजाय, आपके सिस्टम को abrtइसके बजाय कार्यक्रम में भेजने के लिए कॉन्फ़िगर किया गया है । स्वचालित बग रिपोर्टिंग टूल संभवतः उतना प्रलेखित नहीं है जितना इसे होना चाहिए ...

किसी भी मामले में, त्वरित उत्तर यह है कि आपको अपनी मूल फ़ाइल को खोजने में सक्षम होना चाहिए /var/cache/abrt, जहां abrtइसे लागू करने के बाद संग्रहीत किया जाता है। इसी तरह, Apport का उपयोग करने वाली अन्य प्रणालियाँ कोर को दूर /var/crashऔर इतने पर दूर कर सकती हैं ।

Comments

हाँ, मैंने निम्नलिखित सामग्री echo "core।% e।% p"> / proc / sys / kernel / core_pattern का अनुसरण करके core_pattern को संपादित किया है। यह वर्तमान निर्देशिका में कोर डंप फ़ाइल बनाता है। "core.giis.12344" नाम के साथ आदि। आपके उत्तर / टिप्पणी / संकेत के लिए आप सभी का धन्यवाद।

— webminal.org

बस ध्यान दें कि फेडोरा 18 abrt प्रोग्राम के /var/spool/abrt/बजाय कोर डंप्स का भंडारण किया जा रहा है/var/cache/abrt

— नेल्सन

क्या सिस्टम कॉन्फ़िगरेशन का उपयोग करने के बजाय उपयोगकर्ताओं को स्वयं के लिए इसे कॉन्फ़िगर करने की अनुमति देने का एक तरीका है?

— अल्लौरकोड

जब यह आदेश चलाया जाता है और प्रक्रिया को लागू किया जाता है, तो क्या stdout और stderr डिफ़ॉल्ट रूप से नहीं खोले जाते हैं? मैं बहुत अजीब चीजें घटित होते देखता हूं। जब मैं अपने कस्टम फ़ाइल (applog.txt) में stderr और stdout के d2 का उपयोग करता हूं, तो डेटा जिसे मैं अन्य फ़ाइल (mycore.BIN) में लिख रहा हूं, उस फ़ाइल को रीडायरेक्ट किया जा रहा है जिसे मैंने stdout और stderr (applog.txt) को पकड़ने के लिए उपयोग किया है । क्या इस बारे में एक अच्छा पढ़ा है? कृपया सुझाव दे। धन्यवाद

— mk ..

आर्कडिनक्स स्टोर कोरडम्प्स में सिस्टमड/var/lib/systemd/coredump/

— फ्रेंकोइस

Answer 2

हाल के उबंटू (मेरे मामले में 12.04) पर, "सेगमेंटेशन फ़ॉल्ट (कोर डंप किया गया)" मुद्रित होने के लिए संभव है, लेकिन कोई कोर फ़ाइल उत्पन्न नहीं हुई है जहाँ आप एक की उम्मीद कर सकते हैं (उदाहरण के लिए स्थानीय रूप से संकलित कार्यक्रम के लिए)।

ऐसा हो सकता है यदि आपके पास 0 (आप ऐसा नहीं किया है ulimit -c unlimited) का एक मुख्य फ़ाइल आकार ulimit है - यह उबंटू पर डिफ़ॉल्ट है। आम तौर पर कि दबाने होगा "(कोर फेंक दिया)", अपनी गलती में आप cluing, लेकिन Ubuntu पर, corefiles को पहुंचाया जाता है Apport (उबंटू के क्रैश रिपोर्टिंग प्रणाली) के माध्यम से /proc/sys/kernel/core_pattern, और इस भ्रामक संदेश का कारण बन रहा है।

यदि Apport को पता चलता है कि विचाराधीन प्रोग्राम वह नहीं है, जिसके लिए क्रैश रिपोर्ट हो रही हो (जिसके बारे में आप देख सकते हैं /var/log/apport.log), यह cwd में एक कोर फाइल डालने के डिफ़ॉल्ट कर्नेल व्यवहार का अनुकरण करने के लिए वापस आता है (यह स्क्रिप्ट में किया जाता है /usr/share/apport/apport)। इसमें उल्लिम को सम्मानित करना शामिल है, जिस स्थिति में यह कुछ भी नहीं करता है। लेकिन (मुझे लगता है) जहां तक ​​कर्नेल का संबंध है, एक कोरफाइल उत्पन्न हुआ था (और एपॉर्ट करने के लिए पाइप किया गया था), इसलिए संदेश "सेगमेंटेशन दोष (कोर डंप किया गया)"।

अल्टीमेट सेट करने की भूल करने के लिए अंततः PEBKAC, लेकिन भ्रामक संदेश ने मुझे यह सोच कर परेशान कर दिया कि मैं थोड़ी देर के लिए पागल हो रहा था, सोच रहा था कि मेरे कोरफाइल्स क्या खा रहे थे।

(इसके अलावा, सामान्य तौर पर, कोर (5) मैनुअल पेज - man 5 core- एक अच्छा संदर्भ है जहां आपकी कोर फाइल समाप्त हो जाती है और कारण यह नहीं लिखा जा सकता है।)

Comments

बहुत बहुत धन्यवाद - मैं उसी समस्या में भाग गया। Btw, उबंटू 14.04 ठीक उसी व्यवहार को प्रदर्शित करता है जैसा आपने वर्णित किया था।

— माल्टे स्कॉरुप्पा

मेरे उबंटू स्थापित (14.04 संशोधित) पर, इसे चलाने के द्वारा इसके लिए एक आसान अस्थायी समाधान है sudo service apport stop--- मैंने इसे चलाने के बाद, इसे /proc/sys/kernel/core_patternऐप्पोर्ट पाइप से बदल दिया core। Apport core_patternअस्थायी रूप से ठीक करने के लिए पर्याप्त स्मार्ट है , मुझे लगता है।

— पैट्रिक कोलिन्स

"ulimit -c unlimited" ठीक वही है जिसकी मुझे ज़रूरत थी - धन्यवाद!

— डेव सी

मैंने हर आदेश का जवाब देने की कोशिश की है, और हर टिप्पणी में हर स्थान के बाद यहाँ ulimit कमांड कर रहा है, लेकिन अभी भी मेरे Ubuntu 16.04 LTS पर कहीं भी एक कोर फ़ाइल नहीं मिल सकती है ...

— नागदेव

@ElectricGoat नहीं, मैंने नहीं। यह खराब है UX डिजाइन, IMO। सिस्टम को केवल पथ प्रिंट करना चाहिए, या किसी संदेश को प्रिंट नहीं करना चाहिए यदि यह नहीं बनाया जा रहा है। मैं अपना खुद का उत्तर जोड़ूंगा, जब या अगर मुझे आगे इसकी जांच करने का मौका मिलेगा।

— नगेव

Answer 3

Systemd के लॉन्च के साथ , वहाँ एक और परिदृश्य है। डिफॉल्ट सिस्टमड अपने जर्नल में कोर डिप्स को स्टोर करेगा, systemd-coredumpctlकमांड के साथ एक्सेस किया जा सकता है । Core_pattern- फाइल में परिभाषित:

$ cat /proc/sys/kernel/core_pattern 
|/usr/lib/systemd/systemd-coredump %p %u %g %s %t %e

यह व्यवहार एक सरल "हैक" के साथ अक्षम किया जा सकता है:

$ ln -s /dev/null /etc/sysctl.d/50-coredump.conf
$ sysctl -w kernel.core_pattern=core      # or just reboot

हमेशा की तरह, कोर डंप के आकार को डंप किए जाने वाले कोर के आकार के बराबर या अधिक होना चाहिए, जैसा कि उदाहरण के लिए किया जाता है ulimit -c unlimited।

Comments

वह "हैक" मेरे लिए काम नहीं करता था (फिर से शुरू होने के बाद भी)। मैं आर्क लिनक्स चला रहा हूं और मैं पहले ही दौड़ चुका हूं ulimit -c unlimited।

— gsingh2011

@ gsingh2011 यह पुराना हो सकता है। मैं अब आर्क नहीं चलाता इसलिए मैं यह नहीं कह सकता कि क्या यह इन दिनों काम करना चाहिए। यदि आप इसका पता लगाते हैं तो एक नई टिप्पणी के साथ मुझे / हमें अपडेट करने के लिए स्वतंत्र महसूस करें।

— समयसीमा

@ gsingh2011 के 50-coredump.confबजाय प्रयास करें coredump.conf। यह ओवरराइड होना चाहिए /lib/sysctl.d/50-coredump.conf। डिफ़ॉल्ट के साथ बहाल किया जा सकता हैsysctl -w kernel.core_pattern=core

— लेकेनस्टेन

मुझे इसके लिए एपपोर्ट को बंद करना पड़ाsudo service apport stop

— rahul003

Answer 4

Ubuntu 16.04 LTS के तहत एक कोर डंप पाने के लिए निर्देश लिखना :

1. जैसा कि @jtn ने अपने उत्तर में उल्लेख किया है, उबंटू दुर्घटनाओं के प्रदर्शन को प्रदर्शित करता है , जो बदले में डंप लिखने से मना कर देता है क्योंकि प्रोग्राम एक स्थापित पैकेज नहीं है।

2. समस्या को हल करने के लिए, हमें यह सुनिश्चित करने की आवश्यकता है कि एपॉर्ट नॉन-पैकेज प्रोग्रामों के लिए कोर डंप फाइलें भी लिखें । ऐसा करने के लिए, निम्नलिखित सामग्री के साथ ~ / .config / apport / सेटिंग्स नामक एक फाइल बनाएं :
   [main] unpackaged=true

3. अब अपने प्रोग्राम को फिर से क्रैश करें, और अपनी क्रैश फ़ाइलों को फ़ोल्डर के भीतर उत्पन्न होते देखें: / var। / जैसे नामों के साथ क्रैश । * .1000.crash ध्यान दें कि इन फ़ाइलों को सीधे gdb द्वारा नहीं पढ़ा जा सकता है ।

4. [वैकल्पिक] gdb द्वारा डंप को पठनीय बनाने के लिए, निम्नलिखित कमांड चलाएँ:

   apport-unpack <location_of_report> <target_directory>

संदर्भ: Core_dump - Oracle VM VirtualBox

Comments

यह एकमात्र समाधान है जिसने मेरे लिए उबंटू में 18.04

— greuze

कौन सा उपयोगकर्ता ~ से संबंधित है? यदि प्रक्रिया रूट द्वारा चलती है तो इसका मतलब /root/.config/apport/settings है?

— निकोली

@ निकोली का मानना ​​है कि यह उस उपयोगकर्ता को होना चाहिए जिसने कार्यक्रम को निष्पादित किया। हालांकि मुझे यकीन नहीं है।

— अर्कुर्र

Answer 5

मैं निम्नलिखित दो संभावनाओं के बारे में सोच सकता था:

1. जैसा कि अन्य पहले ही बता चुके हैं, कार्यक्रम हो सकता है chdir()। क्या प्रोग्राम चलाने वाले उपयोगकर्ता को उस निर्देशिका में लिखने की अनुमति है जिसे वह chdir()संपादित करना चाहता है? यदि नहीं, तो यह कोर डंप नहीं बना सकता है।

2. कुछ अजीब कारणों से कोर डंप का नाम नहीं है core.*आप उसके /proc/sys/kernel/core_patternलिए जांच कर सकते हैं । इसके अलावा, आपके द्वारा नामित कमांड एक सामान्य कोर डंप नहीं मिलेगा। आपको उपयोग करना चाहिए find / -name "*core.*", क्योंकि कोरपम्प का विशिष्ट नाम हैcore.$PID

Comments

यहाँ मेरा पैटर्न है - क्या इसका मतलब है कि कोर फाइल को कोर के बजाय "PID.signal.userid" नाम दिया गया है। $ बिल्ली / proc / sys / कर्नेल / core_pattern / usr / lib / hookCCpp / var / char / abrt% p% s% u

— webminal.org

Answer 6

यदि आप बायनेरिज़ के लिए कोर डंप गायब कर रहे हैं RHELऔर उपयोग करते समय abrt, सुनिश्चित करें कि/etc/abrt/abrt-action-save-package-data.conf

शामिल

ProcessUnpackaged = yes

यह बायनेरिज़ के लिए क्रैश रिपोर्ट (कोर डंप सहित) को स्थापित करने में सक्षम बनाता है जो स्थापित पैकेज (जैसे स्थानीय रूप से निर्मित) का हिस्सा नहीं हैं ।

Answer 7

Fedora25 के लिए, मुझे कोर फ़ाइल मिल सकती है

/var/spool/abrt/ccpp-2017-02-16-16:36:51-2974/coredump

जहां ccpp-2017-02-16-16:36:51-2974" is pattern "%s %c %p %u %g %t %P %प्रति `के रूप में / खरीद / sys / गिरी / core_pattern '

Answer 8

डब्लूएसएल में मेरे प्रयास असफल रहे हैं।

लिनक्स (डब्लूएसएल) के लिए विंडोज सबसिस्टम पर चलने वालों के लिए इस समय एक खुला मुद्दा लगता है कि कोर डंप फाइलें गुम हो सकती हैं।

टिप्पणियों से संकेत मिलता है कि

यह एक ज्ञात मुद्दा है जिसके बारे में हम जानते हैं, यह एक ऐसी चीज है जिसकी हम जांच कर रहे हैं।

गितुब अंक

विंडोज डेवलपर प्रतिक्रिया

Answer 9

Ubuntu18.04 में, कोर फ़ाइल प्राप्त करने के लिए सबसे आसान तरीका ऐपर्ट सेवा को रोकने के लिए नीचे कमांड का इनपुट करना है।

sudo service apport stop

फिर आवेदन को फिर से जमा करें, आपको वर्तमान निर्देशिका में डंप फ़ाइल मिलेगी।

Answer 10

मैं लिनक्स मिंट 19 (उबंटू 18 आधारित) पर हूं। मैं coredumpकरंट फोल्डर में फाइलें रखना चाहता था । मुझे दो काम करने थे:

1. बदलना /proc/sys/kernel/core_pattern(द्वारा # echo "core.%p.%s.%c.%d.%P > /proc/sys/kernel/core_patternया द्वारा)# sysctl -w kernel.core_pattern=core.%p.%s.%c.%d.%P)
2. द्वारा कोर फ़ाइल आकार के लिए सीमा बढ़ाना $ ulimit -c unlimited

यह पहले से ही उत्तर में लिखा गया था, लेकिन मैंने संक्षेप में संक्षेप में लिखा था। दिलचस्प रूप से बदलती सीमा को रूट विशेषाधिकारों ( /ubuntu/162229/how-do-i-increase-the-open-files-limit-for-a-non-root-user non- के अनुसार की आवश्यकता नहीं थी रूट केवल सीमा कम कर सकता है, इसलिए यह अप्रत्याशित था - इसके बारे में टिप्पणी का स्वागत है)।

Answer 11

ulimit -c unlimited "कोर डंप" के बाद कोर फ़ाइल को सही ढंग से वर्तमान निर्देशिका में दिखाई दिया।