[SOLVED] How to debug ns-2 code for segfault

Bringo · 06-14-2010, 01:57 PM

Code:

$ cat segfault.c
 int main(void)
 {
     char *s = "hello world";
     *s = 'H';
 }

$ gdb segfault                               line# 1
GNU gdb Fedora (6.8-24.fc9)
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...
(gdb) r                                      line# 2
Starting program: /path/to/file/segfault 

Program received signal SIGSEGV, Segmentation fault.
0x080483af in main () at segfault.c:4
warning: Source file is more recent than executable.
4            *s = 'H';
Missing separate debuginfos, use: debuginfo-install glibc.i686
(gdb) bt                                     line# 3
#0  0x080483af in main () at segfault.c:4
(gdb)

So, now we know where exactly the problem occures. I know only these three commands to debug using gdb. But in case of ns-2 code, I don't know how to use gdb.

I changed a routing protocol's C++ code in ns-2 and successfully recompiled ns-2 but when I run any tcl script with that particular protocol, I get 'segmentation fault'. Now I want to trace what part of the code is causing this. I have tried using 'printf's at suspectable places. Is this possible to debug ns-2 code with gdb just like the segfault.c above?
I am useing fedora 9.

Thanks

rweaver · 06-14-2010, 02:32 PM

Compile your program with -g (I think) to get more debug info.

gcc -g segfault.c -o segfault

Is it dumping a core?

johnsfine · 06-14-2010, 02:42 PM

In a number of situations I had problems getting gdb even involved in the correct executable to debug a seg fault. My lack of knowledge of gdb combined with complexity in the normal launch of the program resulted in a problem well beyond my ability.

But there is a work around for that situation:
Use ulimit to enable core dumps.
Run the program normally without involving gdb.
Use gdb to read in the executable and the coredump and give you info about the state of things at the moment of the seg fault.

That may be less powerful than actually stepping through the code up to the fault. But it may be much simpler to accomplish.

Bringo · 06-14-2010, 02:44 PM

I don't want to compile or debug segfault.c program. I only showed segfaul.c as an example of debugging. I want to debug ns-2. Because when I recompiled ns-2 after making certain changes in a protocol's c++ code in ns-2, it was successfully compiled. But a tcl script with that protocol gives segmentation fault. So now I want to know what piece of code in my changes is giving this error.

Thanks

johnsfine · 06-14-2010, 02:49 PM

Did you see my answer above?

Quote:

Originally Posted by Bringo

I don't want to compile or debug segfault.c program. I only showed segfaul.c as an example of debugging.

I understood that and noticed rweaver apparently didn't. But rweaver's advice about compiling with -g is still appropriate.

I made a guess (in my answer above) about what might be your problem with using gdb with ns-2 and I suggested an alternative. But without actually knowing the problem, I can't give you more specific advice.

You don't know how to change the makefile or build scripting for ns-2 to include the -g?

You don't know how to load/launch ns-2 inside gdb? (How do you launch ns-2 when you aren't trying to debug it? Remember some of us never heard of ns-2 before this thread.)

You don't know how to interpret the results?

Or what?

You know how to find the segfault in your own simple example with gdb. What don't you know about doing the same with ns-2?

Bringo · 06-14-2010, 03:23 PM

Thank you very much johnsfine. In fact you made your post # 3 when I was writing a reply to rweaver. Therefore, I could see your post but after making reply to rweaver. I really appreciate your assistance..

- ns-2 is the well-known network simulator with C++ as it's back-end and tcl for front-end scripting. http://en.wikipedia.org/wiki/Ns_(simulator)
- Yes, I don't know how to change the makefile or build scripting for ns-2 to include the -g?
- Yes, I don't know how to load/launch ns-2 inside gdb?
- We launch ns-2 by 'ns' command in terminal and tcl script as an argument. So tcl script (as front-end) uses ns-2's C++ coding (as back-end).

I think now you will have a better idea why I can debug simple segfault.c using gdb but not ns-2.

Thanks

johnsfine · 06-14-2010, 04:07 PM

Quote:

Originally Posted by Bringo

I don't know how to change the makefile or build scripting for ns-2 to include the -g?

Maybe the -g is already there. Maybe you don't really need it. Or maybe you'll need to figure out some environment variable (maybe CFLAGS) that the makefile for ns-2 understands for such things.

Quote:

I don't know how to load/launch ns-2 inside gdb?
- We launch ns-2 by 'ns' command in terminal and tcl script as an argument.

That's easy. So instead of ns use
gdb --args ns
and follow that (as you would follow ns) with the tcl script argument.

Then use the r and bt commands as you did for the simpler example.

Bringo · 06-15-2010, 05:21 AM

O.K. I have examined the makefile and have found the following entries involving CFLAGS:

Code:

...
CFLAGS	+= $(CCOPT) $(DEFINE)
...
.cc.o:
	@rm -f $@
	$(CPP) -c $(CFLAGS) $(INCLUDES) -o $@ $*.cc

.c.o:
	@rm -f $@
	$(CC) -c $(CFLAGS) $(INCLUDES) -o $@ $*.c
...

