There are several issues in fatal error handler that need to be resolved:
1. report_error(): in case of more than one fatal error occurs at the same
time, we can't just return or exit if error_level > 2, that may cause
crashes. We should hold there for a few seconds to allow normal error
dumping and shutdown to finish.
2. Move most of the error dumping logic out of signal handler. Only async-
safe functions are allowed in signal handlers. It's impossible to have
stable yet complex dumping logic in signal handler.
3. Avoid memory allocation. System calls like localtime() may call malloc().
That can cause VM hang if the crash happens while the thread is holding
malloc lock. (see 4485056).
4. ErrorID is not so useful in case of crashes. It always points to os.cpp:xxx
in os::report_fatal_error(). Since we know the function name nearest to
the crash site, A better ErrorID for crashes probably is
5. Print offset in the library. - That can be used by a standalone utility
(e.g. addr2line on Linux) to retrieve line numbers.
6. Dump native stack trace. Java stack trace is not so useful in some cases.
We will have problems walking x86 stack if frame pointer is not emitted on
the stack. But a best-effort printout is better than nothing.
7. Limit screen dump to one screen (25 lines) if possible. It's especially
important for Windows 9x/Me users who do not have a scrollable DOS console.
Stuffs like open dll libraries can go into error file.
8. Include JDK version in error message as well.
9. Allow user-specified error report site (not always
10. In item 6 above, it would be good if the native function names are
11. It would be good if there is an option to do a full Java thread dump
upon crashes (as in EVM). Currently by turning on -XX:ShowMessageBoxOnError,
when it crashes, we can still hit Ctrl+\ or Ctrl+Break to get a full Java
thread dump, if the crash happens in native state, but not in Java or
VM state. It would be good if we are offered an option to get a full
Java thread dump no matter where the crash happens.
12. In 1.3.1, if a crash happens in compiled Java code, only the Java
method name is shown but not its class name. And the Java stack trace
of the crashing thread is not reliably shown. It would be good if we
can always get the exact Java method and one easy workaround for that crash
may be just to exclude that method from being compiled.
13. In addition, for unhandled synchronous signals on solaris we should try
to report the faulting pc/npc (%eip for IA32), %sp and the faulting linear
address. The faulting linear address can be found in the siginfo_t.
The trapno and si_code might be useful as well.
14. In discussion with the webbug team, their top request is to not change
error id between releases for the same fatal error. Currently we use
filename plus line number to encode error id, which means whenever we make
changes to the source file, errorid could change.
15. It would be useful to include information about system configuration,
such as, #CPU, available memory, environment variables, etc. According to
the webbug team, users are much better at copy-n-paste error dump than
actually figuring out the configuration.