Debug Core Dumps / Core Files on UNIX

Checked relevance 29-AUG-2006 Creating a Stack Trace From a Core File Anyone who has worked with UNIX for any reasonable period of time is likely to have run into a 'core dump' situation. When an application runs into something that the process should be aware of, it generates some signals. Signals are software interrupts. They provide a way of handling asynchronous events, e.g. a user request to stop a process. For every signal there is a default action. The application that generates the signals can choose to ignore or catch those signals or let their default action apply. When the default action is labeled 'terminate w/core' the application terminates with a 'core dump'. The core file is left in the current working directory of the process. It contains a memory image of the process at the time of the termination. (The fact that the file is named core shows how long this feature has been part of UNIX.) This file can then be used with most Unix debuggers to examine the state of the process at the time it is terminated. The core file will not be generated if (a) the process was set-user-ID and the current user is not the owner of the program file, or (b) the process was set-group-ID and the current user is not the group owner of the file, or (c) the user does not have permission to write in the current working directory, or (d) the file is to big. A 'core dump' can occur under the following circumstances: (a) Dividing by zero or (SIGFPE) other arithmetic exceptions vary by port. (b) Dereferencing invalid address. (SIGSEGV) (c) Dereferencing "impossible" address (SIGBUS) (d) Executing illegal instructions (SIGILL) The permissions of the core file are usually user-read, user-write, group-read, and other-read, $ ls -l core -rw-r--r-- 1 bclinton 8483248 Dec 31 12:00 core The Unix debuggers that can be used to extract more information from a core file include: dbx, adb, crash, xdb, sdb, kadb, etc. The most common ones used are dbx and adb. This bulletin will explain how dbx can be used. Suppose Forms40 runtime f40runm produced a core dump. To analyse the core file with dbx, use the following command, C shell: dbx $ORACLE_HOME/bin/f40runm core | tee stack.trc Bourne or Korn shell: dbx $ORACLE_HOME/bin/f40runm core 2>&1 | tee stack.trc It is very important to include the full path of the executable. It is also recommended(but not necessary) to have read priviledge on the executable. In this case only Oracle can use chmod to alter the file protection on f40runm. Once the command is issued, dbx will print out several lines of information and then return to a dbx prompt(dbx). Type 'where' at the prompt(no quotes when actually entering it) dbx will print out the stack trace. Type 'quit' at the prompt to exit out of dbx. All the output should be captured in a file called stack.trc. Now contact Oracle Support with this stack trace file. An alternative method to capture the stack trace output from a Unix debugger is to use the 'script' command. Running 'script' without any arguments will start a new shell and save all terminal output into a file named 'typescript' in the current directory. Be sure to 'exit' from the 'script' command after leaving the debugger. With other UNIX debuggers, the commands to retrieve stack trace are slightly different. For example, Debugger Trace Command Exit Command -------- ------------- ------------ adb $c Ctrl-D sdb t q xdb t 100 quit On Windows, the equivalent of a 'core dump' is a GPF(Generic Protection Fault). A Windows application called drwatson.exe can be used to capture and diagnose a GPF. It resides under c:windows. On VMS, a similar application termination will produce a 'stack dump'. Unlike a 'core dump', a 'stack dump' will print out all the useful information about the application's status at the point of termination on the screen. Therefore, there is no need for using any outside debuggers.