论文学习—英文.docVIP

Using SystemTap to analyze functional problems Functional problems, also known as bugs, are not unknown among developers and some ofthem are really hard to fix. The first step is to understand what the system is actually doinginstead of what it should be doing. This chapter introduces some new SystemTap functions and shows how to use them toanalyze functional problems. We cover several sample scenarios: 1. Generating a call graph 2. Retrieving function arguments and return values 3. Generating a stack trace 4. Reading data at specific locations 5. Probing functions, unknown pointers 6. Signals 7. Probing TCP and UDP 8. Probing page faults 1 Generating a call graph In order to debug functional problems in a section of code, it is often necessary to have an understanding of the flow of execution through the code. An easy way to get a quick understanding of the flow is by creating a call graph. SystemTap makes this very simple. The simple script in Example 4-1 displays a call graph. Example 1-1 Creating a call graph probe module(“ext3”).function(“*”).call { printf(“%s - %s\n”, thread_indent(1), probefunc()) } probe module(“ext3”).function(“*”).return { printf(“%s - %s\n”, thread_indent(-1), probefunc()) } This example will create a call graph of the ext3 module. Example 4-2 shows a partial example of the output from executing the script in Example 4-1 while running the Linux ls command. Example 1-2 Partial output from Example 4-1 0 ls(6218): - ext3_permission 3 ls(6218): - ext3_permission 0 ls(6218): - ext3_dirty_inode 3 ls(6218): - ext3_journal_start_sb 8 ls(6218): - ext3_journal_start_sb 12 ls(6218): - ext3_mark_inode_dirty 16 ls(6218): - ext3_reserve_inode_write 20 ls(6218): - ext3_get_inode_loc 23 ls(6218): - __ext3_get_inode_loc 28 ls(6218): - __ext3_get_inode_loc 31 ls(6218): - ext3_get_inode_loc 35 ls(6218): - ext3_reserve_inode_write 39 ls(6218): - ext3_mark_iloc_dirty 43 ls(6218): - ext3_mark_iloc_dirty 46 ls(6218): - ext3_mark_inode_dirty 49 ls(6218): - __e