Gỡ lỗi SIGBUS trên x86 Linux

Question

Điều gì có thể gây SIGBUS (lỗi bus) trên ứng dụng chung của người dùng x86 trong Linux? Tất cả các cuộc thảo luận tôi đã có thể tìm thấy trực tuyến là liên quan đến lỗi liên kết bộ nhớ, mà từ những gì tôi hiểu không thực sự áp dụng cho x86.

(mã của tôi đang chạy trên một Geode, trong trường hợp có bất kỳ quirks xử lý cụ thể liên quan ở đó.)

Answer 1

Bạn có thể nhận SIGBUS từ truy cập chưa được ký nếu bạn bật bẫy truy cập chưa được căn chỉnh, nhưng thông thường là tắt trên x86. Bạn cũng có thể làm cho nó truy cập vào một thiết bị được ánh xạ bộ nhớ nếu có lỗi nào đó.

Đặt cược tốt nhất của bạn là sử dụng trình gỡ lỗi để xác định hướng dẫn lỗi (SIGBUS là đồng bộ) và cố gắng xem nó đang cố gắng làm gì.

Answer 2

Một nguyên nhân phổ biến của một lỗi xe buýt trên x86 Linux đang cố gắng dereference cái gì đó không thực sự là một con trỏ, hoặc là một con trỏ hoang dã. Ví dụ, không khởi tạo một con trỏ, hoặc gán một số nguyên tùy ý cho một con trỏ và sau đó cố gắng dereference nó thường sẽ tạo ra một lỗi phân đoạn hoặc một lỗi bus.

Căn chỉnh áp dụng cho x86. Mặc dù bộ nhớ trên x86 là địa chỉ byte (vì vậy bạn có thể có một con trỏ char đến bất kỳ địa chỉ nào), nếu bạn có ví dụ một con trỏ đến một số nguyên 4 byte, con trỏ đó phải được căn chỉnh.

Bạn nên chạy chương trình của mình trong gdb và xác định truy cập con trỏ nào đang tạo ra lỗi bus để chẩn đoán sự cố.

Answer 3

SIGBUS có thể xảy ra trong Linux vì một vài lý do khác với lỗi liên kết bộ nhớ - ví dụ: nếu bạn cố gắng truy cập khu vực mmap ngoài phần cuối của tệp được ánh xạ.

Bạn có đang sử dụng bất cứ thứ gì như mmap, khu vực bộ nhớ dùng chung hoặc tương tự không?

Answer 4

Ồ vâng, có một cách kỳ lạ hơn để nhận SIGBUS.

Nếu hạt nhân không thể trang trong trang mã do áp lực bộ nhớ (OOM killer phải được tắt) hoặc yêu cầu IO không thành công, SIGBUS.

Answer 5

Đó là một chút so với đường bị đánh, nhưng bạn có thể lấy SIGBUS từ một tải SSE2 (m128) chưa được căn chỉnh.

Answer 6

SIGBUS trên x86 (bao gồm x86_64) Linux là một con thú quý hiếm. Nó có thể xuất hiện từ nỗ lực truy cập vào cuối tệp mmap ed hoặc một số tình huống khác được mô tả bởi POSIX.

Nhưng do lỗi phần cứng, việc lấy SIGBUS không dễ dàng. Cụ thể là, truy cập không được gán từ bất kỳ lệnh nào - có thể là SIMD hay không - thường là kết quả trong SIGSEGV. Chồng tràn kết quả trong SIGSEGV. Ngay cả khi truy cập vào các địa chỉ không có dạng thức kinh điển dẫn đến SIGSEGV. Tất cả điều này do #GP được nâng lên, hầu như luôn luôn ánh xạ tới SIGSEGV.

Bây giờ, here're một số cách để có được SIGBUS do một ngoại lệ CPU:

1. Enable AC bit trong EFLAGS, sau đó làm truy cập unaligned bởi bất kỳ bộ nhớ đọc hoặc viết hướng dẫn. Xem this discussion để biết chi tiết.

2. Vi phạm chính tắc qua đăng ký con trỏ ngăn xếp (rsp hoặc rbp), tạo #SS.Dưới đây là một ví dụ cho GCC (biên dịch với gcc test.c -o test -masm=intel):

 
int main() 
{ 
    __asm__("mov rbp,0x400000000000000\n" 
      "mov rax,[rbp]\n" 
      "ud2\n"); 
} 

Answer 7

là một thời gian ngắn này đề cập ở trên là một "thất bại IO yêu cầu", nhưng tôi sẽ mở rộng khi nó một chút.

Trường hợp thường xuyên là khi bạn lười biếng phát triển tệp bằng ftruncate, ánh xạ nó vào bộ nhớ, bắt đầu viết dữ liệu và sau đó hết dung lượng trong hệ thống tệp của bạn. Không gian vật lý cho tệp được ánh xạ được phân bổ trên các lỗi trang, nếu không có gì còn lại thì quá trình sẽ nhận được SIGBUS.

Nếu bạn cần ứng dụng của mình khôi phục chính xác từ lỗi này, bạn nên đặt trước khoảng trống trước khi mmap bằng cách sử dụng sai chỗ. Xử lý ENOSPC trong errno sau khi rút gọn cuộc gọi đơn giản hơn nhiều so với xử lý tín hiệu, đặc biệt là trong một ứng dụng đa luồng.