Source: https://www.cnblogs.com/fifteen/archive/2012/03/20/2407449.html
Recent work involves analyzing the core dump file, finding this good post, and then turning to my blog O (∩_∩) o~
Ps:
Where can you get dbx?
It is part of Bos.adt.debug
# lslpp-w/usr/bin/dbx
File Fileset Type
-------------------------------------------
/usr/bin/dbx Bos.adt.debug Symlink
The following transfers are from: http://www.aixchina.net/?6141/viewspace-18882
Introduction to the I Core dump analysisenvironment variable Settings
The basic configuration parameters for each user, including the core size, can be limited through the/etc/security/limits file. or change the core size limit for the current environment with Ulimit.
By default, the app process uses the file name core when it generates core dump. To prevent the process core from overwriting each other under the same working directory, you can define the environment variable core_naming=true and then start the process so that a file named Core.pid.ddhhmmss is generated. You can use the file Core command to see which process is generating the core.
By default, the application process dump contains all of the shared memory, and if you want to exclude shared memory content at dump, you can set the environment variable core_noshm=true before starting the process.
The system has a parameter fullcore to control whether the complete core is generated when the program Coredump. To avoid information loss, it is recommended to open Fullcore. You can use the Lsattr–el sys0 query to open fullcore, use chdev-l sys0-a fullcore=true to change the Fullcore state to open. You can also call the Sigaction routine in the program to set the Fullcore, refer to the following test program:
Fullcore Setup Example
|
Find Core Dump
The core of the application process is generated under its current working directory and can be used within the application to switch the current working directory using the CHDIR function. Use the PROCWDX command to view the current working directory of the process. The core of the system is generated under LG_DUMPLV and is transferred to the/var/adm/ras/directory (if there is enough space) on the reboot, and remains in the LG_DUMPLV and is likely to be overwritten at any time.
You can use Errpt-a to view detailed error messages that identify c0aa5338 Sysdump (System core), B6048838 Core_dump (Process Core), get the process of generating the core, and the location of the core file. Use SNAP–AC to collect dump information for the system.
Core Dump information collection
If possible, using DBX to analyze the results directly on the machine where the coredump is occurring is the most convenient method of analysis. In this case, be careful not to log in directly with the root user and then analyze with DBX, but you must do so under the user to which the application belongs, because the core may need to rely on some libraries in the context of the application runtime, so that the application's environment variables will be used.
If you need to retrieve the core information from the production machine in the laboratory analysis, you need to collect some relevant information. Process core analysis typically relies on at least the application executable program, and sometimes includes some runtime dynamic library information. If you need to collect complete core-related information, run the Snapcore <core path along with the name > < executable file and name, such as Snapcore./core./a.out, and then remove it under/tmp/snapcore The corresponding. Pax. Z file.
The normal collection process should be as follows:
Snap Core collection Process
|
II example of using DBX to analyze core dump
DBX is a source-level debugging tool based on the command line interface under AIX. This document only provides some basic DBX analysis instructions, please refer to "General Programming concepts:writing and Debugging Programs" for the description of DBX for more information.
Preliminary analysis
|
Example:
# dbx./test Core |
Shows the location where the current process executes when the core occurs (a specific row can be seen in the case of-G compilation):
(DBX) where |
Attention:
If you are analyzing an offsite core file, you need to use Snapcore to collect relevant core information. For dependent link libraries, note that you need to increase the -p ldpath=newpath:... Reset link library path (only all dependent libraries have been linked to fully reproduce the core dump fault site), refer to the DBX Help documentation for more information.
# Cd/tmp/snapcore |
List source information
List the program source code (list, you need to run the DBX command using-I to indicate the source search path, and use-G compilation) or the sink code (LISTI):
(DBX) Listi main |
Enumerating Variable Contents
Example code:
#include <iostream> |
Take the global variable G_test example:
#print G_test shows the value of G_test
#print sizeof (g_test) shows the size of the G_test
#whatis G_test shows the type of g_test
#print &g_test shows the address of the G_test
#&g_test/16x displays the value of 16 consecutive WORD (? byte) from the beginning of the address of the G_test
If you do not use the-G compilation, you cannot dynamically obtain information such as the type, size, and so on of the g_test, but you can get the address of g_test and query the value of the area where the address is stored.
For example:
#./a.out |
Enumerating the contents of registers
List the contents of the Register:
(DBX) Registers
The following simulation of a simple core dump, assigning a value to 0 addresses raises the issue of core dump:
# dbx./a.out Core |
This example is relatively simple, from the final assembly instruction "STW r3,0x0 (R4)" Can simply see that the program core dump is due to 0 address (0+R4) deposit (R3 Register value) caused.
View Multithreading-related information
If the following environment variables take the default OFF value, the system completely disables the appropriate debug list, which means that the DBX command will not show any objects:
Aixthread_mutex_debug
Aixthread_cond_debug
Aixthread_rwlock_debug
can use
Export Aixthread_mutex_debug=on
Open Aixthread_mutex_debug.
(DBX) Print $t 1//print basic information for T1 threads
(dbx) attribute
(DBX) condition
(DBX) Mutex
(DBX) Rwlock
(DBX) thread
For example:
(thread_id = 1, State_u = 4, priority = $, policy = other, attributes = 0x20001078)
(DBX) thread current [Tid]
For example (> indicates the current thread at core dump):
(DBX) thread |
Limitations of Core Dump analysis
Do not expect to be able to rely on core dump analysis to solve all the problems, here is a simple example of buffer overflow, in this example, because the buffer overflow overwrite the call stack information, thus completely lost the positioning basis:
[Email PROTECTED]/TMP#>XLC test. C-g-O test2 |
System Dump Analysis
environment variable Settings
The current dump configuration information for the system can be viewed through "sysdumpdev–l":
[Email protected]/#>sysdumpdev-l |
Note that older versions of AIX "Always allow dump" may be turned off by default, it is recommended to open when the system is crash, you can use command sysdumpdev–k, or use Smitty, System Environments-> ; Change/show Characteristics of System Dump menu settings.
Sysdumpdev–l get statistics about the recent dump generated by the system:
#>sysdumpdev-l |
In order to ensure that the system appears crash, dump device can save the dump information, need to reasonably configure the size of the dump device, you can use Sysdumpdev–e to estimate the space required by the system dump. The general recommended dump device value is 1.5 times times the size of the sysdumpdev–e estimate.
environment variable Settings
This document only provides some basic dump analysis instructions, please refer to "KDB Kernel debugger and KDB command" for more information.
Preliminary analysis
The KDB dump file analysis requires the use of the kernel file/unix that generated the dump, which is typically collected by SNAP–AC. The preliminary order is as follows:
#kdb./dump./unix
Example:
#kdb./dump./unix |
Analysis Command Example
Status to see the processes that each CPU is running at dump, such as:
0) > Status |
CPU <id> command Toggles the current CPU, the default current CPU is CPU0:
(0) > CPU 1
(1) >
Basic status and related information of the printing system:
(0) > Stat
When printing the system dump, the kernel stack:
(0) > F
Lke is used to list the relevant system file information for the kernel code:
(0) > Lke 003de9cc
Show the last command when the system dump:
(0) > Dr IAR
Displays the log information for virtual storage management, where Exception value of 0000001C means Pagingspace exhausted:
(0) > Vmlog
Display information for the process table:
(0) > Proc
To display information about the thread table:
(0) > th
Display the system's ERRPT information:
(0) > Errpt
< END >ERRORS not READ by Errdemon (ORDERED chronologically):
Error Record:
Erec_flags ........ 1
Erec_len .......... 54
Erec_timestamp ..... 46dcdd9d
Erec_rec_len ....... 34
Erec_dupcount ...... 0
Erec_duptime1 ...... 0
Erec_duptime2 ...... 0
erec_rec.error_id ..... Dd11b4af
Erec_rec.resource_name. Sysproc
00007FFF FFFFD000 00000000 003de9cc ... =......
00000000 00020000 80000000 000290b2 ....... .....
"Turn" uses DBX, KDB to analyze Coredump under AIX
Start building with 50+ products and up to 12 months usage for Elastic Compute Service
1 on 1 presale consultation
24/7 Technical Support 6 Free Tickets per Quarter Faster Response
Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.
A comprehensive suite of global cloud computing services to power your business
Payment Methods We Support
