2012-08-03 26 views
9

Tôi đang chạy một quá trình java trên amazon ec2. Nó chạy trong 72 phút và sau đó đột nhiên tôi nhận được "kết quả java 137". Đó là tất cả, không có ngoại lệ hoặc bất kỳ thông báo lỗi nào khác. Tôi đã tìm kiếm lỗi này nhưng không thể tìm thấy bất kỳ điều gì hữu ích. Điều gì có thể là nguyên nhân của nó và làm thế nào để giải quyết nó? Làm ơn cho tôi biết.giải quyết kết quả java 137

+0

quá trình gì bạn có đang chạy? Có lẽ đó chỉ là trạng thái mà việc xử lý được chấm dứt; nó có thể không phải là một lỗi. –

+1

Tôi tin rằng số sau "kết quả Java" là giá trị được chuyển đến System.exit (int) khi mã chấm dứt thực thi. Quy ước thông thường là bất kỳ mã thoát nào khác 0 đều chỉ ra lỗi, nhưng biểu mẫu nghèo nàn không có thông báo lỗi để giúp bạn gỡ lỗi tình huống. – Bobulous

+0

@KevinMangold Tôi đang chèn các bản ghi vào MongoDB trên một cụm. Có 4 mảnh trên 4 máy và quá trình java này chèn các tài liệu bằng cách kết nối với MongoS (một trong những tài liệu hướng dẫn các mảnh). Trong mã của tôi, tôi sử dụng System.exit() nhưng nó trả về một cách rõ ràng -1 khi điều kiện lỗi được đáp ứng. Cảm ơn bạn đã gắn thẻ amazon-ec2 :), tôi nên làm điều đó trong khi đăng. – Raghava

Trả lời

22

Các mã thoát trên 127 thường có nghĩa là quá trình đã bị dừng do Signal.

Mã thoát 137 sau đó chuyển thành 128 + 9, trong khi Tín hiệu 9 là SIGKILL, tức là quá trình đã bị tiêu diệt mạnh. Điều này có thể trong số những người khác là một lệnh "kill -9". Tuy nhiên trong trường hợp của bạn, điều này có thể là tình trạng thiếu bộ nhớ trên hệ điều hành, gây ra một chức năng gọi là "OOM Killer" để ngăn chặn quá trình sử dụng hết bộ nhớ để giữ cho hệ điều hành ổn định ngay cả trong một điều kiện.

Xem this question để có cuộc thảo luận tương tự.

3

Chỉ trong trường hợp ai đó quan tâm đến việc biết số 128 này đến từ đâu; lý do có thể được tìm thấy trong mã nguồn OpenJDK. Xem: UNIXProcess_md.c

Từ các ý kiến ​​trong phương pháp Java_java_lang_UNIXProcess_waitForProcessExit:

Giá trị tốt nhất để trở lại là 0x80 + tín hiệu số, bởi vì đó là những gì tất cả các vỏ Unix làm, và vì nó cho phép người gọi để phân biệt giữa quá trình thoát ra và xử lý tử vong bằng tín hiệu.

Vì vậy, đó là lý do tại sao các nhà phát triển JVM quyết định thêm 128 vào trạng thái trả về của trẻ khi trẻ thoát vì tín hiệu.

tôi rời khỏi đây phương pháp chịu trách nhiệm về tình trạng trở về từ tiến trình con:

/* Block until a child process exits and return its exit code. 
    Note, can only be called once for any given pid. */ 
JNIEXPORT jint JNICALL 
Java_java_lang_UNIXProcess_waitForProcessExit(JNIEnv* env, 
               jobject junk, 
               jint pid) 
{ 
    /* We used to use waitid() on Solaris, waitpid() on Linux, but 
     * waitpid() is more standard, so use it on all POSIX platforms. */ 
    int status; 
    /* Wait for the child process to exit. This returns immediately if 
     the child has already exited. */ 
    while (waitpid(pid, &status, 0) < 0) { 
     switch (errno) { 
     case ECHILD: return 0; 
     case EINTR: break; 
     default: return -1; 
     } 
    } 

    if (WIFEXITED(status)) { 
     /* 
      * The child exited normally; get its exit code. 
      */ 
     return WEXITSTATUS(status); 
    } else if (WIFSIGNALED(status)) { 
     /* The child exited because of a signal. 
      * The best value to return is 0x80 + signal number, 
      * because that is what all Unix shells do, and because 
      * it allows callers to distinguish between process exit and 
      * process death by signal. 
      * Unfortunately, the historical behavior on Solaris is to return 
      * the signal number, and we preserve this for compatibility. */ 
#ifdef __solaris__ 
     return WTERMSIG(status); 
#else 
     return 0x80 + WTERMSIG(status); 
#endif 
    } else { 
     /* 
      * Unknown exit code; pass it through. 
      */ 
     return status; 
    } 
} 
Các vấn đề liên quan