Chùm tín hiệu JVM SIGPIPE

Question

Chúng tôi có một ứng dụng C++ với một JVM được nhúng (Sun's). Bởi vì chúng tôi đăng ký các trình xử lý tín hiệu của riêng mình, chúng tôi khuyên bạn nên làm như vậy trước khi khởi tạo JVM vì nó cài đặt các trình xử lý riêng của mình (see here).

Từ những gì tôi hiểu, JVM biết nội bộ nếu tín hiệu có nguồn gốc từ mã riêng của nó và nếu nó không truyền nó dọc theo chuỗi - đến bộ xử lý của chúng tôi.

Những gì chúng ta bắt đầu nhìn thấy là chúng ta đang nhận được SIGPIPEs, với một chồng gọi đó trông gần như thế này (mục trên cùng là xử lý tín hiệu của chúng tôi):

/.../libos_independent_utilities.so(_ZN2os32smart_synchronous_signal_handlerEiP7siginfoPv+0x9) [0x2b124f7a3989] 
/.../jvm/jre/lib/amd64/server/libjvm.so [0x2aaaab05dc6c] 
/.../jvm/jre/lib/amd64/server/libjvm.so [0x2aaaab05bffb] 
/.../jvm/jre/lib/amd64/server/libjvm.so(JVM_handle_linux_signal+0x718) [0x2aaaab05e878] 
/.../jvm/jre/lib/amd64/server/libjvm.so [0x2aaaab05bf0e] 
/lib64/libpthread.so.0 [0x3c2140e4c0] 
/lib64/libpthread.so.0(send+0x91) [0x3c2140d841] 
/.../jvm/jre/lib/amd64/libnet.so [0x2aaabd360269] 
/.../jvm/jre/lib/amd64/libnet.so(Java_java_net_SocketOutputStream_socketWrite0+0xee) [0x2aaabd35cf4e] 
[0x2aaaaeb3bf7f] 

Nó có vẻ như JVM là quyết định mà SIGPIPE được nâng lên từ send nên được chuyển đến bộ xử lý tín hiệu của chúng tôi. Có đúng khi làm như vậy không?

Ngoài ra, tại sao ngăn xếp cuộc gọi không đầy đủ? Tôi có nghĩa là rõ ràng nó không thể hiển thị cho tôi mã java trước socketWrite0 nhưng tại sao tôi không thể nhìn thấy ngăn xếp trước mã java?

Answer 1

JVM không thể biết SIGPIPE đến từ mã riêng của nó hay mã của bạn. Thông tin đó không được đưa ra bởi tín hiệu. Bởi vì nó không muốn bạn bỏ lỡ bất kỳ sự kiện có thể nào mà bạn có thể quan tâm, nó phải truyền cho bạn tất cả SIGPIPE, ngay cả những cái mà nó hóa ra là từ mã riêng của nó.

Tín hiệu Unix có hai hương vị - "đồng bộ" và "không đồng bộ". Một vài điều kiện đặc biệt khi thực thi mã có thể gây ra bẫy và dẫn đến tín hiệu "đồng bộ". Đây là những thứ như truy cập bộ nhớ không được ký hiệu (SIGBUS), truy cập bộ nhớ bất hợp pháp, thường là NULL, (SIGSEGV), chia cho số không và các lỗi toán học khác (SIGFPE), hướng dẫn không thể giải mã (SIGILL), v.v. Chúng có ngữ cảnh thực thi chính xác và được gửi trực tiếp đến luồng gây ra chúng. Trình xử lý tín hiệu có thể tra cứu ngăn xếp và xem "này tôi có quyền truy cập bộ nhớ bất hợp pháp đang thực thi mã java và con trỏ là NULL. Hãy để tôi sửa lỗi đó."

Ngược lại, các tín hiệu tương tác với thế giới bên ngoài là sự đa dạng "không đồng bộ" và bao gồm những thứ như SIGTERM, SIGQUIT, SIGUSR1, v.v. Những ngữ cảnh này không có ngữ cảnh thực hiện cố định. Đối với các chương trình luồng, chúng được phân phối khá ngẫu nhiên vào bất kỳ luồng nào. Quan trọng hơn, SIGPIPE nằm trong số này. Có, trong một số ý nghĩa, nó thường được kết hợp với một cuộc gọi hệ thống. Nhưng nó là khá có thể (ví dụ) có hai chủ đề nghe hai kết nối riêng biệt, cả hai đều đóng trước khi một trong hai luồng được lên lịch. Hạt nhân chỉ đảm bảo rằng có một SIGPIPE đang chờ xử lý (việc thực hiện thông thường là một bitmask của các tín hiệu đang chờ xử lý), và giao dịch với nó để lên lịch lại bất kỳ luồng nào trong tiến trình. Đây chỉ là một trong những trường hợp đơn giản nhất có thể khi JVM có thể không có đủ thông tin để loại trừ mã máy khách của bạn đang quan tâm đến tín hiệu này.

(Đối với những gì xảy ra với cuộc gọi đã đọc, họ trả về "đã xảy ra lỗi: EINTR" và tiếp tục. Tại thời điểm này, JVM có thể biến điều đó thành ngoại lệ, nhưng trở lại xảy ra sau tín hiệu giao hàng và xử lý tín hiệu kích hoạt.)

Kết quả là bạn sẽ chỉ phải đối phó với các kết quả dương tính giả. (Và đối phó với việc chỉ nhận được một tín hiệu mà hai có thể đã được mong đợi.)