A coredump example of the virtual function of Linux x86 version 6.5, "Coredump Problem principle Inquiry"

In large projects, the problem of version mismatch is very easy, which leads to the problem of virtual function drift is more difficult to solve.

Here, an example is used to illustrate how to solve this problem.

Create three source files: Testso.h,testso.cpp,xuzhina_dump_c6_s3_ex.cpp.

The code for TESTSO.H is as follows:

  1 #ifndef __testso_h__  2 #define __TESTSO_H__  3   4 class xuzhina_dump_c6_s3_ex  5 {  6 public     :  7         Virtual char* encode (char* str);  8};        9  #endif

The code for Testso.cpp is as follows:

  1 #include <string.h>  2 #include "testso.h"  3   4 char* xuzhina_dump_c6_s3_ex::encode (char* str)  5 {  6     return str;  7}  8

The code for Xuzhina_dump_c6_s3_ex.cpp is as follows:

  1 #include <stdio.h>  2 #include "testso.h"  3   4 int main ()  5 {  6     char* Hello = (char* ) "Hello";  7     xuzhina_dump_c6_s3_ex* test = new Xuzhina_dump_c6_s3_ex;  8   9     char* p = test->encode (hello),     printf ("The second char:%c\n", P[1]);     return 0; 14}

Compile Code:

[[email protected] 3_ex]$ g++-o libtestso.so-shared-fpic testso.cpp[[email protected] 3_ex]$ g++-o xuzhina_dump_c6_s3_ Ex Xuzhina_dump_c6_s3_ex.cpp-l.-ltestso

Running XUZHINA_DUMP_C6_S3_EX can result in this:

[Email protected] 3_ex]$ export ld_library_path= $LD _library_path:.;. /XUZHINA_DUMP_C6_S3_EX the second char:e

Now add a virtual function to the Testso.h class (note the order of the virtual function declarations):

  1 #ifndef __testso_h__  2 #define __TESTSO_H__  3   4 class xuzhina_dump_c6_s3_ex  5 {  6 public     :  7         Virtual char* parseval (char* str);  8         Virtual char* encode (char* str);  9};  #endif在testso. CPP adds its implementation code:  1 #include <string.h>  2 #include "testso.h"  3   4 Char * Xuzhina_dump_c6_s3_ex::encode (char* str)  5 {  6     return str;  7}  8   9 char* xuzhina_dump_c6_s3_ex::p arseval (char* str) Ten {one     char* p = strstr (str, "=");     (P! = NULL)-     {         p+1 return;     \ n}-     return NULL; 17}

Regenerate so files, but do not regenerate xuzhina_dump_c6_s3_ex (why?). This is the simulation of several departments of collaborative product development process, often some version of the producer for the sake of trouble, not clear recompile)

[Email protected] 3_ex]$ g++-o libtestso.so-shared-fpic testso.cpp

Run XUZHINA_DUMP_C6_S3_EX, it coredump.

[Email protected] 3_ex]$ export ld_library_path= $LD _library_path:.;. /xuzhina_dump_c6_s3_ex./xuzhina_dump_c6_s3_ex:symbol ' _ztv21xuzhina_dump_c6_s3_ex ' have different size in shared object, consider Re-linkingsegmentation fault (core dumped)

To open the Coredump file, you can see the following stack:

(gdb) bt#0  0x08048630 in Main ()

Take a look at the assembly of the main function:

