Các nhân viên khi JVM gặp sự cố khi ghi nhật ký lỗi hs_err_pid.log. Tôi muốn tìm hiểu nguyên nhân khiến JVM gặp sự cố? Làm thế nào để hiểu được các bản ghi này, liệu nó có được ghi lại ở bất cứ đâu về cách sắp xếp Nhật ký này không. Tôi cố gắng để tìm kiếm trên Net nhưng không có kết quả :-(Cách hiểu lỗi Hotspot Java
Chỉ tay ra để phù hợp URL sẽ được đánh giá cao Cảm ơn..
Trừ khi bạn đang gọi mã gốc (JNI), không có gì trong mã của bạn bao giờ nên làm JVM sụp đổ, do đó, thông tin dấu vết ngăn xếp trong tệp nhật ký đó có lẽ không có ý nghĩa gì đối với hầu hết các nhà phát triển. Đó có thể là lý do tại sao nó có thể không được ghi lại (ít nhất là bên ngoài) Vì vậy, điều tốt nhất có thể là báo cáo lỗi như được đề xuất bởi thông báo lỗi
Nhưng, nếu bạn thực sự muốn hiểu điều đó, Kohsuke's Blog có hàng hóa. Như thường lệ. :)
Để bắt đầu, hãy tìm dòng trên cùng trông giống như "ntdll.dll + 0x2000".
Nếu điểm phát sóng xuất hiện trong mã gốc của bạn (ví dụ: DLL là một trong số của bạn), sau đó tìm hiểu cách thuyết phục trình biên dịch của bạn tạo danh sách ánh xạ từ DLL offset sang số dòng. Rõ ràng, điều đó có nghĩa là bạn cần phải chạy lại với DLL mới được biên dịch và chờ sự cố xảy ra lần nữa.
Nếu không, hãy xem liệu tìm kiếm dòng cụ thể có mang lại điều gì đó trong Google hay không, lưu ý rằng cùng một lỗi có thể có nghĩa là toàn bộ máy chủ. Và xem liệu tên DLL có giống như tên của một cái gì đó có thể nhận ra hay không, ví dụ: tên trình điều khiển máy in, trình điều khiển đồ họa hoặc một số thành phần khác mà bạn có thể theo dõi một cuộc gọi cụ thể. Dù thành phần đó là gì, bạn có thể nâng cấp nó lên phiên bản cố định hoặc tránh thực hiện cuộc gọi được đề cập. Nếu bạn không chắc chắn thành phần là gì, nó có thể chỉ là "JVM" mà bạn cần nâng cấp-- nâng cấp ít nhất lên bản cập nhật mới nhất/phiên bản nhỏ của phiên bản bất kỳ mà bạn đang sử dụng có lẽ là một ý tưởng hay.
Trong quá khứ, tôi cũng đã thấy các lỗi trong trình biên dịch JIT có thể được giải quyết tạm thời bằng cách yêu cầu không cố gắng biên dịch phương thức cụ thể đang được đề cập - trong trường hợp này, lỗi hotspot một số đầu mối về phương pháp mà nó đã được (có thể chỉ là bãi chứa của ngăn xếp Java), nhưng tôi không có một ví dụ để bàn tay để nhớ lại các chi tiết.
này là khá hữu ích: http://weblogs.java.net/blog/kohsuke/archive/2009/02/crash_course_on.html
ok các anwser đầu tiên đã đề cập url này, nevermind
Liên kết giờ đã chết. – jdv
điều ác khác có thể xảy ra mà có thể gây ra một vụ tai nạn JVM. Tôi đã nhìn thấy nó với bảo trì hệ thống tập tin trên cùng một bộ điều khiển nhưng điểm gắn kết riêng biệt. Tôi đã nhìn thấy nó khi thay thế một tập tin jar hiện có trước khi dừng tomcat. (Rất tiếc.) Tôi đã có thể suy ra hai nguyên nhân này bằng thông tin trong hs_err_pid.log với những người trên diễn đàn Sun Java. –
Tôi thực sự cảm thấy mình phải có -1 cái này. Nó không chỉ liên kết với một blog, nhưng blog không hề mang lại cho tôi bất kỳ thông tin nào có lợi cho tôi khi khám phá lý do tại sao chương trình của tôi bị hỏng. Như vậy, nó không trả lời câu hỏi. :/ – Joehot200
Liên kết giờ đã chết. – jdv