use gdb to know where the segmentation fault accurre

mary1001 · 01-27-2015, 12:11 AM

hi
i use this structure to get the source of my problem in ns2...

Quote:

It is some times simpler if you can locate the root cause of the
segmentation fault.
To do this, make the following changes to the Makefile in the
*/ns*-allinone/ns*/ folder.

1. locate the compiler command it will either be "cc" or "gcc". change
it to "cc -g" or "gcc -g". This will make the compiler generated flags
for gdb
2. Then type
>make clean
>make
this will re compile ns
3. then run ns using gdb using the command below
>gdb ns
>[inside gdb]r your-tcl-file.tcl
4. Then, when you get a seg fault, it will show you the line number
and file name which caused the Seg Fault. This will give you lot of
info to debug your code.

now i run a tcl file in gdb and i get this output in gdb that get me the source of seg fault...but i dont know what is this and what the problem is...
("bt" give me backtrace)

Quote:

(gdb) r sm4.tcl

Starting program: /usr/local/bin/ns sm4.tcl
num_nodes is set 3
INITIALIZE THE LIST xListHead
Starting Simulation…

Program received signal SIGSEGV, Segmentation fault.
0xb7d0afef in vfprintf () from /lib/i386-linux-gnu/libc.so.6

(gdb) bt

#0 0xb7d0afef in vfprintf () from /lib/i386-linux-gnu/libc.so.6
#1 0xb7d29962 in vsprintf () from /lib/i386-linux-gnu/libc.so.6
#2 0xb7d1031f in sprintf () from /lib/i386-linux-gnu/libc.so.6
#3 0x082d330e in CMUTrace::format_rtaodv (this=0x8921fb8, p=0x89cfb00,
offset=76) at trace/cmu-trace.cc:967
#4 0x082d5786 in CMUTrace::format (this=0x8921fb8, p=0x89cfb00,
why=0x8515dbe “—“) at trace/cmu-trace.cc:1550
#5 0x082d59f9 in CMUTrace::recv (this=0x8921fb8, p=0x89cfb00, h=0x0)
at trace/cmu-trace.cc:1646
#6 0x081e2f87 in NsObject::handle (this=0x8921fb8, e=0x89cfb00)
at common/object.cc:93
#7 0x081e0257 in Scheduler::dispatch (this=0x88ce018, p=0x89cfb00, t=0)
at common/scheduler.cc:150
#8 0x081e0190 in Scheduler::run (this=0x88ce018) at common/scheduler.cc:129
#9 0x081e0339 in Scheduler::command (this=0x88ce018, argc=2, argv=0xbfffe320)
at common/scheduler.cc:198
#10 0x084050f9 in OTclDispatch (cd=0x88cf668, in=0x86e4d10, argc=3,
argv=0x86e58e0) at otcl.c:455
#11 0x0840b711 in TclInvokeStringCommand ()
#12 0x08410236 in TclEvalObjvInternal ()
#13 0x0845910b in TclExecuteByteCode ()
#14 0x08460bec in TclCompEvalObj ()
#15 0x08459026 in TclExecuteByteCode ()
#16 0x0849d02d in TclObjInterpProcCore ()
#17 0x0849d390 in TclObjInterpProc ()
#18 0x0840b853 in TclInvokeObjectCommand ()
#19 0x08405211 in OTclDispatch (cd=0x88cf668, in=0x86e4d10, argc=2,
argv=0x86e57d8) at otcl.c:498
#20 0x0840b711 in TclInvokeStringCommand ()
#21 0x08410236 in TclEvalObjvInternal ()
#22 0x0845910b in TclExecuteByteCode ()
#23 0x0849d02d in TclObjInterpProcCore ()
#24 0x0849d390 in TclObjInterpProc ()
#25 0x0840b853 in TclInvokeObjectCommand ()
#26 0x084050f9 in OTclDispatch (cd=0x88c7548, in=0x86e4d10, argc=2,
argv=0x86e56c8) at otcl.c:455
#27 0x0840b711 in TclInvokeStringCommand ()
#28 0x08410236 in TclEvalObjvInternal ()
#29 0x08411fc9 in TclEvalEx ()
#30 0x0841254b in Tcl_EvalEx ()
#31 0x0847cf91 in Tcl_FSEvalFileEx ()
#32 0x08483140 in Tcl_Main ()
#33 0x08400ff2 in nslibmain (argc=2, argv=0xbffff254)
at common/tclAppInit.cc:67
#34 0x0840114b in main (argc=2, argv=0xbffff254)
at common/main-monolithic.cc:46

can anybody help me?!!plzzz

rtmistler · 01-28-2015, 09:01 AM

I'd look in trace/cmu-trace.cc at line #967, providing that is your code. If not, say that's common library which goes beyoind your purview, then find a place in the stack where it is part of your code and see if there are any NULL pointers. Because sprintf() and the variety of follow on functions are likely complaining about an out of bounds address. And not necessarily 0x0000000, but maybe something uninitialized and bad enough of a random number that the system recognizes that it's not a valid memory address, for instance 0xffffffff, or even 0xf00abcdef; like the system may know that addresses above a certain memory location are out of bounds too.

And when within GDB you can issue up and down to go up and down that call stack and then 'p' for print to print out variables. For instance "this" is a variable, likely a pointer, likely a structure, so you can print out that structure "p this", or "p *this", or "p &this", and it would appear that the first or second options would work best for you in this situation.

You either know some of those variables or you don't.

Granted there's nothing saying there isn't a problem within a library function; however you first should proceed to debug your code. So wherever the last point that it left your code, is where you ought to look. Just because the SEGV is way up somewhere else, if all you have is main-monolithic.cc and the rest are all library calls, then look at that lone and the state of the variables at that point.

Type "help" when at the gdb prompt to get some assistance, or perform a web search for general gdb commands.