Stackcore File Parsing
Description
Parse the stackcore file.
A stackcore file can be obtained from the following sources:
- Host-side stackcore file (stackcore_tracer_*.txt). Obtain the stackcore file by referring to section " Viewing Trace Logs" in Log Reference.
- Device-side stackcore file. For details, see section " Exporting System Logs and Other Maintenance and Test Information from the Device > Exporting System Logs and Other Maintenance and Test Information from the Device at a Time" in msnpureport Tool.
- Stackcore file obtained by using the coredump file parsing function of the asys tool.
Applicability
|
Product |
Supported |
|---|---|
|
Atlas 350 Accelerator Card |
√ |
|
|
√ |
|
|
√ |
|
|
√ |
|
|
√ |
|
|
√ |
Notes
The stackcore parsing function uses the readelf tool to obtain file information and the addr2line tool to parse stack function names and line numbers. Both of the tools are built-in tools of the Linux system. Ensure that the readelf and addr2line tools are installed, and that the user has the permission to execute scripts.
You need to run the stackcore file parsing command in the environment where the stackcore file is obtained. Otherwise, the parsing result may be inaccurate.
Command
asys analyze -r=stackcore --file=filename --symbol_path=path1,path2 --output=path3
Or
asys analyze -r=stackcore --path=directory --symbol_path=path1,path2 --output=path3
Parameters
- r : specifies the parsing mode. This parameter is mandatory. Set it to stackcore, which is used to parse stackcore files (*.txt files) for subsequent fault locating.
- file: used to parse a single file. Set this parameter to the file name containing the path. This parameter is mandatory in stackcore mode.
- path: It specifies a directory for parsing multiple files in the specified directory and its subdirectories. In stackcore mode, select either the path or file parameter. The two parameters cannot coexist.
- symbol_path: It specifies the dynamic library directory required for parsing in stackcore mode. Multiple directories can be transferred and separated by commas (,). Only the dynamic libraries in the current directory are scanned. Path 1 is scanned followed by path 2. Subdirectories are not scanned. To prevent incorrect parsing, you are advised to place related dynamic libraries in the same path. The stackcore mode is optional. If the symbol_path parameter is not specified, the required dynamic library path is obtained from the stackcore file. To ensure that the dynamic library file can be found, you are advised to use this mode only in the environment where the core dump error occurs.
- output (optional): Its value is used as the prefix of the result output directory of the asys tool. That is, the final output directory is {output}/asys_output_timestamp. If the command does not contain the output parameter, the output is stored in the command execution directory. If the value of output is empty or invalid, the specified directory does not have the write permission, or the directory fails to be created, the asys tool exits and reports an error.
Usage Example and Output Description
asys analyze -r=stackcore --file=stackcore_tracer_test.txt --symbol_path=$HOME/test1,$HOME/test2 --output=$HOME/dfx_info
The following is an example of the parsed .txt file. In the file, the thread information starts with Thread Number (Thread ID, Thread name). If the thread name fails to be obtained, unknown is displayed.
[process] crash reason:6 crash pid:37246 crash tid:37246 crash stack base:0x00007ffea1e96000 crash stack top:0x00007ffea1e91770 [stack] Thread 1 (37246, python3.7) #00 0x00007fbad83792bf lookdict_unicode in dictobject.c:811 from libpython3.7m.so.1.0 #01 lookdict_unicode in dictobject.c:783 from libpython3.7m.so.1.0 #02 0x00007fbad83d8c22 PyDict_GetItem in dictobject.c:1328 from libpython3.7m.so.1.0 #03 0x00007fbad83e9648 _PyObject_GenericGetAttrWithDict in object.c:1269 from libpython3.7m.so.1.0 #04 0x00007fbad83e6729 module_getattro in moduleobject.c:704 from libpython3.7m.so.1.0 #05 0x00007fbad83e937b _PyObject_GetMethod in object.c:1137 from libpython3.7m.so.1.0 ...... [maps] e0000380000-e0000381000 rw-p 00000000 00:00 0 e00003c0000-e00003c1000 rw-p 00000000 00:00 0 562677ed1000-562677ed2000 r--p 00000000 fd:00 13113992 /usr/local/python3.7.5/bin/python3.7 562677ed2000-562677ed3000 r-xp 00001000 fd:00 13113992 /usr/local/python3.7.5/bin/python3.7 562677ed3000-562677ed4000 r--p 00002000 fd:00 13113992 /usr/local/python3.7.5/bin/python3.7 ......
- If the parsed .txt file contains ?, the possible causes are as follows:
- Compile option: The -g option is not used during compilation of the dynamic library file to retain debugging information in the file.
- Link parameter not added: -rdynamic is not used to instruct the linker to add all symbols to the dynamic symbol table.
- Dynamic library not found: No matching dynamic library is found.
- When the stackcore parsing function parses function names and line numbers, the line numbers parsed from some dynamic libraries are slightly different from the actual situation. The reasons are as follows:
- Compile option: Different compile options, especially those related to debugging information, may have impacts.
- Optimization level: A higher optimization level may cause code reorganization and optimization, resulting in deviation between the line numbers and the raw source codes.