Lỗi phân đoạn (lõi bị đổ) - đến đâu? nó là gì? và tại sao?


16

Khi xảy ra lỗi phân đoạn trong Linux, thông báo lỗi Segmentation fault (core dumped) sẽ được in đến thiết bị đầu cuối (nếu có) và chương trình sẽ bị chấm dứt. Là một nhà phát triển C / C ++, điều này xảy ra với tôi khá thường xuyên và tôi thường bỏ qua nó và chuyển sang gdb, tạo lại hành động trước đó của mình để kích hoạt lại tham chiếu bộ nhớ không hợp lệ. Thay vào đó, tôi nghĩ rằng có lẽ tôi có thể sử dụng "lõi" này, vì chạy gdbmọi lúc khá tẻ nhạt và tôi không thể luôn tái tạo lỗi phân đoạn.

Câu hỏi của tôi là ba:

  • Đâu là "lõi" khó nắm bắt?
  • Nó chứa cái gì?
  • Tôi có thể làm gì với nó?

Thông thường bạn chỉ cần lệnh gdb path-to-your-binary path-to-corefile, sau đó info stacktheo sau Ctrl-d. Điều đáng lo ngại duy nhất là việc bán phá giá cốt lõi là một điều bình thường đối với bạn.
ott--

Không quá bình thường , thỉnh thoảng hơn - hầu hết thời gian là do lỗi chính tả hoặc một cái gì đó tôi đã thay đổi và không ưu tiên kết quả.
Joe

Câu trả lời:


16

Nếu người khác dọn dẹp ...

... bạn thường không tìm thấy gì. Nhưng may mắn thay, Linux có một trình xử lý cho việc này mà bạn có thể chỉ định khi chạy. Trong /usr/src/linux/Documentation/sysctl/kernel.txt bạn sẽ tìm thấy:

[/ Proc / sys / kernel /] core_potype được sử dụng để chỉ định tên mẫu dumpfile lõi.

  • Nếu ký tự đầu tiên của mẫu là '|', hạt nhân sẽ coi phần còn lại của mẫu là lệnh để chạy. Kết xuất lõi sẽ được ghi vào đầu vào tiêu chuẩn của chương trình đó thay vì vào một tệp.

( cảm ơn )

Theo nguồn này được xử lý bởi abrt chương trình (đó là Công cụ báo cáo lỗi tự động, không hủy bỏ), nhưng trên Arch Linux của tôi, nó được xử lý bởi systemd. Bạn có thể muốn viết trình xử lý của riêng bạn hoặc sử dụng thư mục hiện tại.

Nhưng những gì trong đó?

Bây giờ những gì nó chứa là hệ thống cụ thể, nhưng theo tất cả các bách khoa toàn thư biết :

[Kết xuất lõi] bao gồm trạng thái được ghi lại của bộ nhớ làm việc của chương trình máy tính tại một thời điểm cụ thể [...]. Trong thực tế, các phần chính khác của trạng thái chương trình thường được kết xuất cùng lúc, bao gồm các thanh ghi bộ xử lý, có thể bao gồm bộ đếm chương trình và con trỏ ngăn xếp, thông tin quản lý bộ nhớ, và thông tin và cờ của bộ xử lý và hệ điều hành khác.

... Vì vậy, về cơ bản nó chứa mọi thứ gdbtừng muốn, và hơn thế nữa.

Vâng, nhưng tôi muốn tôi hạnh phúc thay vì gdb

Cả hai bạn đều có thể hài lòng vì gdbsẽ tải bất kỳ kết xuất lõi nào miễn là bạn có một bản sao chính xác của tệp thực thi của mình : gdb path/to/binary my/core.dump. Sau đó, bạn có thể tiếp tục kinh doanh như bình thường và khó chịu bằng cách thử và không sửa lỗi thay vì cố gắng và không tái tạo lỗi.



4

Tệp lõi thường được gọi corevà nằm trong thư mục làm việc hiện tại của quy trình. Tuy nhiên, có một danh sách dài các lý do tại sao một tệp lõi sẽ không được tạo và nó có thể được đặt ở một nơi khác hoàn toàn, dưới một tên khác. Xem trang man core.5 để biết chi tiết:

SỰ MIÊU TẢ

Hành động mặc định của các tín hiệu nhất định là khiến một quá trình chấm dứt và tạo ra tệp kết xuất lõi , một tệp đĩa chứa hình ảnh của bộ nhớ của quy trình tại thời điểm chấm dứt. Hình ảnh này có thể được sử dụng trong trình gỡ lỗi (ví dụ: gdb (1)) để kiểm tra trạng thái của chương trình tại thời điểm nó kết thúc. Một danh sách các tín hiệu gây ra một quá trình đổ lõi có thể được tìm thấy trong tín hiệu (7).

...

Có nhiều trường hợp trong đó một tệp kết xuất lõi không được tạo ra:

   *  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.

Ngoài ra, kết xuất lõi có thể loại trừ một phần không gian địa chỉ của quy trình nếu cờ madvise (2) MADV_DONTDUMP được sử dụng.

Đặt tên các tệp kết xuất lõi

Theo mặc định, một tệp kết xuất lõi được đặt tên là lõi, nhưng tệp / Proc / sys / kernel / core_potype (kể từ Linux 2.6 và 2.4.21) có thể được đặt để xác định một mẫu được sử dụng để đặt tên cho các tệp kết xuất lõi. Mẫu có thể chứa% specifier được thay thế bằng các giá trị sau khi tệp lõi được tạo:

       %%  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

1

Trong Ubuntu, bất kỳ sự cố nào xảy ra đều được đăng nhập vào / var / crash. Báo cáo sự cố được tạo có thể được giải nén bằng cách sử dụng công cụ apport

đường dẫn apport-unpack /var/crash/_crash_file.crash 'để giải nén'

và sau đó có thể đọc kết xuất lõi trong báo cáo được giải nén bằng cách sử dụng

gdb 'mèo ExecutablePath' CoreDump

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.