หลักทิ้งแล้ว แต่ไฟล์หลักไม่ได้อยู่ในไดเรกทอรีปัจจุบัน?

ในขณะที่รันโปรแกรม C มันบอกว่า"(core dumped)"แต่ฉันไม่เห็นไฟล์ใด ๆ ภายใต้พา ธ ปัจจุบัน

ฉันได้ตั้งค่าและตรวจสอบulimit:

ulimit -c unlimited 
ulimit -a 

ฉันพยายามค้นหาไฟล์ชื่อ "core" แต่ไม่ได้รับไฟล์ทิ้งหลัก?
ความช่วยเหลือใด ๆ ไฟล์หลักของฉันอยู่ที่ไหน

อ่าน/usr/src/linux/Documentation/sysctl/kernel.txt

[/ proc / sys / kernel /] core_pattern ใช้เพื่อระบุชื่อรูปแบบ core dumpfile

• หากอักขระตัวแรกของรูปแบบคือ '|' เคอร์เนลจะถือว่าส่วนที่เหลือของรูปแบบเป็นคำสั่งให้เรียกใช้ ดัมพ์หลักจะถูกเขียนไปยังอินพุตมาตรฐานของโปรแกรมนั้นแทนไปยังไฟล์

แทนที่จะเขียนการถ่ายโอนข้อมูลหลักไปยังดิสก์ระบบของคุณได้รับการกำหนดค่าให้ส่งไปยังabrtโปรแกรมแทน เครื่องมือรายงานข้อผิดพลาดอัตโนมัติอาจไม่ได้รับการจัดทำเป็นเอกสารตามที่ควรเป็น ...

ไม่ว่าในกรณีใดคำตอบอย่างรวดเร็วคือคุณควรจะสามารถค้นหาไฟล์หลักของคุณได้/var/cache/abrtโดยที่abrtจะเก็บไฟล์ไว้หลังจากถูกเรียก ในทำนองเดียวกันระบบอื่น ๆ ที่ใช้Apportอาจกระรอกแกนกลางออกไป/var/crashและอื่น ๆ

ใน Ubuntu ล่าสุด (12.04 ในกรณีของฉัน) เป็นไปได้ที่จะพิมพ์ "Segmentation fault (core dumped)" แต่ไม่มีไฟล์หลักที่คุณอาจคาดหวัง (ตัวอย่างเช่นสำหรับโปรแกรมที่คอมไพล์ในเครื่อง)

สิ่งนี้อาจเกิดขึ้นหากคุณมีขนาดไฟล์หลักเป็น ulimit เป็น 0 (คุณยังไม่ได้ทำulimit -c unlimited) - นี่เป็นค่าเริ่มต้นบน Ubuntu โดยปกติแล้วจะระงับ "(core dumped)" ซึ่งทำให้คุณเข้าใจผิด แต่ใน Ubuntu นั้น corefiles จะถูกส่งไปยังApport (ระบบรายงานความผิดพลาดของ Ubuntu) ผ่านทาง/proc/sys/kernel/core_patternและดูเหมือนว่าจะทำให้เกิดข้อความที่ทำให้เข้าใจผิด

หาก Apport พบว่าโปรแกรมที่เป็นปัญหาไม่ใช่โปรแกรมที่ควรรายงานข้อขัดข้องสำหรับ (ซึ่งคุณสามารถเห็นได้เกิดขึ้น/var/log/apport.log) มันจะกลับไปจำลองพฤติกรรมการทำงานของเคอร์เนลเริ่มต้นของการวางไฟล์คอร์ใน cwd (จะทำในสคริปต์/usr/share/apport/apport) ซึ่งรวมถึงการให้เกียรติ ulimit ซึ่งในกรณีนี้มันไม่ทำอะไรเลย แต่ (ฉันถือว่า) ตราบใดที่เคอร์เนลเกี่ยวข้อง corefile ถูกสร้างขึ้น (และ piped เพื่อ apport) ดังนั้นข้อความ "Segmentation fault (core dumped)"

ในที่สุด PEBKAC ที่ลืมตั้ง ulimit แต่ข้อความที่ทำให้เข้าใจผิดทำให้ฉันคิดว่าฉันกำลังจะโมโหชั่วขณะหนึ่งสงสัยว่าสิ่งที่กิน corefiles ของฉัน

(โดยทั่วไปแล้วหน้า core (5) manual - man 5 core- เป็นการอ้างอิงที่ดีว่าไฟล์หลักของคุณสิ้นสุดที่ใดและสาเหตุที่อาจไม่ถูกเขียน)

ด้วยการเปิดตัวsystemdมีสถานการณ์อื่นเช่นกัน โดยค่าเริ่มต้น 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และเช่นเคยขนาดของแกนทิ้งจะต้องเท่ากับหรือสูงกว่าขนาดของแกนที่ถูกทิ้งเป็นกระทำโดยยกตัวอย่างเช่น