depend: $(SRC)
	$(MKDEP) -- $(CFLAGS) -- -Y $(SRC) >& /dev/null
...

Now I don't know how and where to add -g. Now I have tried running ns-2 with gdb as follows:

Code:

$ gdb ns
GNU gdb Fedora (6.8-24.fc9)
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...
(gdb) r
Starting program: /usr/local/bin/ns 
% ns dsdv-newtrace.tcl
Detaching after fork from child process 2800.
num_nodes is set 3
INITIALIZE THE LIST xListHead
channel.cc:sendUp - Calc highestAntennaZ_ and distCST_
highestAntennaZ_ = 1.5,  distCST_ = 550.0
SORTING LISTS ...DONE!
child killed: segmentation violation
% exit

Program exited normally.
Missing separate debuginfos, use: debuginfo-install gcc.i386 glibc.i686
(gdb) bt
No stack.
(gdb)

Thanks

Bringo · 06-20-2010, 12:08 PM

Hello again, I am now debugging it in eclipse but still the code culprit of the segfault is not identifiable. I have marked confusions in the screenshots attached. Please help me how can I go forward with debugging. Essentially how can I use the information presented in the screenshots to figure out the problem. In the 2nd screenshot, in Debug window, many methods are listed starting with 30 AirTimeTimer::expire() and ending at 1 main(). What does this hints ?
Note that I still don't know where in the makefile I should add -g flag.

Thanks.

johnsfine · 06-20-2010, 01:56 PM

Quote:

Originally Posted by Bringo

still the code culprit of the segfault is not identifiable.

It seems pretty clear that the segfault is in AirTimeTimer::expire()

Without recompiling with -g, it is hard to figure out where in AirTimeTimer::expire() the bug is. But maybe that is a small enough function that you can deduce the bug looking at the whole source code of that one function. Try posting that one function's source code. I expect I would notice things you might not.

Quote:

many methods are listed starting with 30 AirTimeTimer::expire() and ending at 1 main(). What does this hints ?

That is the call stack:
main() called something. That called something else. And so on down to TimerHandler::handle() calling AirTimeTimer::expire()

Quote:

Note that I still don't know where in the makefile I should add -g flag.

You don't normally add that in the makefile. You confirmed already that your makefile uses CFLAGS in the typical way, so you delete some relevant .o files (or clean the whole project if you prefer) then
export CFLAGS=-g
then rerun the make

Bringo · 06-24-2010, 03:09 PM

Thanks johnsfine.
Here is void AirTimeTimer::expire():

Code:

void AirTimeTimer::expire(Event *e){
  if(a_->hc < 100) {
		if(a_->mac_802_11->tx_state_== MAC_RTS)	// sending state
			a_->my_txtime[a_->hc]++;
		if(a_->mac_802_11->rx_state_== MAC_CTS)	// receiving state
			a_->my_rxtime[a_->hc]++;
		if(a_->mac_802_11->nav_ > Scheduler::instance().clock())	//NAV pending
			a_->my_navtime[a_->hc]++;
    a_->hc++;
}
else {
  a_->hc=0;
 }
 resched(0.01);
}

johnsfine · 06-24-2010, 03:23 PM

Looking at the assembler code of your earlier attachment, next to this C++ code, I can be fairly confident that
a_->mac_802_11
was an invalid pointer (likely null) when AirTimeTimer::expire executed and the seg fault occurred on the attempt to read the value of
a_->mac_802_11->tx_state

That implies a_ itself was a valid pointer and a_->hc was less than 100.

You wouldn't find out much more from GDB even if you had the -g in the right place during the compile.

If this is your own code, you ought to have some idea what a_->mac_802_11 is supposed to be and why it might be an invalid pointer instead.

Bringo · 06-24-2010, 11:18 PM

Thanks johnsfine. You are right. Is the jargon in Disassembly window in my previous attachments the assembly code? Kindly tell us what were the hints in disassembly window that made you conclude this.

Thank you very much johnsfine.

johnsfine · 06-25-2010, 04:59 AM

Quote:

Originally Posted by Bringo

You are right.

Does that mean you figured out why a_->mac_802_11 was an invalid pointer and how to correct the program for that bug?

Quote:

Is the jargon in Disassembly window in my previous attachments the assembly code? Kindly tell us what were the hints in disassembly window that made you conclude this.

Yes, the content of the Disassembly window is the assembler code. Since I know how to program in assembler code, I know what that code does. You showed only a tiny amount of assembler code at and after the instruction that triggered the seg fault. But that happened to fit only one possible seg fault in the C++ source code (mainly because the C++ code was so short and simple).

Bringo · 06-25-2010, 09:08 AM

Quote:

Originally Posted by johnsfine

Does that mean you figured out why a_->mac_802_11 was an invalid pointer and how to correct the program for that bug?

a_->mac_802_11 was an invalid pointer because it was not initialized. The corrective step is simple i.e. initializing mac_802_11 through its constructor.

Quote:

Originally Posted by johnsfine

Since I know how to program in assembler code, I know what that code does.

Oops ! So now to understand debugging, have I to understand assembly code as well ? OMG