2011-01-06 24 views
5

Tôi có một ứng dụng đa nền tảng rất phức tạp. Gần đây nhóm của tôi và tôi đã chạy thử nghiệm căng thẳng và đã gặp phải một số sự cố (và các bãi lõi đi kèm với chúng). Một số các bãi lõi là rất chính xác, và cho tôi thấy vị trí chính xác nơi vụ tai nạn xảy ra với khoảng 10 hoặc nhiều khung ngăn xếp. Những người khác đôi khi chỉ có một khung ngăn xếp với ?? là biểu tượng duy nhất!Làm thế nào để tăng xác suất của các khối lõi Linux khớp với các biểu tượng?

Những gì tôi muốn biết là:

  1. Có cách nào để tăng khả năng cốt lõi bãi chỉ đi đúng hướng?
  2. Tại sao số lượng khung xếp chồng không được báo cáo nhất quán?
  3. Bất kỳ phương pháp hay nhất nào để được tư vấn về quản lý các bãi lõi.

Đây là cách tôi biên dịch mã nhị phân (trong chế độ phát hành):

  1. Compiler và nền tảng: g ++ với glibc-2.3.2-95.50 trên CentOS 3.6 x86_64 - Điều này giúp tôi duy trì khả năng tương thích với cũ phiên bản Linux.
  2. Tất cả các tệp được biên dịch bằng cờ -g.
  3. Biểu tượng gỡ lỗi bị tước khỏi nhị phân cuối cùng và được lưu trong một tệp riêng biệt.
  4. Khi tôi có kết xuất lõi, tôi sử dụng GDB với tệp thực thi đã tạo lõi và tệp biểu tượng. GDB không bao giờ than phiền rằng có sự không khớp giữa lõi/nhị phân/ký hiệu.

Tuy nhiên, đôi khi tôi nhận được các bãi lõi không có biểu tượng nào cả! Có thể hiểu được rằng tôi đang liên kết với phiên bản libstdC++ và libgcc không được gỡ lỗi, nhưng sẽ tốt hơn nếu ít nhất là dấu vết ngăn xếp cho tôi biết mã lệnh của tôi đã xuất hiện ở đâu trong khi mã lệnh của tôi bị lỗi (mặc dù cuối cùng có thể kết thúc bằng ??) .

Trả lời

7

Những người khác đôi khi chỉ có một khung ngăn xếp có "??" là biểu tượng duy nhất!

Có thể có nhiều lý do cho rằng, trong số những người khác:

  • khung đống bị cho vào thùng rác (ghi đè)
  • EBP/RBP (trên x86/x64) hiện không nắm giữ bất kỳ giá trị có ý nghĩa - điều này có thể xảy ra trong các đơn vị được biên dịch với hoặc đơn vị asm làm như vậy

Lưu ý rằng điểm thứ hai có thể xảy ra đơn giản, ví dụ, glibc được biên dịch theo cách như vậy. Việc có thông tin gỡ lỗi cho các thư viện hệ thống như vậy được cài đặt có thể giảm thiểu điều này (một cái gì đó giống như những gì mà gói {info, source} gỡ lỗi glibc đang ở trên openSUSE).

gdb có nhiều quyền kiểm soát đối với chương trình hơn glibc, do đó, cuộc gọi backtrace của glibc sẽ tự nhiên không thể in backtrace nếu gdb không thể làm như vậy.

Nhưng việc vận chuyển nguồn sẽ dễ dàng hơn nhiều :-)

+2

Điều này rất có thể là vấn đề - nếu khung ngăn xếp đã bị lỗi phá vỡ, thì nó biến mất. – caf

+0

Được thăng hạng. Nếu lỗi đó đang trashing ngăn xếp, thì không có sự thay thế nào cho việc thất bại sớm và lớn tiếng. khẳng định() là bạn của bạn. – user47559

2
  1. Bạn đã thử cài đặt các biểu tượng gỡ lỗi của các thư viện khác nhau mà bạn đang sử dụng chưa? Ví dụ, phân phối của tôi (Ubuntu) cung cấp libc6-dbg, libstdc++6-4.5-dbg, libgcc1-dbg vv.
  2. Nếu bạn đang xây dựng với tối ưu hóa (ví dụ: -O2), thì trình biên dịch có thể làm mờ ranh giới giữa các khung ngăn xếp. Tôi không chắc rằng điều này sẽ gây ra backtraces chỉ với một khung ngăn xếp, nhưng nói chung quy tắc là mong đợi khó khăn gỡ lỗi tuyệt vời vì mã bạn đang tìm kiếm trong kho lõi đã được sửa đổi và do đó không nhất thiết phải tương ứng với nguồn của bạn .
3

Là một thay thế, trên một hệ thống glibc, bạn có thể sử dụng cuộc gọi backtrace chức năng (hoặc backtrace_symbols hoặc backtrace_symbols_fd) và lọc ra các kết quả chính mình, vì vậy chỉ những biểu tượng thuộc mã riêng của bạn được hiển thị. Đó là một công việc nhiều hơn một chút, nhưng sau đó, bạn thực sự có thể điều chỉnh nó theo nhu cầu của bạn.

Các vấn đề liên quan