Status: Verified
GOAL:
How to produce a readable text file from a core file that is created as a result of a Progress system error?
GOAL:
How to use adb, sdb, or dbx to get a stack trace from a core file?
GOAL:
How to convert a core file to a stack trace?
GOAL:
How to debug a core file?
GOAL:
What are some of the debuggers available in UNIX?
GOAL:
How to use dbx?
GOAL:
How to use adb?
GOAL:
How to use sdb?
GOAL:
How to use _fst?
GOAL:
How to find which executable is associated with a core file
GOAL:
How to generate a stack trace from a core file
GOAL:
** Save file named core for analysis by Progress Software Corporation. (439)
FACT(s) (Environment):
UNIX
Progress/OpenEdge Versions
FIX:
A Progress system error usually produces a core file on a UNIX machine. When the core file is created, you receive the following message:
** Please save file named core for analysis by PSC (439)
The following instructions on how to produce a readable stacktrace are for UNIX based systems, and require the UNIX debugging utilities such as adb, sdb and dbx; for SCO UnixWare platforms _fst is required.
A core file is a binary file that contains large amounts of information. It is not something that can be read and understood in the manner by which it was produced. Rather, you must use an operating system utility (adb, sdb, dbx, _fst) to interpret the information in the core file and redirect the informative pieces of data to stdout or to a file for further analysis by a Technical Support Engineer.
Information from this output is often referred to as a stack trace. A stack trace can be useful in determining what was happening when the system error occurred. Core files are located in the directory where the executable that "cored" was initiated.
Progress Version 7.3E and later also creates a secondary file in this same directory called a protrace file. The protrace file has a naming convention protrace.nnn (where nnn is the process identification [PID] of the process that produced the core file). This file is a Progress-generated stack trace.
Some protrace.pid files might contain just hex values. This is common for UNIX operating systems running on an Intel based platform. Here, you must either generate a stack trace from the core file using the operating system utilities (adb, sdb, dbx, _fst) or use another Progress utility called tracecnv to massage the protrace.pid file.
On IBM platforms, it is common to see protrace.pid files which state "cannot unwind stack", or "stack utility unsupported". This message means that Progress was not able to generate its own stack trace file (protrace.pid) from the core file. In this case, you must use the operating system utilities (adb, sdb, dbx, _fst) against the core file in order to produce a stack trace that is useful to a Technical Support Engineer.
To determine whether you have adb or sdb on your system, look in the /bin directory or check with your system administrator on whether the debugger has been installed.
NOTE: SCO UnixWare and SCO OpenServer provide _fst to analyze core files. This debugging utility is identical to adb and the steps outlined below apply. However, _fst is not copied to the disk when SCO is initially installed. It is installed separately. _fst is found in the /etc directory.
Executing the debugger utility with the Progress executable in the $DLC directory might not always produce a good stack trace. A good stack trace should contain a list of C modules that were executing when the system error occurred.
The stack trace should include some, if not all, of the following routines:
utcore, drexit, drHdlError, _sig*
If you do not see these system calls, take the following steps:
1) Type (strings core | more) to determine the executable that cored.
2) Make a copy of the progress executable (for example, cp _progres _rx).
3) Use the chown command to change the ownership of this _progress copy to the userid of the user that executes the debugger utility (for example, chown userid _rx).
4) Use the chmod command to remove the setuid bit on the executable (for example, chmod u-s _rx).
Debuggers are:
adb:
adb $DLC/bin/<executablename> core
$> stacktrace (directs output to a file named stacktrace)
$r (displays values of the registers)
$c (traces back function calls)
$> (redirects output back to the terminal)
$q (exits adb)
NOTE: The ("$") is n.ot a prompt, you must type it in.
sdb:
sdb <executablename> core > stacktrace
t (traces back function call)
x (displays values of registers)
q (exits sdb)
_fst:
Same steps as ADB.
dbx:
dbx <path-for-the-executable> core | tee dbx.out
Note: if you have copied the executable, put your own path to executable in the above command
(dbx)
at this prompt type "where"
NOTE: This displays the stack trace to the screen and also to the output file (dbx.out).
(dbx)
At this prompt type "quit" to exit the utility.
pstack (only available on Solaris):
pstack core | tee pstack.out.