(GDB) disassemble maindump of assembler code for function Main:0x080485e0 <+0>: Push%EBP 0x080485e1 <    +1&GT: mov%esp,%ebp 0x080485e3 <+3>: Push%ebx 0x080485e4 <+4>: and $0xfffffff0,%esp 0x080485e7 <+7>: Sub $0x20,%esp 0x080485ea <+10>: Movl $0x80486f4,0x1c (%ESP) 0x080485f2 &lt ; +18>: Movl $0x4, (%ESP) 0x080485f9 <+25>: Call 0x80484d0 <[email protected]> 0x080485fe &LT;+30&GT: mov%eax,%ebx 0x08048600 <+32>: mov%ebx, (%ESP) 0x08048603 <+35>: Call 0x804    8650 <_ZN21xuzhina_dump_c6_s3_exC2Ev> 0x08048608 <+40>: mov%ebx,0x18 (%ESP) 0x0804860c <+44>:   mov 0x18 (%ESP),%eax 0x08048610 <+48>: mov (%EAX),%eax 0x08048612 <+50>: mov (%EAX),%eax 0x08048614 <+52>: mov 0x1c (%ESP),%edx 0x08048618 <+56>: mov%edx,0x4 (%esp) 0x0804861c <+6 0&GT: mov 0x18 (%eSP),%edx 0x08048620 <+64>: mov%edx, (%ESP) 0x08048623 <+67>: Call *%eax 0x08048625 <+69&gt ;: mov%eax,0x14 (%ESP) 0x08048629 <+73>: mov 0x14 (%ESP),%eax 0x0804862d <+77>: Add $0x1, %eax=> 0x08048630 <+80>: Movzbl (%eax),%eax 0x08048633 <+83>: MOVSBL%al,%eax 0x08048636 <+86& GT: mov%eax,0x4 (%ESP) 0x0804863a <+90>: Movl $0x80486fa, (%ESP) 0x08048641 <+97>: Call 0x 80484C0 <[email protected]> 0x08048646 <+102>: mov $0x0,%eax 0x0804864b <+107>: mov- 0x4 (%EBP),%ebx 0x0804864e <+110>: Leave 0x0804864f <+111>: ret End of assembler dump.

Look at the value of the register EAX

(GDB) I R eaxeax            0x1      1

Visible, because the value of EAX is 1. and EAX by

   0x08048623 <+67>:    call   *%eax   0x08048625 <+69>:    mov    %eax,0x14 (%ESP)   0x08048629 <+73>:    mov    0x14 (%esp),%eax   0x0804862d <+77>:    add    $0x1,%eax

It is

   0x08048623 <+67>:    call   *%eax

's return value.

So, where does the function pointer stored by EAX come from?

   0x0804860c <+44>:    mov    0x18 (%esp),%eax   0x08048610 <+48>:    mov    (%eax),%eax   0x08048612 <+50>:    mov    (%eax),%eax   0x08048614 <+52>:    mov    0x1c (%esp),%edx   0x08048618 <+56>:    mov    %edx,0x4 (%esp)   0x0804861c <+60>:    mov    0x18 (%ESP),%edx   0x08048620 <+64>:    mov    %edx, (%ESP)   0x08048623 <+67>:    call   *%eax

Apparently, it was eventually taken from the esp+0x18 point, and the

   0x08048600 <+32>:    mov    %ebx, (%ESP)   0x08048603 <+35>:    call   0x8048650 <_ zn21xuzhina_dump_c6_s3_exc2ev>   0x08048608 <+40>:    mov    %ebx,0x18 (%ESP)

The esp+0x18 holds the this pointer to the XUZHINA_DUMP_C6_S3_EX (Shell c++filt _zn21xuzhina_dump_c6_s3_exc2ev) object.

So

   0x0804860c <+44>:    mov    0x18 (%esp),%eax   0x08048610 <+48>:    mov    (%eax),%eax   0x08048612 <+50>:    mov    (%eax),%eax

Is the operation of removing the virtual function from the this pointer. Take a look at the virtual function table for class XUZHINA_DUMP_C6_S3_EX:

(GDB) x $esp +0x180xbfc0fee8:     0x08c07008 (GDB) x/x 0x08c070080x8c07008:      0x08049958 (GDB) x/4x 0x080499580x8049958 <_ztv21xuzhina_dump_c6_s3_ex+8>:      0xb77b16c8      0x00000000      0x00000000      0x00000000 (GDB) info symbol 0XB77B16C8XUZHINA_DUMP_C6_S3_EX::p arseval (char*) in section. Text of libtestso.so

