In the above example, the output includes the PID ( pid=10791) and also the thread ID ( tid=1026). If Microsoft Visual Studio is installed, the default debugger is typically configured to be msdev.exe. This debugger is configured by a registry setting which is described in Collect Crash Dumps on Windows. If the user clicks Yes, the VM will attempt to start the default debugger. If the user enters y or yes, then gdb will be launched (assuming it is set in the PATH variable). In this case, a SIGSEGV error occurred, and the user is prompted to specify whether the gdb debugger is to be launched to attach to the process. To debug, run 'gdb /proc/10791/exe 10791' then switch to thread 1026Įnter 'yes' to launch gdb automatically (PATH must include gdb) The following example shows a fatal error on a Linux system.
#The java jar file cannot be launched mac windows#
In the case of Windows, a Windows message box pops up. In the case of the Linux operating system, the output and prompt are sent to the application console (standard input and standard output).
When this option is set and a fatal error occurs, the HotSpot VM will display information about the fatal error and prompt the user to specify whether the native debugger is to be launched. In the example, the userdump.exe utility is executed to create a core dump of the current process in case of a fatal error. The utility does not ship with Windows and should be downloaded from the Microsoft website as a part of the Microsoft OEM Support Tools package. On Windows, the userdump.exe utility creates a crash dump of the specified process. In the example above, the gdb debugger is launched and attached to the current process when an unexpected error is encountered. On Linux, the gdb command launches the debugger. In the example above, the contents of the fatal error log file are mailed to a support alias when a fatal error occurs. Java -XX:OnError="cat hs_err_pid%p.log | mail MyApp The following examples demonstrate how this option can be used when launching a Java application named MyApp with the java launcher. Within this string, all occurrences of %p are replaced with the current PID, and all occurrences of %% are replaced by a single %. The script or command is specified using the -XX:OnError= string command-line option, where string is a single command, or a list of commands separated by semicolons. When a fatal error occurs, the Java HotSpot VM can optionally execute a user-supplied script or command. For example -XX:HeapDumpPath=/disk2/dumps will cause the heap dump to be generated in the /disk2/dumps directory. You can specify an alternative file name or directory with the -XX:HeapDumpPath= option. In this case the file is 507 MB and is created with the name java_pid2262.hprof in the current directory.īy default, the heap dump is created in a file called java_pid pid.hprof in the working directory of the VM, as in the example above. When the exception is thrown, a heap dump file is created.
The ConsumeHeap fills the Java heap and runs out of memory. Heap dump file created Įxception in thread "main" : Java heap spaceĪt ConsumeHeap$BigObject.(ConsumeHeap.java:22) $ java -XX:+HeapDumpOnOutOfMemoryError -mn256m -mx512m ConsumeHeap
The following example shows the result of running out of memory with this flag set. You can also specify this option at runtime with the MBeans tab in the JConsole utility. There is no overhead in running with this option, so it can be useful for production systems where the OutOfMemoryError exception takes a long time to appear. This option tells the Java HotSpot VM to generate a heap dump when an allocation from the Java heap or the permanent generation cannot be satisfied. The -XX:HeapDumpOnOutOfMemoryError Option
0 kommentar(er)
