CODEWITHSUNDEEP
c++linuxsegmentation-faultgdb
SACHIN GOYAL
SACHIN GOYAL

Reputation: 965

segmentation fault has occurred on a code which was not compiled using debugger flags

one of process on my system has got segmentation fault . From core files , I got the below information .

#0  0x00007f8768c06cfb in TestDummy::work() () from libCont.so
#1  0x00007f8768bfb5ee in Test::work() () from libCont.so
#2  0x00007f8768c5fa7b in Test::worker_threads() () from libCont.so
#3  0x00007f873fffe830 in ?? ()
#4  0x0000000000000000 in ?? ()

Please note I am unable to re create this segmentation fault , all i have is this core file on a system to identify what went wrong . Note: code was not compiled using debugger flag i.e "g++ -g" , so debug information is not available .

What I tried I tried to dissemble and read complete frame 0 to identify the exact crash point but it didn't help .

can anybody let me know a way to debug it further?

Upvotes: 0

Views: 99

Answers (2)

SACHIN GOYAL
SACHIN GOYAL

Reputation: 965

I think there a way by which we can debug the core which is not compiled using debugger flags . I would like to explain it with below example .

(gdb) disassemble 
Dump of assembler code for function mystrcpy:  
 0x0804852a <+0>:   push   %ebp  
 0x0804852b <+1>:   mov    %esp,%ebp  
 0x0804852d <+3>:   sub    $0x10,%esp  
 0x08048530 <+6>:   mov    0x8(%ebp),%eax 
  0x08048533 <+9>:  mov    %eax,-0x4(%ebp)  
 0x08048536 <+12>:  jmp    0x8048540 <mystrcpy+22>
   0x08048538 <+14>:    addl   $0x1,0xc(%ebp)  
 0x0804853c <+18>:  addl   $0x1,0x8(%ebp)
   0x08048540 <+22>:    mov    0xc(%ebp),%eax 
  0x08048543 <+25>: movzbl (%eax),%edx 
  0x08048546 <+28>: mov    0x8(%ebp),%eax
=> 0x08048549 <+31>:    mov    %dl,(%eax)  
 0x0804854b <+33>:  mov    0x8(%ebp),%eax  
 0x0804854e <+36>:  movzbl (%eax),%eax
   0x08048551 <+39>:    test   %al,%al 
  0x08048553 <+41>: jne  
  0x8048538 <mystrcpy+14>  
 0x08048555 <+43>:  mov    -0x4(%ebp),%eax
   0x08048558 <+46>:    leave   
  0x08048559 <+47>: 
ret    End of assembler dump.

Now , line which is actually showing "=>" symbol is the culprit .(=> 0x08048549 <+31>: mov %dl,(%eax) )

We can use gdb commands to figure out what had happened with line which is showing the problem .

  gdb) print $eax //print command
     $1 = 0
    (gdb) print $dl
     $2 = 118
    (gdb) print/c $dl
     $3 = 118 'v‘
    (gdb) info frame //info frame command
    Stack level 0, frame at 0xffbf8b90: eip = 0x8048549 in mystrcpy; saved eip =   0x80485cd called by frame at 0xffbf8bc0 Arglist at 0xffbf8b88, args:  Locals at 0xffbf8b88, Previous frame's sp is 0xffbf8b90 Saved registers:  ebp at 0xffbf8b88, eip at 0xffbf8b8c
    (gdb) x/x $ebp+4 //base pointer + 4 
    0xffbf8b8c: 0x080485cd
    (gdb) info symbol 0x080485cd  //info symbol command 
     connect + 115 in section .text of /home/vmahajan/a.out
     (gdb) x/x $ebp+4 
     0xffbf8b8c:    0x080485cd
    (gdb) x/x $ebp+8 
     0xffbf8b90:    0x00000000
    (gdb) x/x $ebp+12 
     0xffbf8b94:    0xffbf91f3
    (gdb) print/s (char *)0xffbf91f3
     $5 = 0xffbf91f3 "vishal“

Upvotes: 0

Employed Russian
Employed Russian

Reputation: 213879

What I tried I tried to dissemble and read complete frame 0 to identify the exact crash point but it didn't help

You don't need to identify the exact crash point: GDB has already told you what it is: it's the instruction at address 0x7f8768c06cfb.

What you are probably saying is "despite looking at disassembly, I still can't understand which source line caused the problem". We could help you with that, but only if you actually show the source and the disassembly in your question.

Your only other choices are:

  1. Find a local guru who you can show the source and the disassembly, and who will help you the same way we would, or
  2. Do what Lightness Races in Orbit told you to do: rebuild your binary with exactly the same flags, but add -g as well. Assuming you have a hermetic build and can rebuild your original binary in a close enough state (output from nm new-binary should match output from nm old-binary), GDB will then tell you exactly what line the address 0x7f8768c06cfb corresponds to.

Note: you don't actually have to rebuild the entire binary with -g. Rebuilding just the source containing TestDummy::work() and re-linking libCont.so should be enough.

Upvotes: 1

Related Questions