c++ debugging

[monstar]

Hello,
I'm new in c++ and in linux, I have a program that is giving me error when compiling using the g++ in linux, the command g++ -g -o test test.cpp is working fine, but when running the ./test it is giving error because of the pointers,
I tried to use the debug command gcc but it is not working, and help plz.

thanks all, :)

[Moschops]

The gnu debugger is gdb.

gdb nameOfprogram

and then

run

[monstar]

malloc.c:2453: sYSMALLOc: Assertion `(old_top == (((mbinptr) (((char *) &((av)->bins[((1) - 1) * 2])) - __builtin_offsetof (struct malloc_chunk, fd)))) && old_size == 0) || ((unsigned long) (old_size) >= (unsigned long)((((__builtin_offsetof (struct malloc_chunk, fd_nextsize))+((2 * (sizeof(size_t))) - 1)) & ~((2 * (sizeof(size_t))) - 1))) && ((old_top)->size & 0x1) && ((unsigned long)old_end & pagemask) == 0)' failed.

Program received signal SIGABRT, Aborted.
0x00007ffff72b9285 in raise () from /lib64/libc.so.6
(gdb)
(gdb) n
Single stepping until exit from function raise,
which has no line number information.

Program terminated with signal SIGABRT, Aborted.
The program no longer exists.
(gdb)
when runing i have the following error help plz

[kbw]

You've corrupted the heap, most probably written off the end of an array. If the code is short can you post it please.

[Moschops]

At the point in gdb where you get control again, type bt. This will give you a list of all the lines in all the functions you're in the middle of calling, and you'll see which one in your code is the problem.

It is definitely worth taking five minutes to read a quick explanation on how to use gdb.

[BHX]

Moschops wrote:

It is definitely worth taking five minutes to read a quick explanation on how to use gdb.

Where is a good place for that though? I've avoided using gdb because, just like C++ tutorials, there are tons of gdb tutorials and probably a lot of misinformed ones to sift through. Any recommendations?

[Moschops]

To get started with gdb, short examples are good. Once you know how to run it (gdb nameOfProgram), how to examine and traverse the stack (bt, up, down), see the code you're currently in (list) and how to get the values of variables (print) you're equipped to deal with the most common crashes (i.e. segFaults) and you've bootstrapped yourself to the point that you can learn more yourself.

Here's a sample session:

#include<iostream>
using namespace std;

int main()
{

  int x = 7;
  int *p = 0;

  cout << "x = " << x;
  cout << "The pointer points to the value " << *p;
}

Wrote some code, now I'll build it and run. What I type is in bold.

j@j-desktop:~/badCode$ g++ 227.cpp
j@j-desktop:~/badCode$ ./a.out 
Segmentation fault

Oh no, a segfault. I'll rebuild it with debugging symbols and then run it under the debugger. My thought process is in italic, my typing is in bold.

j@j-desktop:~/badCode$ g++ -g 227.cpp
j@j-desktop:~/badCode$ gdb ./a.out 
GNU gdb (GDB) 7.1-ubuntu
Copyright (C) 2010 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 "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/j/badCode/a.out...done.
(gdb) run
Starting program: /home/j/badCode/a.out 

Program received signal SIGSEGV, Segmentation fault.
0x0000000000400824 in main () at 227.cpp:13
13	  cout << "The pointer points to the value " << *p;
Thoughts: Well, the segFault happens on this line. I'm using a pointer here, p. I'd better check the value of that pointer.
(gdb) print p
$1 = (int *) 0x0
Thoughts:Aha! The pointer has a value of zero - it's a null pointer. Trying to dereference it is causing a segFault. Let's see the nearby code.
(gdb)  list
8	
9	  int x = 7;
10	  int *p = 0;
11	
12	  cout << "x = " << x;
13	  cout << "The pointer points to the value " << *p;
14	}
Thoughts: Ah, I never set the pointer to point at anything. That's easily fixed.
(gdb) quit
A debugging session is active.

	Inferior 1 [process 6779] will be killed.

Quit anyway? (y or n) 

Fix the code:

#include<iostream>

using namespace std;

int main()
{

  int x = 7;
  int *p = 0;
  p = &x;

  cout << "x = " << x;
  cout << "The pointer points to the value " << *p;
}

Now build and run:
j@j-desktop:~/badCode$ g++ 227.cpp
j@j-desktop:~/badCode$ ./a.out

x = 7The pointer points to the value 7

So there we have it. The commands I used were:

gdb ./a.out - Start gdb attached to the program I'm interested in. This does not start the program running.
run - Start program running
print p - Show me the value of the object named p.
list - Show the line that execution has paused at, and surrounding lines of code.
quit - Exit gdb.

I suggest you do something similar yourself to practice a little. SegFaults are wonderfully easy to track down like this. Literally thirty seconds with gdb can identify the exact problem. I've seen people spend hours trying to do it by hand, staring at the code, printlining variables all over the place, just because they didn't want to get into the debugger.

[BHX]

Yeah, just that little slip of not setting the pointer to the address of the variable people would have fought 10 to 20 minutes staring at it not certain. I've done things like that, stare right at the code that is wrong and not see it til hours later.

[monstar]

thank you all for your help :) actually i'm new in programming and in linux too :(
the code is about 36 pages!!!! and i can't print it, but in the code there is a lot of pointers, pointers of pointers, pointers of pointers of....7th pointer in some cases, i think that the problem is in the pointer!! do you agree with me, and if so how to solve it??? thank you for your help
this is my final year project

[Moschops]

how to solve it?

Run the code under a debugger.

[BHX]

monstar wrote:

how to solve it?

Moschops wrote:

Run the code under a debugger.

I would say to do Moschops example above and do like he said about making apps and purposely putting segfaults and such in it then debugging it to get used to using the debugger. Otherwise, if you forget to set the debugging symbols it will just run the program normally and not really be much help. After getting comfortable with using the debugger you should then build your source with the debugger symbols and work from there.

Is it normal to actually have fun using the debugger? :-/

[monstar]

Starting program: /dsk/l1/katerji/totem/a.out
peer 1: abilene
peer 2: geant
Number of pairs of inter-cone flows: 6
a.out: malloc.c:2453: sYSMALLOc: Assertion `(old_top == (((mbinptr) (((char *) &((av)->bins[((1) - 1) * 2])) - __builtin_offsetof (struct malloc_chunk, fd)))) && old_size == 0) || ((unsigned long) (old_size) >= (unsigned long)((((__builtin_offsetof (struct malloc_chunk, fd_nextsize))+((2 * (sizeof(size_t))) - 1)) & ~((2 * (sizeof(size_t))) - 1))) && ((old_top)->size & 0x1) && ((unsigned long)old_end & pagemask) == 0)' failed.

