การแบ่งส่วนความผิดพลาด (แกนทิ้ง) - ไปที่ไหน? มันคืออะไร? และทำไม?


16

เมื่อเกิดข้อผิดพลาดในการแบ่งส่วนใน Linux ข้อความแสดงข้อผิดพลาดSegmentation fault (core dumped)จะถูกพิมพ์ไปยังเทอร์มินัล (ถ้ามี) และโปรแกรมจะถูกยกเลิก ในฐานะ C / C ++ dev สิ่งนี้เกิดขึ้นกับฉันบ่อยครั้งและฉันมักจะเพิกเฉยต่อมันและไปยังgdbสร้างการกระทำก่อนหน้าของฉันใหม่เพื่อกระตุ้นการอ้างอิงหน่วยความจำที่ไม่ถูกต้องอีกครั้ง ฉันคิดว่าฉันอาจสามารถใช้ "แกนหลัก" นี้แทนได้เนื่องจากการรันgdbตลอดเวลานั้นค่อนข้างน่าเบื่อและฉันไม่สามารถสร้างข้อผิดพลาดในการแบ่งกลุ่มได้อีก

คำถามของฉันคือสาม:

  • ทิ้ง "แกนกลาง" นี้ไว้ที่ไหน
  • มันมีอะไรบ้าง
  • ฉันจะทำอย่างไรกับมัน?

โดยปกติแล้วคุณจะต้องคำสั่งgdb path-to-your-binary path-to-corefileแล้วตามด้วยinfo stack Ctrl-dสิ่งเดียวที่น่ากังวลก็คือการถ่ายโอนข้อมูลหลักเป็นสิ่งปกติสำหรับคุณ
ott--

ไม่มากปกติมากขึ้นเป็นครั้งคราว - ที่สุดของเวลาที่มันเกิดจากความผิดพลาดหรืออะไรผมเปลี่ยนและไม่ได้ยึดผล
โจ

คำตอบ:


16

หากคนอื่นทำความสะอาด ...

... คุณมักจะไม่พบอะไรเลย แต่โชคดีที่ Linux มีตัวจัดการสำหรับสิ่งนี้ซึ่งคุณสามารถระบุได้ในขณะทำงาน ใน/usr/src/linux/Documentation/sysctl/kernel.txtคุณจะพบ:

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

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

( ขอบคุณ )

ตามแหล่งที่มาสิ่งนี้จัดการโดยabrtโปรแกรม (นั่นคือเครื่องมือรายงานข้อผิดพลาดอัตโนมัติไม่ใช่ยกเลิก) แต่ใน Arch Linux ของฉันมันถูกจัดการโดย systemd คุณอาจต้องการเขียน handler ของคุณเองหรือใช้ไดเรกทอรีปัจจุบัน

แต่มีอะไรอยู่ในนั้น

ตอนนี้สิ่งที่มีอยู่นั้นเป็นระบบเฉพาะ แต่ตามสารานุกรมที่รู้ทั้งหมด :

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

... ดังนั้นโดยทั่วไปจะมีทุกสิ่งgdbที่ต้องการและอื่น ๆ

ใช่ แต่ฉันต้องการให้ฉันมีความสุขแทน gdb

คุณทั้งสองจะมีความสุขตั้งแต่จะโหลดถ่ายโอนข้อมูลหลักตราบใดที่คุณมีสำเนาถูกต้องของปฏิบัติการของคุณ:gdb gdb path/to/binary my/core.dumpจากนั้นคุณควรจะสามารถดำเนินธุรกิจได้ตามปกติและรำคาญด้วยการพยายามและไม่สามารถแก้ไขข้อบกพร่องแทนที่จะพยายามทำและไม่สามารถทำซ้ำข้อบกพร่องได้


6

นอกจากนี้หากulimit -cส่งคืนจะ0ไม่มีไฟล์การถ่ายโอนข้อมูลหลัก

ดูว่าจะค้นหาไฟล์หลักที่สร้างจากความผิดพลาดของแอปพลิเคชัน linux ได้ที่ไหน

นอกจากนี้คุณยังสามารถเรียกการถ่ายโอนข้อมูลหลักด้วยตนเองCTRL- \ซึ่งจบการทำงานของกระบวนการและทำให้เกิดการถ่ายโอนข้อมูลหลัก


4

โดยปกติไฟล์หลักจะถูกเรียกcoreและตั้งอยู่ในไดเรกทอรีการทำงานปัจจุบันของกระบวนการ อย่างไรก็ตามมีรายการเหตุผลมากมายที่ทำให้ไฟล์หลักไม่ถูกสร้างขึ้นและอาจอยู่ในตำแหน่งอื่นภายใต้ชื่ออื่น ดูหน้าcore.5 manสำหรับรายละเอียด:

