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
   "function_name:offset".

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
   "http://java.sun.com/cgi-bin/bugreport.cgi")

10. In item 6 above, it would be good if the native function names are
    demangled.

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.