Program received signal SIGABRT, Aborted.
0x00007ffff72b9285 in raise () from /lib64/libc.so.6
Missing separate debuginfos, use: debuginfo-install glibc-2.14.90-24.fc16.7.x86_64 libgcc-4.6.3-2.fc16.x86_64 libstdc++-4.6.3-2.fc16.x86_64
(gdb) n
Single stepping until exit from function raise,
which has no line number information.

Program terminated with signal SIGABRT, Aborted.
The program no longer exists.
this is the program debugging, any help

[Moschops]

Don't type 'n'. Type 'bt'.

Make sure you build with debugging symbols.

[monstar]

#0 0x00007ffff72b9285 in raise () from /lib64/libc.so.6
#1 0x00007ffff72bab9b in abort () from /lib64/libc.so.6
#2 0x00007ffff730037d in __malloc_assert () from /lib64/libc.so.6
#3 0x00007ffff7303c37 in _int_malloc () from /lib64/libc.so.6
#4 0x00007ffff7305595 in malloc () from /lib64/libc.so.6
#5 0x00007ffff7b8e3bd in operator new(unsigned long) ()
from /usr/lib64/libstdc++.so.6
#6 0x00007ffff7b8e4d9 in operator new[](unsigned long) ()
from /usr/lib64/libstdc++.so.6
#7 0x0000000000402994 in main (argc=1, argv=0x7fffffffe7c8) at clubmed.cpp:235


ok i typed bt and this is what i got

[Moschops]

clubmed.cpp:235

The problem is being caused at line 235 of the file clubmed.cpp (which is your code), in the function main.

Looks like you're calling new at that point and it's going very wrong. Often, when you're getting a crash on fiddling with memory, running the program under valgrind (with the command valgrind ./nameOfProgram) will tell you exactly where you're trashing memory.

If you type 'up' 7 times, you will then be able to type 'list' and see that code. You will then be able to type 'print someVariable' to see the values of variables, just as in my original example session above.

Learning to use the debugger will make your life so much easier.

[kbw]

I don't think that's the case. The heap has been corrupted earlier and the symptom is __malloc_assert detecting a problem when operator new[] is called.

[Moschops]

That's what valgrind will find. Or there's Bruce Perens' ElectricFence.