CODEWITHSUNDEEP
c++gdb
kagali-san
kagali-san

Reputation: 3072

gdb detected a segmentation fault. How to pinpoint the exact source?

(gdb) s
Things:action (this=0x7fffffffdce0, packet=0x62c980) at file:41
41              if( thing->work(data) ) {
(gdb) s
Program received signal SIGSEGV, Segmentation fault.
0x00000000004040e1 in Things:action (this=0x7fffffffdce0, packet=0x62c980) at file:41
41              if( thing->work(data) ) {

In a backtrace, call to work(data) is a last one; and the segmentation happened (as it seems) before the GDB-managed process entered work(data). In a list, there is no declaration of work(data), so guessing that more code was executed, than is shown by backtrace and latest step.

  1. Can that segfault come from the bad pointer being passed as a function argument in a bad manner (without "extern C", or some other preparations)? (assuming no function code was executed)
  2. How to get a detailed trace to determine, was any work() code executed after entering the function, or the error happened right at the moment, when process tried to enter the function, thereby passing it's arguments to libc?

Upvotes: 2

Views: 798

Answers (2)

SamB
SamB

Reputation: 9224

Well, work() can't have been started unless it's inline, or you it would have been on the top of the backtrace...

I would try disassembling to see what instruction triggered the SIGSEGV and go from there.

Upvotes: 1

icecrime
icecrime

Reputation: 76745

As I said in the comment : I believe that the execution never reached work(data) because the this pointer is invalid (0x7fffffffdce0 looks like garbage). The SIGSEGV is on this->.

Has the object been destroyed / deleted at some point, and have you kept a reference or pointer to it ?

Upvotes: 1

Related Questions