การเขียนคำแนะนำเพื่อรับการถ่ายโอนข้อมูลหลักภายใต้Ubuntu 16.04 LTS :

1. ตามที่ @ jtn ได้กล่าวถึงในคำตอบของเขา Ubuntu ได้มอบหมายการแสดงผลของความขัดข้องให้กับapportซึ่งในทางกลับกันปฏิเสธที่จะเขียนการถ่ายโอนข้อมูลเนื่องจากโปรแกรมไม่ใช่แพ็คเกจที่ติดตั้ง

2. ในการแก้ไขปัญหาเราต้องแน่ใจว่าapportเขียนไฟล์ core dump สำหรับโปรแกรมที่ไม่ใช่แพ็คเกจด้วย หากต้องการทำเช่นนั้นให้สร้างไฟล์ชื่อ~ / .config / apport / settingsด้วยเนื้อหาต่อไปนี้:
   [main] unpackaged=true

3. ตอนนี้ความผิดพลาดของโปรแกรมของคุณอีกครั้งและดูไฟล์ที่ผิดพลาดของคุณจะถูกสร้างขึ้นภายในโฟลเดอร์: / var / ความผิดพลาดที่มีชื่อเหมือน.1000.crash * โปรดทราบว่าgdbไม่สามารถอ่านไฟล์เหล่านี้โดยตรง

4. [ไม่บังคับ]หากต้องการทำให้ dumps readble โดย gdb ให้รันคำสั่งต่อไปนี้:

   apport-unpack <location_of_report> <target_directory>

ข้อมูลอ้างอิง: Core_dump - Oracle VM VirtualBox

ฉันนึกถึงความเป็นไปได้สองอย่างต่อไปนี้:

1. chdir()เป็นคนอื่นได้ชี้แล้วออกจากโปรแกรมที่อาจจะ ผู้ใช้ที่ใช้งานโปรแกรมได้รับอนุญาตให้เขียนลงในไดเรกทอรีchdir()หรือไม่ มิฉะนั้นจะไม่สามารถสร้างคอร์ดัมพ์ได้

2. ด้วยเหตุผลแปลก ๆ บางอย่างดัมพ์หลักไม่มีชื่อcore.*คุณสามารถตรวจสอบ/proc/sys/kernel/core_patternได้ นอกจากนี้คำสั่ง find ที่คุณตั้งชื่อจะไม่พบ core dump ทั่วไป คุณควรใช้find / -name "*core.*"เนื่องจากชื่อทั่วไปของ coredump คือcore.$PID

หากคุณไม่มีแกนทิ้งสำหรับไบนารีRHELและเมื่อใช้abrtตรวจสอบให้แน่ใจว่า/etc/abrt/abrt-action-save-package-data.conf

มี

ProcessUnpackaged = yes

สิ่งนี้ช่วยให้สามารถสร้างรายงานข้อขัดข้อง (รวมถึงการถ่ายโอนข้อมูลหลัก) สำหรับไบนารีที่ไม่ได้เป็นส่วนหนึ่งของแพ็คเกจที่ติดตั้ง (เช่นสร้างขึ้นภายในเครื่อง)

สำหรับ 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 %ตาม `/ proc / sys / kernel / core_pattern '

ความพยายามของฉันใน WSL ไม่ประสบความสำเร็จ

สำหรับผู้ที่ทำงานบน Windows Subsystem สำหรับ Linux (WSL) ดูเหมือนว่าจะเป็นปัญหาที่เปิดอยู่ในเวลานี้สำหรับไฟล์ดัมพ์หลักที่ขาดหายไป

ความคิดเห็นระบุว่า

นี่เป็นปัญหาที่ทราบกันดีว่าเราตระหนักถึงมันเป็นสิ่งที่เรากำลังสืบสวนอยู่

ปัญหา Github

คำติชมของนักพัฒนา Windows

ใน Ubuntu18.04 วิธีที่ง่ายที่สุดในการรับไฟล์หลักคือการป้อนคำสั่งด้านล่างเพื่อหยุดบริการ apport

sudo service apport stop

จากนั้นรันแอปพลิเคชันอีกครั้งคุณจะได้รับไฟล์ดัมพ์ในไดเรกทอรีปัจจุบัน

ฉันใช้ Linux Mint 19 (ใช้ Ubuntu 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-ไม่ใช่/ubuntu/162229/howรูทสามารถลดขีด จำกัด ลงได้เท่านั้นดังนั้นจึงเป็นสิ่งที่ไม่คาดคิด - ความคิดเห็นเกี่ยวกับเรื่องนี้ยินดีต้อนรับ)

ulimit -c unlimited ทำไฟล์หลักอย่างถูกต้องปรากฏในไดเรกทอรีปัจจุบันหลังจาก "core ทิ้ง"