Pemecahan Masalah Program Java

Ravidiip, Tuju Versi unspecified Last review: 2010
Java menyediakan berbagai informasi untuk membantu menyelesaikan masalah pada program aplikasi maupun lingkungan runtime, terutama melalui stack trace. Stack trace ini sebaiknya dilampirkan pada laporan bug.

Halaman ini diambil dari dokumentasi Fedora Wiki sebelumnya.

Dokumen ini telah disunting untuk dipublikasikan di Portal Dokumen Fedora, tetapi belum direview untuk keakuratan teknisnya.

Mungkin saja

  • Mengandung masalah format

  • Ketinggalan zaman

  • Membutuhkan cinta lain

Ulasan mengenai akurasi teknis sangat dihargai. Jika Anda ingin membantu, lihat berkas README di repositori sumber untuk petunjuk.

Permintaan pull diterima di https://pagure.io/fedora-docs/quick-docs

Setelah Anda memperbaiki halaman ini, hapus pemberitahuan ini.

Halaman ini merupakan lampiran dari halaman Menyediakan Stack Trace. Situasi untuk mendapatkan stack trace dari perangkat lunak Java sedikit lebih rumit dibandingkan dengan sebagian besar perangkat lunak Fedora Project lainnya, karena terdapat dua jenis stack trace (Java dan native).

Dua Jenis Stack Trace Java

Stack trace yang dihasilkan oleh libgcj (yaitu oleh mesin virtual saat dijalankan) mencakup seluruh bagian program dan pustaka yang ditulis dalam Java, serta semua metode JNI dan CNI – namun tidak mencakup kode non-Java yang dipanggil dari metode JNI atau CNI. Sayangnya, stack trace tersebut umumnya tidak menyertakan nomor baris kode sumber, bahkan jika informasi debugging lengkap tersedia. Namun kabar baiknya, stack trace libgcj akan memberikan lebih banyak informasi di gcc 4.1 – yang diharapkan dapat dimasukkan ke Rawhide tepat waktu untuk Fedora Core 5.

Stack trace yang dihasilkan oleh gdb – yang secara konvensi disebut “backtrace” – mencakup semua kode native (baik itu kode C, atau Java yang dikompilasi ke kode mesin). Namun, untuk kode yang diinterpretasikan, hanya pemanggilan ke interpreter yang ditampilkan, dan bukan apa yang sedang diinterpretasikan.

Dengan demikian, baik stack trace Java maupun backtrace gdb tidak cocok untuk semua situasi. Kadang Anda perlu memeriksa stack trace Java, kadang backtrace gdb, dan kadang keduanya.

Mendapatkan Java Stack Trace dari Program Java

Terkadang, program Java akan mencetak stack trace saat terjadi crash atau kesalahan, baik ke jendela terminal tempat program dijalankan, maupun ke file log.

Jika Anda mendapatkan stack trace dan terdapat satu atau lebih klausa “Caused by:”, harap diingat bahwa klausa “Caused by” yang terakhir adalah yang paling penting. Selalu sertakan setidaknya klausa “Caused by” terakhir (jika ada) saat melaporkan masalah.

Rincian spesifik aplikasi:

Eclipse

Jika Anda dapat membuka Eclipse, Anda dapat melihat log error melalui menu Window, lalu Show View → Other → PDE Runtime → Error Log. Klik dua kali pada entri error untuk membuka dialog dengan stack trace yang dapat disalin dan ditempel langsung ke laporan bug.

Jika Eclipse gagal dijalankan, jalankan dengan perintah eclipse -consolelog untuk menampilkan log ke konsol. Jika hasilnya tidak berguna, coba jalankan dengan eclipse -consolelog -debug.

Tomcat

Periksa semua file di direktori /var/log/tomcat5</ dan file log khusus webapp apa pun yang telah Anda konfigurasikan.

Ketika Anda tidak dapat memperoleh Java Stack Trace

Jika program Java gagal tanpa mencetak stack trace – baik di terminal maupun di file log mana pun – maka: jika program dikompilasi secara native, atau menampilkan pesan Aborted, Segmentation fault, atau Illegal instruction sesaat sebelum berhenti, cobalah untuk mendapatkan backtrace gdb seperti dijelaskan pada bagian berikutnya. Jika tidak, backtrace gdb tidak akan banyak membantu, jadi cukup laporkan bug tanpa melampirkan stack trace.

Pekerjaan mendatang: Dalam versi gcc 4.1 yang akan datang, direncanakan adanya penangan SIGQUIT yang memungkinkan pengguna menghasilkan Java stack trace sesuai permintaan. (Namun fitur ini tidak dapat digunakan untuk crash yang mengakhiri program, hanya untuk jenis kegagalan tertentu saat program masih berjalan.)

Mendapatkan gdb Backtrace dari Program Java

Pertama, bacalah halaman StackTraces hingga bagian cara memulai gdb.

Karena libgcj menggunakan beberapa sinyal secara internal, Anda perlu memberi tahu gdb untuk mengabaikan sebagian di antaranya, dengan mengetik atau menempelkan perintah berikut ke dalam gdb:

handle SIGHUP nostop print
handle SIGPWR nostop noprint
handle SIGXCPU nostop noprint
handle SIG32 nostop noprint
handle SIG33 nostop noprint

gdb juga bisa memakan waktu lama dalam memuat informasi debugging untuk berbagai pustaka (yang dapat memengaruhi waktu mulai program secara signifikan), jadi agar ada indikator progres yang ramah, Anda dapat menambahkan opsi berikut juga:

set verbose on

Sekarang ketik run atau r untuk singkatnya, dan lanjutkan membaca petunjuk pada halaman StackTraces.

Mengabaikan “Null Pointer Exception” yang tidak berbahaya di gdb

Terkadang, kode menghasilkan satu atau lebih Null Pointer Exceptions yang sebenarnya tidak berbahaya — atau setidaknya tidak relevan dengan bug yang sedang Anda telusuri. (Tidak semua Null Pointer Exceptions bersifat tidak berbahaya atau tidak relevan, tetapi beberapa di antaranya demikian.) Karena gcj menggunakan SIGSEGV untuk mendeteksi Null Pointer Exceptions, Anda juga dapat menentukan perintah berikut

handle SIGSEGV nostop noprint

untuk memberi tahu gdb agar mengabaikan SIGSEGV,

handle SIGSEGV nostop print

atau untuk memberi tahu gdb agar memberitahu Anda tentang SIGSEGV, tetapi tetap mengabaikannya.

Want to help? Learn how to contribute to Fedora Docs ›