【STACKX】Oracle core file分析利器STACKX 使用指南

If a file download dialog box does not appear when clicking on the above link, you may need to clear your web browser's cache and/or restart your web browser.

Back to Contents

Debuggers recognized and discovered by  stackx are (in order of preference):

• gdb
• mdb (Solaris only)
• adb
• dbx
• sdb

Back to Contents

stackx is distributed as a tar archive, stackx.tar. 

To install  stackx,

1. Create a new directory on the target machine where you would like  stackx to be installed
2. Copy the distribution file to the new directory on the target machine. 
3. Untar the resulting uncompressed file in the following manner:

Three files will be extracted:

• stackx -- the "run" script
• README.txt -- a guide on using  stackx in text format
• README.htm -- a guide on using  stackx in html format

Back to Contents

To uninstall  stackx remove the files in the  stackx directory created during the install.

Back to Contents

To run  stackx simply invoke the  stackx script, passing either a local core filename or the fully qualified core filename as an argument. In the following examples a core file named core.1234 is used.
 

Optionally, if a particular debugger is desired, or no debugger is available in the path, a fully qualified debugger name can be passed as an optional first argument. If the desired debugger is in the current path, then it does not have to be fully qualified with path name. However, a fully-qualified name will eliminate issues of ambiguity where more than one otherwise-identical debugger executable is installed on a machine:
 

If you want output sent to a text file:
 

NOTE: The core file does not have to be in the local directory. A fully qualified filename can be accessed by  stackx, but only if read permission is available to the executing session on that file. It may be necessary to execute  stackx as root, or to change permissions on the core file. For a core file named core.1234, you can set global read permission this way:
 

Back to Contents

Processes that run multiple threads present a special case for diagnostic efforts. In order to be useful for diagnosing problems, a stack trace for each thread must be generated.  stackx will invoke appropriate commands for debuggers to extract stack traces for all threads in a core, if the underlying debugger supports this type of operation. Such utilities include:

• gdb
• mdb Solaris only)
• adb
• dbx

However, such support is not universally available on each debugger. In particular, older versions of adb and dbx do not support multi-threaded cores. Unfortunately, there is no reliable way to determine the version of a debugger prior to running it. As such,  stackx may not operate properly if a multi-threaded core is generated and a non multi-threaded debugger is used. It is recommended to install a debugging utility that supports multi-threaded programs and cores. The gdb debugger is generally available as an open-source utility and can be freely downloaded and installed for most platforms. Current versions of gdb support multi-threaded cores.

stackx may also be run on platforms not listed in this document, but support is nevertheless restricted to those debuggers listed here. To determine if a debugger is available on your platform, do the following for each debugger of interest:

If a debugger is available, it will be displayed with the fully qualified pathname. However, if a particular debugger is not found, it may simply be that the current path does not reflect its location. For further assistance, consult the administrator of the machine of interest.

Oracle Support recommends testing unlisted platforms on a non-production server first, as behavior may be unpredictable.

Back to Contents

 and Enhancements, release 1.3 (December 3, 2015)

1. Removed support for pstack, as mdb provides better output.

2. Improved tagging to identify for stack traces of all threads, and to contain stack trace of current thread.

3. Added tag section to contain initial debugger output for ease in parsing output by other tools.

4. Cleanup of output, including duplicate errorstack output when multiple executable names are discovered in the core. Now, only first executable name is used.

5. Cleanedup discovered executable name to express full path. eg, ./a.out becomes /use/bin/whatever/a.out.

6. Tidied up header information, renamed CPU Bits to CPU Type.

 and Enhancements, release 1.2 (August 22, 2007)

1. Corrected comparator operator to -gt

2. Added register info (all registers), gdb only

3. Corrected for AIX, 'file' command output variation.

4. Improved output tagging, to more uniform xml-like presentation to ease parsing for support tools.

5. For dbx, added redundant debug command syntax to accommodate syntax variations among non-detectable versions of the dbx  debugger. Some spurious output will be generated, but probability of stack extraction is greatly improved.

6. The two character limitation on detected program name no longer applies.  stackx is expected to reliably find the name of all core-generating executables.

7. Corrected expression syntax in determining execCount
   

 and Enhancements, release 1.1

1. AIX has differences in output from 'which' command, corrections made to accommodate this platform issue.

2. AIX has differences in output from 'file' command, corrections made to accommodate this platform issue.

3. dbx now given priority over adb as default debugger selection.

4. Documentation clarifies need to run  stackx on same machine on which corefile was created.

Back to Contents

1. Multi-threaded cores may not be supported by all debuggers, particularly on older platforms, as noted above. The remedy is to install a more contemporary debugger, such as gdb.
    
2. There may be some cases where the executable application program name cannot be determined reliably, regardless of program name length. In such cases,  stackx will not extract a stack trace for that core file, but will report this fact in its output. There is no workaround for this limitation.
    
3. The stack trace extraction should be performed on the machine on which the core was created. If the core file is moved to a different machine, and then  stackx run on that new machine, two major problems can occur:
    
   1. The core file may not be binary-compatible with the new machine, in which case the debugging operation will likely fail. An example of this would be a core file from a HP-UX machine, and an extraction attempt from a Solaris machine. Please run  stackx on the machine on which the corefile was created.
       
   2. The executable file may not be located in the actual path location as on the original machine. Since  stackx gets the name of the executable that created the core file, that executable path name is also extracted from the core file. If the executable is in a different path from the machine on which the corefile was created, then the debugger will not be able to extract a stack trace for that core file.

Back to Contents