Troubleshooting Java Programs
Java provides a range of information to resolve problems with application programs or the runtime environment, in particular stack traces. These should be attached to a bug report.
|
This page was taken from the previous Fedora Wiki documentation. It has been cleaned up for publishing here on the Fedora Docs Portal, but it has not yet been reviewed for technical accuracy. It is probably
Reviews for technical accuracy are greatly appreciated. If you want to help, see the README file in the source repository for instructions. Pull requests accepted at https://pagure.io/fedora-docs/quick-docs Once you’ve fixed this page, remove this notice. |
This page is an appendix to the bugs Providing a Stack Trace page. The situation for getting stack traces from Java software is slightly more complicated than with most other Fedora Project software, because of the two kinds of stack traces (Java and native).
The Two Kinds of Java Stack Traces
Stack traces produced by libgcj (i.e. produced by the virtual machine as it runs) cover all parts of the program and libraries written in Java, and all JNI and CNI methods as well - but not non-Java code called from JNI or CNI methods. Also, unfortunately, they do not typically provide source code line numbers - even if full debugging information is available. However, the good news is, libgcj stack traces will provide more information in gcc 4.1 - which it is hoped will go into Rawhide in time for inclusion in Fedora Core 5.
Stack traces produced by gdb - which, by convention, are called "backtraces" - cover all native code (whether that is C code, or Java code compiled to machine code). However, for interpreted code, they only show calls to the interpreter, but not what is being interpreted.
Thus, neither Java stack traces nor gdb backtraces are suitable for all situations. Sometimes it will be necessary to examine Java stack traces, sometimes gdb backtraces, and sometimes both.
Obtaining a Java stack trace from a Java program
Sometimes, Java programs will print out Java stack traces when they crash or fail in some way, either to the terminal window from which they are run, or to a log file.
If you get a stack trace, and if you get one or more "Caused by:" clauses, please remember that the last "Caused By" clause is the most important. Please always post at least the last "Caused By" clause (if any) when reporting a problem.
Application-specific details:
Eclipse
If you can get into Eclipse, you can view the error log by going to the Window menu and then Show View → Other → PDE Runtime → Error Log. Double-click on an error to get a popup dialog with a stack trace, which can be copied-and-pasted directly into a bug report.
If Eclipse fails to start, run it with eclipse -consolelog to output the log to the console. If that doesn’t produce anything useful, try eclipse -consolelog -debug .
When you cannot obtain a Java stack trace
If a Java program simply fails without printing a stack trace - not on the terminal window or even in a log file anywhere - then: If it is natively-compiled, or if it says Aborted or Segmentation fault or Illegal instruction immediately before it quits, try to obtain a gdb backtrace as described in the next section. Otherwise, a gdb backtrace will probably not be helpful, so just file a bug report without a stack trace.
Future work: In the upcoming gcc 4.1, a SIGQUIT handler is planned which will enable the generation of Java stack traces on demand by the user. (This cannot be used for crashes which terminate the program, however - it can only be used for certain failures which leave the program running.)
Obtaining a gdb backtrace from a Java program
First you will need to read the StackTraces page, up to the point of starting gdb.
Because libgcj uses several signals internally, you need to tell gdb first of all to ignore some of them, by typing or pasting the following commands into gdb:
handle SIGHUP nostop print
handle SIGPWR nostop noprint
handle SIGXCPU nostop noprint
handle SIG32 nostop noprint
handle SIG33 nostop noprintgdb can also be quite slow at loading the debugging information for various libraries (which can drastically affect the startup time of programs), so, to get nice friendly progress indications, you might want to also specify:
set verbose onNow type run or r for short and continue reading the instructions on the StackTraces page.
Ignoring "Null Pointer Exceptions" of the harmless variety in gdb
Sometimes code generates one or more Null Pointer Exceptions which are in fact harmless - or at least, irrelevant to the bug you are trying to trace. (Not all Null Pointer Exceptions are harmless or irrelevant, but some are.) Because gcj uses SIGSEGV to detect Null Pointer Exceptions, you can also specify
handle SIGSEGV nostop noprintto tell gdb to ignore SIGSEGVs, or
handle SIGSEGV nostop printto tell gdb to inform you of SIGSEGVs, but otherwise ignore them.
Want to help? Learn how to contribute to Fedora Docs ›