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

来源：这里教程网时间：2026-03-03 17:22:35 作者：

Introduction Supported Platforms Download STACKX Debuggers Recognized Installing STACKX Uninstalling STACKX Running STACKX Thread Support Bug Fixes Open Issues and Limitations Reporting Feedback

Introduction

stackx is a shell script utility for extracting diagnostic stack trace information from core file on UNIX/LINUX platforms. Core files are typically created when an application program fails in such a way it cannot continue operation. Often this is from an attempt by the application program to access a memory location outside its range permitted by the operating system. When this happens, the operating system sends a signal to the program, which in turn may produce a disk file containing information about its operation, prior to the program terminating execution. This file is the "core" file, and contains information on program functions called immediately prior to program failure. This information is called a "stack trace" or "back trace" and is embedded within the binary core file, which is not human readable. In order to extract the useful information and put it into human readable form, some effort is required. stackx assists in that effort. Stack trace information normally consists of a list of the current program function (at time of termination) as well as the "stack" of functions called prior to the current function. This information can be instrumental in determining the cause of a program failure, if it is extracted properly. Extracting stack trace information from a core is not difficult, but this operation requires an operating system utility known as a debugger, or other similar utility, and the specific technique required varies with the debugging utility used. To simplify this effort, stackx was created to provide a simpler and consistent command line interface for automating this operation. stackx works as follows:

Chooses a debugger from a list of supported utilities in the current environment path, or a user-specified debugger passed as a command line argument.

Finds the core-generating application program name from inside the core file.

Runs the debugger and passes appropriate commands to that debugger.

Output is text, normally displayed to the users screen. Output can be redirected to a trace file by passing an appropriate redirect operator and output filename, in the conventional UNIX manner. This is shown in the RUNNING STACKX section below. Back to Contents

Supported Platforms

Core stack trace extraction is supported on the following platforms:

IBM AIX Intel Linux (RedHat and SuSE) HP-UX (10.* and 11.*) HP Tru64 Sun Solaris (2.5 - 2.10)

Back to Contents

Current stackx Version: 1.3.0 December, 2015

Click here to download the file (use the name stackx1_3.tar when saving). 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

Installing STACKX

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

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

$ tar -xvf stackx.tar

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

Un installing STACKX

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

Running STACKX

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.

$ stackx core.1234

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:

$ stackx /usr/bin/adb core.1234

If you want output sent to a text file:

$ stackx core.1234 > stacktrace.txt or $ stackx /usr/bin/adb core.1234 > stacktrace.txt

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:

$ chmod +r core.1234

Back to Contents

Thread Support

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:

$ which <debuggername>

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

Bug Fixes and Enhancements, release 1.3 (December 3, 2015)

Removed support for pstack, as mdb provides better output.

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

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

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

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

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

Bug Fixes and Enhancements, release 1.2 (August 22, 2007)

Corrected comparator operator to -gt

Added register info (all registers), gdb only

Corrected for AIX, 'file' command output variation.

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

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.

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

Corrected expression syntax in determining execCount

Bug Fixes and Enhancements, release 1.1

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

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

dbx now given priority over adb as default debugger selection.

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

Back to Contents

Open Issues and Limitations

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. 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. 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:
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. 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