รายละเอียด

การดำเนินการเริ่มต้นของสัญญาณบางอย่างคือการทำให้กระบวนการยุติและสร้างไฟล์ core dumpซึ่งเป็นไฟล์ดิสก์ที่มีภาพของหน่วยความจำของกระบวนการในเวลาที่ยกเลิก ภาพนี้สามารถใช้ในโปรแกรมดีบั๊ก (เช่น gdb (1)) เพื่อตรวจสอบสถานะของโปรแกรม ณ เวลาที่สิ้นสุด รายการของสัญญาณที่ทำให้กระบวนการการถ่ายโอนข้อมูลหลักสามารถพบได้ในสัญญาณ (7)

...

มีหลายสถานการณ์ที่ไฟล์ core dump ไม่ได้ถูกสร้างขึ้น:

   *  The process does not have permission to write the core file.  (By
      default, the core file is called core or core.pid, where pid is
      the ID of the process that dumped core, and is created in the
      current working directory.  See below for details on naming.) 
      Writing the core file will fail if the directory in which it is to
      be created is nonwritable, or if a file with the same name exists
      and is not writable or is not a regular file (e.g., it is a
      directory or a symbolic link).
   *  A (writable, regular) file with the same name as would be used for
      the core dump already exists, but there is more than one hard link
      to that file.
   *  The filesystem where the core dump file would be created is full;
      or has run out of inodes; or is mounted read-only; or the user has
      reached their quota for the filesystem.
   *  The directory in which the core dump file is to be created does
      not exist.
   *  The RLIMIT_CORE (core file size) or RLIMIT_FSIZE (file size)
      resource limits for the process are set to zero; see getrlimit(2)
      and the documentation of the shell's ulimit command (limit in
      csh(1)).
   *  The binary being executed by the process does not have read
      permission enabled.
   *  The process is executing a set-user-ID (set-group-ID) program that
      is owned by a user (group) other than the real user (group) ID of
      the process, or the process is executing a program that has file
      capabilities (see capabilities(7)).  (However, see the description
      of the prctl(2) PR_SET_DUMPABLE operation, and the description of
      the /proc/sys/fs/suid_dumpable file in proc(5).)
   *  (Since Linux 3.7) The kernel was configured without the
      CONFIG_COREDUMP option.

นอกจากนี้ดัมพ์หลักอาจแยกส่วนของพื้นที่แอดเดรสของกระบวนการหากใช้แฟล็ก madvise (2) MADV_DONTDUMP

การตั้งชื่อไฟล์ core dump

โดยค่าเริ่มต้นไฟล์การถ่ายโอนข้อมูลหลักชื่อแกน แต่ไฟล์ / proc / sys / kernel / core_pattern (ตั้งแต่ Linux 2.6 และ 2.4.21) สามารถตั้งค่าเพื่อกำหนดแม่แบบที่ใช้ในการตั้งชื่อไฟล์การถ่ายโอนข้อมูลหลัก เท็มเพลตสามารถมีตัวระบุ% ซึ่งถูกแทนที่ด้วยค่าต่อไปนี้เมื่อสร้างไฟล์แกน:

       %%  a single % character
       %c  core file size soft resource limit of crashing process (since
           Linux 2.6.24)
       %d  dump mode—same as value returned by prctl(2) PR_GET_DUMPABLE
           (since Linux 3.7)
       %e  executable filename (without path prefix)
       %E  pathname of executable, with slashes ('/') replaced by
           exclamation marks ('!') (since Linux 3.0).
       %g  (numeric) real GID of dumped process
       %h  hostname (same as nodename returned by uname(2))
       %i  TID of thread that triggered core dump, as seen in the PID
           namespace in which the thread resides (since Linux 3.18)
       %I  TID of thread that triggered core dump, as seen in the
           initial PID namespace (since Linux 3.18)
       %p  PID of dumped process, as seen in the PID namespace in which
           the process resides
       %P  PID of dumped process, as seen in the initial PID namespace
           (since Linux 3.12)
       %s  number of signal causing dump
       %t  time of dump, expressed as seconds since the Epoch,
           1970-01-01 00:00:00 +0000 (UTC)
       %u  (numeric) real UID of dumped process

2

ในอูบุนตูความผิดพลาดใด ๆ ที่เกิดขึ้นจะถูกบันทึกไว้ใน / var / crash รายงานข้อขัดข้องที่สร้างขึ้นสามารถนำออกจากกล่องโดยใช้เครื่องมือการเชื่อมต่อ

apport-unpack /var/crash/_crash_file.crash 'เส้นทางไปยัง unpack'

และจากนั้นดัมพ์หลักในรายงานที่ไม่ได้แพ็กสามารถอ่านได้โดยใช้

gdb 'cat ExecutablePath' CoreDump

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.