Symbol table-nm command in the function library file

The nm command can list the symbol tables in a function library file. It works for both static function libraries and shared function libraries. For a given function library, the NM command can list all the symbols defined in the function library, including the values and types of each symbol. You can also define the number of rows of the function (Symbol) in the original program. However, this requires that the "-l" option be added when compiling the function library.

Here we will discuss the types of symbols. The type of a symbol is displayed in the form of a letter. lowercase letters indicate that the symbol is local, while uppercase letters indicate that the symbol is global (externel ). Generally, there are several types: T, D, B, U, W. Their meanings are as follows: T indicates the general variable symbol defined in the Code segment; D indicates the initialized data segment; B indicates the initialized data segment; A indicates that the data segment is not defined, it is used in this library, but it is defined in other libraries. The abbreviation of W and weak indicates that if the symbol is also defined in other libraries, the definition of other symbols can overwrite this definition.

If you know the name of a function, but you do not know the library in which the function is defined, you can use the "-o" option of Mn and the grep command to find the library name. The-O option enables each row to display the file name of this function library. For example, if you want to find out where "Cos" is defined, you can use the following command:

NM libuserdecorate. So-A-L 2>/dev/null | grep init_cnf
Libuserdecorate. So: 0002e476 T _ partition/data/home/Macy/SVN/isd_qqvipserver_rep/decorate_proj/trunk/operate_server/src/main/user_decorate_server.cpp: 76

 

More detailed usage of NM: Man nm

 

A troubleshooting article by another colleague Steven:

There are two problems with online notifications:

1. Shared Memory leakage

2. There is no dettach after shared memory attach. The online notification has special usage for shared memory. Attach is called in each function to use the shared memory. In this way, after each use, there is no dettach. The consequence is that the number of nattach of SHM keeps increasing, which leads to program core to a certain extent. I haven't found the cause for this problem for a long time. I added printf To The Destructor and found that I didn't call the Destructor at all. When you plan to modify the usage of the shared memory (the shared memory is only attach at startup to avoid attach in the function), Master still helps you identify the key to the problem.

 

The following describes the analysis and positioning of these two problems.

1. Shared Memory leakage location

Ø view the shared memory usage on the faulty machine, and use IPCS-m to view a large number of shared memory segments as follows:

------ Shared memory segments --------

Key shmid owner perms bytes nattch status

0x00000000 1835059 user_00 600 204800 0

0x00000000 1867828 user_00 600 20 0

The SHM key is 0 and the size is fixed.

The number of shared memory blocks with a size of 204800 is counted when the program is started on the development machine. IPCS-M | grep 204800 | WC-L. It is found that the number increases by 1 each time it is started.

View the online notification process ID

Check the shared memory usage of each process:

The timestamp information is omitted for ease of display.

1) cache_main process:

2) notify_worker process ID is 11639)

The main character appears. The worker uses a SHM block of 204800 and the key is 0.

3) weihu_worker (process ID 11637)

It is found that only a 16 m SHM is used, which is the SHM between worker and proxy.

Ø conclusion: each time the policy_worker process starts, a shared memory block with a SHM size of 204800 will be created. Check the initialization function, and there is no corresponding creation process. Later, we compared the difference with the previous version and found that the previous version has a corresponding creation process, this is because I did not re-compile it immediately after I commented it out, and later I forgot this :(

Pay attention to the check when using shared memory in the future !!!

2. No dettach after shared memory attach, resulting in core.

First, check the constructor code of the destructor in the process. Execute GDB cache_main

Disassemble main has a lot of information. Find the following information:

Disassemble cshmqueue as follows:

 

Continue disassembly ~ Cshmqueue, as follows:

It is found that this function is a null function. According to the code logic, this function should analyze its members cshm and CSEM objects, so as to dettach the shared memory. Then, it is estimated that the function will be replaced when linked to the shared memory.

 

Write a simple script to disassemble all the static databases and filter the results using cshmqueue. The following information is displayed in libcredence2.a:

Found this ~ Cshmqueue is t, a strongly typed function.

 

Let's look at our own destructor and use nm-C cnotitysvr. o | grep cshmqueue to view the following:

Found this ~ Cshmqueue is W, weak type function, because our destructor is an inline function.

You can also view the details as follows to confirm that the Destructor is ours:

Note: If you cannot find the inline destructor in the static library implemented by cshmqueue using nm, you can only find it in the target file using this class.

 

Finally, confirm our ~ Cshmqueue is overwritten by the Destructor with the same name in libcredence2.a. The reason why there is no warning or error prompt during compilation is that our destructor is an inline function.

Solution:

Use namespace to restrict the scope of the class.

Ø in future class implementation, constructor and destructor should be put in the source file as much as possible, or use a specific namespace for restrictions.

 

Extended reading (Development and use of library documentation) http://www.cppblog.com/amazon/archive/2010/01/12/105471.html