Error Handling in J2SE 1.3.1

The Java virtual machines (JVM) that ship with J2SE 1.3.1 have a new error-handling feature. When the JVM detects a crash in native code such as JNI code written by the developer or when the JVM itself crashes, it will print debug information about the crash. This error message normally will include information such as the function name, library name, source-file name and line number at which the error occurred. (Currently, information about file name and line number are available only available on Microsoft Windows platforms.) For an example of a message emitted by the error handler, see JNI Error example.

The information provided by the new error-handling mechanism will allow developers to more easily and efficiently debug their applications. If an error message indicates a problem in the JVM code itself, it will allow a developer to submit a more accurate and helpful bug report.

Sometimes the error-handling mechanism won't be able to determine the information that might be helpful in locating the source of a crash. To get the most out of the error handler, developers should be aware of the following guidelines and limitations.

Compile in debug mode

In some circumstances, the error-handling mechanism won't be able to determine symbol names. The most common reason for this is that the binary code that crashed was not compiled in debug mode and therefore doesn't have symbol tables. Developers should compile their code in debug mode to ensure that it contains the necessary debug information. In Visual Studio, for example, this means choosing "Debug" rather than "Release" as the project's build mode. When using gcc or cc on Linux or on the Solaris^TM Operating Environment, compile using the -g command-line option.

Non-exported functions

Even without debug information in the binary code, the error handler can still print the function name of the crash site. However, the function name might not be correct if the problematic function is not "exported" from the dynamic library. On Linux and Solaris OE, all functions are exported except those declared static. On Microsoft Windows platforms, no functions are exported unless explicitly declared so (using JNIEXPORT or __declspec(dllexport)).

Visual Studio limitation on Microsoft Windows 95/98 and NT

On Microsoft Windows 95, 98 and NT platforms, the error handler uses the system's imagehlp.dll file to help determine the function name, source file, and line number of a crash site. (Microsoft Windows 2000 and ME use two files, imagehlp.dll and debughlp.dll to perform this task.) However, the imagehlp.dll file in Microsoft Windows 95/98 and NT does not work well with binary code and DLLs generated by Visual Studio 6.0. This problem is due to a file-format change introduced in Visual Studio 6.0 and is described in detail on the Microsoft Product Support Services web site along with Microsoft's recommended solution.

This problem may cause the error handler to generate error messages with incorrect information about the function name, source file and line number of the crash site, though other information in the error message will be correct.