Very strange. According to the code logic, it should be Xuzhina_dump_c6_s3_ex::encode (char *).

Well, to this point, you can know that the header file where the class XUZHINA_DUMP_C6_S3_EX has been modified, but not recompiled, and the virtual function is added in front of the member virtual function encode. Why not behind it? Interested readers can try this situation.

Already know the new version of the header file has been modified, the rest of the work with the comparison tool, such as diff can be found in the changes.

There is, of course, another way to see how many virtual functions are added.

From the above analysis, you can know that 0x08049958 is the virtual function table address of class XUZHINA_DUMP_C6_S3_EX.

(gdb) x/4x 0x08049958                          0x8049958 <_ztv21xuzhina_dump_c6_s3_ex+8>:      0xb77b16c8      0x00000000      0x00000000      0x00000000

As you can see, it is offset _ztv21xuzhina_dump_c6_s3_ex, while _ZTV21XUZHINA_DUMP_C6_S3_EX is

(gdb) Shell c++filt _ztv21xuzhina_dump_c6_s3_exvtable for XUZHINA_DUMP_C6_S3_EX

So, _ZTV21XUZHINA_DUMP_C6_S3_EX's address is 0x08049950. Take a look at its contents

(gdb) x/4x 0x08049950                         0x8049950 <_ztv21xuzhina_dump_c6_s3_ex>:        0x00000000      0xb77b2808      0xb77b16c8      0x00000000 (gdb) info symbol 0xb77b2808typeinfo for XUZHINA_DUMP_C6_S3_EX in section. Data.rel.ro of Libtestso.so (GDB) info symbol 0XB77B16C8XUZHINA_DUMP_C6_S3_EX::p arseval (char*) in section. Text of libtestso.so

That is, the class XUZHINA_DUMP_C6_S3_EX immediately following the virtual function table. It is interesting to try other classes as well.

So, look at the class xuzhina_dump_c6_s3_ex so file libtestso.so, through the Objdump view.

[[email protected] 3_ex]$ objdump-r libtestso.so libtestso.so:file format elf32-i386dynamic Relocation RECORDSO    Ffset TYPE VALUE 000017e4 r_386_relative *abs*000017e8 r_386_relative *abs*000017f0 r_386_relative *ABS*000017FC r_386_32 _zti21xuzhina_dump_c6_s3_ex00001800 r_386_32 _zn21xuzhina_dump_c6_s3_ex8parseval EPc00001804 r_386_32 _zn21xuzhina_dump_c6_s3_ex6encodeepc00001808 r_386_32 _ztvn10__cxxabiv117__class_ty pe_infoe0000180c r_386_32 _zts21xuzhina_dump_c6_s3_ex00001908 r_386_glob_dat __gmon_start__0000190c R_386_GLOB _dat _jv_registerclasses00001910 r_386_glob_dat _itm_deregistertmclonetable00001914 R_386_GLOB_DAT _ITM_registerT MCloneTable00001918 r_386_glob_dat __cxa_finalize00001928 r_386_jump_slot __gmon_start__0000192c R_386_jump_slot St rstr00001930 R_386_jump_slot __cxa_finalize[[email protected] 3_ex]$ c++filt _zti21xuzhina_dump_c6_s3_ Extypeinfo for xuzhina_dump_c6_s3_ex[[email protected] 3_ex]$ c++filt _zn21xuzhina_dump_c6_s3_ex8parsevalepcxuzhina_dump_c6_s3_ex::p arseval (char* ) [[email protected] 3_ex]$ c++filt _zn21xuzhina_dump_c6_s3_ex6encodeepcxuzhina_dump_c6_s3_ex::encode (char*)

You can see that the class XUZHINA_DUMP_C6_S3_EX has two virtual functions Parseval and encode,parseval in front of encode. That is, only a virtual function is added in front of the encode. If you add more, you can count the number of orders from here.

A coredump example of the virtual function of Linux x86 version 6.5, "Coredump Problem principle Inquiry"