Kbase 15887: How to Get a Reliable Stack Trace Using Progress Utilities?
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
18/03/2009 |
|
Status: Verified
GOAL:
How does Progress get a reliable stack trace from a running process?
GOAL:
How to transfer a hexadecimal stack trace to a readable stacktrace Progress?
GOAL:
What is a protrace.nnn file?
GOAL:
How is protrace.nnn created?
GOAL:
How conditions have to exist for protrac.nnn to be reliably created?
GOAL:
What is tracecnv and how to use it?
FIX:
When a Progress executable produces a core file or when a core file is forced by a kill -8, the following message appears in the DB.lg file:
** Save file named core ...... (439)
The core file resides in the directory from which the executable was invoked. Its size is generally several megabytes, but the truly useful information comes from unwinding the program stack to show what routines had been called that lead up to the cause of the creation of the core file.
In an attempt to make sure that Progress gets a reliable stack trace, a module was added to Progress executables (uttrace) which is called by utcore.
This allows Progress to get the stack trace from the executable whileit is still in memory, rather than by examining a core file after the fact.
The utcore module still produces a file named core but the uttrace module tries to produce a file called protrace.nnn, where nnn is the PID of the executing program. Emphasis on the word "try".
In order for protrace.nnn to be successfully created, two conditions must be met:
1) The symbol table for the executable must reside in memory when the program is executing.
This condition is met on all platforms except Intel (386/486/pentium).
2) All kernel suppliers must provide Progress with a module that allows uttrace to access the kernel information necessary to do the stack trace.
To date, this has been done by all suppliers except IBM. On IBM platforms, a protrace.nnn file is produced but it contains the following message:
automatic stack trace functionality not supported.
On other non-Intel platforms that support the functionality, the protrace.nnn file contains something like the following:
PROGRESS stack trace as of Fri Jun 21 10:39:59 1996 Command line arguments are /usr/dlc7c/bin/_progres -1 dismat
uttrace (x7fffeac8, x7ffff160, x7ffff114, x0)
utcore (x7ffff160, x7ffff114, x0, x7ffff114)
drexit (x2, x2, x7ffff160, x7ffff114)
msgout (x7002, x7fffed38, x1eb, x7ffff160)
On platforms where the module names cannot be determined, the protrace.nnn file contains something like the following:
PROGRESS stack trace as of Fri Jun 21 10:39:59 1996
Command line arguments are /usr/dlc7c/bin/_progres -1 dismat
297d1c (x7fffeac8, x7ffff160, x7ffff114, x0)
297bf6 (x7ffff160, x7ffff114, x0, x7ffff114)
be43 (x2, x2, x7ffff160, x7ffff114)
a589 (x7002, x7fffed38, x1eb, x7ffff160)
On Intel platforms (386/486/pentium) where the symbol table is not kept in memory with the executable, there is a script in $DLC/bin directory called tracecnv that converts the hexadecimal addresses to their symbolic equivalent.
NOTE: On these Intel platforms, the nm command must be called with the -xvp option.
Output from tracecnv can appear in different formats but you can expect to see either of the following:
9D7C0 ---> uttrace (x7ffff3a8, xffffffff, x6c682, xa01bf)
9D6BC ---> utcore (x7ffff400, x61b6, x2, x2)
5DDC ---> drexit (x2, x2, x7ffff494, xab19d)
61B6 ---> drHdlError (x8, x0, x420000, x1f)
or,
( 0) 0x0025c2a8 uttraceback + 0x18 [/dlc/bin/_progres]
( 1) 0x00251fa8 uttrace + 0xa4 [/dlc/bin/_progres]
( 2) 0x00251eb8 utcore + 0xbc [/dlc/bin/_progres]
( 3) 0x0000efc0 drexit + 0x230 [/dlc/bin/_progres]
( 4) 0x0000f700 drSigFatal + 0x68 [/dlc/bin/_progres]