gdb breakpoint problem

gdb breakpoint problem

[kdsfinger]

hi, all
I am new to gdb and have trouble in setting the breakpoint. The
problem is, the program does not stop at some of the breakpoints. I am
using gdb6.6 in centos4.4. Here is the detail.

===================================
/* sample.c -- Sample C program to be debugged with ddd
*/
#include <stdio.h>
#include <stdlib.h>
static void shell_sort(int a[], int size){
	int i, j;	
	int h = 1;
	do {
		h = h * 3 + 1;
	} while (h <= size);
	do {
		h /= 3;
		for (i = h; i < size; i++){
			int v = a[i];
			for (j = i; j >= h && a[j - h] > v; j -= h)
				a[j] = a[j - h];
			if (i != j)
			a[j] = v;
		}
	} while (h != 1);
}

int main(int argc, char *argv[]){
	int *a;  //line 24
	int i; //line 25
	a = (int *)malloc((argc - 1) * sizeof(int)); // line 26
	for (i = 0; i < argc - 1; i++)
		a[i] = atoi(argv[i + 1]);
	shell_sort(a, argc);
	for (i = 0; i < argc - 1; i++)
		printf("%d ", a[i]);
	printf("\n");
	free(a);
	return 0;
}
========================================
gcc -g -o sample sample.c

 gdb sample
GNU gdb 6.6
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...
Using host libthread_db library "/lib/tls/libthread_db.so.1".
(gdb) break 24
Breakpoint 1 at 0x804850b: file sample.c, line 24.
(gdb) info break 1
Num Type           Disp Enb Address    What
1   breakpoint     keep y   0x0804850b in main at sample.c:24
(gdb) run 2 4 6 3 5 7
Starting program: /home/amdx2/drive2/cpp/testddd/sample 2 4 6 3 5 7

Breakpoint 1, main (argc=7, argv=0xbff515c4) at sample.c:26
26              a = (int *)malloc((argc - 1) * sizeof(int));

-------------------------
As you can see, the program did not stop at the breakpoint on line24.
It stops at line26. If I add another breakpoint on line25, this 2nd
breakpoint is skipped as well and the program stops at line26. Why is
that? How can I correct it?

On my own program which is rather big, it got the same problem. When I
use info break xxx, it sometimes point to a different place in "What".
For example, I placed the breakpoint in main line 100, but the "what"
points to other functions in different line. As the result, these
breakpoints never work. I changed my gcc flags with combinations of
-glevel -olevel, the problem did not solve. Thanks for your comments.

zl2k

Re: gdb breakpoint problem

[Daniel Jacobowitz]

On Mon, Jun 11, 2007 at 12:59:57PM -0400, kdsfinger@gmail.com wrote:
> 	int *a;  //line 24
> 	int i; //line 25
> 	a = (int *)malloc((argc - 1) * sizeof(int)); // line 26

> As you can see, the program did not stop at the breakpoint on line24.
> It stops at line26. If I add another breakpoint on line25, this 2nd
> breakpoint is skipped as well and the program stops at line26. Why is
> that? How can I correct it?

A variable declaration does not require any machine instructions.  So
the compiler does not emit any, and there is nowhere that the program
can stop.

> On my own program which is rather big, it got the same problem. When I
> use info break xxx, it sometimes point to a different place in "What".
> For example, I placed the breakpoint in main line 100, but the "what"
> points to other functions in different line.

That is probably a bug in GDB, but we would need a test case to be
sure.

-- 
Daniel Jacobowitz
CodeSourcery

Re: gdb breakpoint problem

[Jim Blandy]

kdsfinger@gmail.com writes:
> hi, all
> I am new to gdb and have trouble in setting the breakpoint. The
> problem is, the program does not stop at some of the breakpoints. I am
> using gdb6.6 in centos4.4. Here is the detail.
>
> ===================================
> /* sample.c -- Sample C program to be debugged with ddd
> */
> #include <stdio.h>
> #include <stdlib.h>
> static void shell_sort(int a[], int size){
> 	int i, j;	
> 	int h = 1;
> 	do {
> 		h = h * 3 + 1;
> 	} while (h <= size);
> 	do {
> 		h /= 3;
> 		for (i = h; i < size; i++){
> 			int v = a[i];
> 			for (j = i; j >= h && a[j - h] > v; j -= h)
> 				a[j] = a[j - h];
> 			if (i != j)
> 			a[j] = v;
> 		}
> 	} while (h != 1);
> }
>
> int main(int argc, char *argv[]){
> 	int *a;  //line 24
> 	int i; //line 25
> 	a = (int *)malloc((argc - 1) * sizeof(int)); // line 26
> 	for (i = 0; i < argc - 1; i++)
> 		a[i] = atoi(argv[i + 1]);
> 	shell_sort(a, argc);
> 	for (i = 0; i < argc - 1; i++)
> 		printf("%d ", a[i]);
> 	printf("\n");
> 	free(a);
> 	return 0;
> }
> ========================================
> gcc -g -o sample sample.c
>
> gdb sample
> GNU gdb 6.6
> Copyright (C) 2006 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "i686-pc-linux-gnu"...
> Using host libthread_db library "/lib/tls/libthread_db.so.1".
> (gdb) break 24
> Breakpoint 1 at 0x804850b: file sample.c, line 24.
> (gdb) info break 1
> Num Type           Disp Enb Address    What
> 1   breakpoint     keep y   0x0804850b in main at sample.c:24
> (gdb) run 2 4 6 3 5 7
> Starting program: /home/amdx2/drive2/cpp/testddd/sample 2 4 6 3 5 7
>
> Breakpoint 1, main (argc=7, argv=0xbff515c4) at sample.c:26
> 26              a = (int *)malloc((argc - 1) * sizeof(int));
>
> -------------------------
> As you can see, the program did not stop at the breakpoint on line24.
> It stops at line26. If I add another breakpoint on line25, this 2nd
> breakpoint is skipped as well and the program stops at line26. Why is
> that? How can I correct it?

First, thanks for providing all the details in your question.  Giving
enough information to allow a reader to reproduce the problem
themselves is the right approach.

What's probably going on is that there is no machine code generated
for lines 24 and 25.  They're just declarations.  The first actual
machine instruction in main is for line 26, so the 'addresses' of lines
24, 25, and 26 are probably all the same.

You can try setting three breakpoints on lines 24, 25, and 26, and
then comparing the addresses printed for each to see if this is the
case.

> On my own program which is rather big, it got the same problem. When I
> use info break xxx, it sometimes point to a different place in "What".
> For example, I placed the breakpoint in main line 100, but the "what"
> points to other functions in different line. As the result, these
> breakpoints never work. I changed my gcc flags with combinations of
> -glevel -olevel, the problem did not solve. Thanks for your comments.

Have you tried compiling with no optimization at all (-O0)?  When
optimization is enabled, the compiler may inline functions, rearrange
code, or remove it altogether.  The debugging information often
doesn't adequately describe these rearrangements, and the debugger
gets confused.

If you have compiled your program with -O0, and setting a breakpoint
in main still results in the breakpoint's location being reported in
some other function, that sounds like a bug.  For us to help you,
you'll need to provide enough information for us to make the problem
happen on our own machines.

Re: gdb breakpoint problem

[Eli Zaretskii]

> Cc: gdb@sourceware.org
> From: Jim Blandy <jimb@codesourcery.com>
> Date: Mon, 11 Jun 2007 10:36:04 -0700
> 
> What's probably going on is that there is no machine code generated
> for lines 24 and 25.  They're just declarations.  The first actual
> machine instruction in main is for line 26, so the 'addresses' of lines
> 24, 25, and 26 are probably all the same.
> 
> You can try setting three breakpoints on lines 24, 25, and 26, and
> then comparing the addresses printed for each to see if this is the
> case.

Or just use the "info line" command to tell you directly what
addresses does each line compile to.

Re: gdb breakpoint problem

[kdsfinger]

On 6/11/07, Jim Blandy <jimb@codesourcery.com> wrote:
>
> kdsfinger@gmail.com writes:
> > hi, all
> > I am new to gdb and have trouble in setting the breakpoint. The
> > problem is, the program does not stop at some of the breakpoints. I am
> > using gdb6.6 in centos4.4. Here is the detail.
> >
> > ===================================
> > /* sample.c -- Sample C program to be debugged with ddd
> > */
> > #include <stdio.h>
> > #include <stdlib.h>
> > static void shell_sort(int a[], int size){
> >       int i, j;
> >       int h = 1;
> >       do {
> >               h = h * 3 + 1;
> >       } while (h <= size);
> >       do {
> >               h /= 3;
> >               for (i = h; i < size; i++){
> >                       int v = a[i];
> >                       for (j = i; j >= h && a[j - h] > v; j -= h)
> >                               a[j] = a[j - h];
> >                       if (i != j)
> >                       a[j] = v;
> >               }
> >       } while (h != 1);
> > }
> >
> > int main(int argc, char *argv[]){
> >       int *a;  //line 24
> >       int i; //line 25
> >       a = (int *)malloc((argc - 1) * sizeof(int)); // line 26
> >       for (i = 0; i < argc - 1; i++)
> >               a[i] = atoi(argv[i + 1]);
> >       shell_sort(a, argc);
> >       for (i = 0; i < argc - 1; i++)
> >               printf("%d ", a[i]);
> >       printf("\n");
> >       free(a);
> >       return 0;
> > }
> > ========================================
> > gcc -g -o sample sample.c
> >
> > gdb sample
> > GNU gdb 6.6
> > Copyright (C) 2006 Free Software Foundation, Inc.
> > GDB is free software, covered by the GNU General Public License, and you are
> > welcome to change it and/or distribute copies of it under certain conditions.
> > Type "show copying" to see the conditions.
> > There is absolutely no warranty for GDB.  Type "show warranty" for details.
> > This GDB was configured as "i686-pc-linux-gnu"...
> > Using host libthread_db library "/lib/tls/libthread_db.so.1".
> > (gdb) break 24
> > Breakpoint 1 at 0x804850b: file sample.c, line 24.
> > (gdb) info break 1
> > Num Type           Disp Enb Address    What
> > 1   breakpoint     keep y   0x0804850b in main at sample.c:24
> > (gdb) run 2 4 6 3 5 7
> > Starting program: /home/amdx2/drive2/cpp/testddd/sample 2 4 6 3 5 7
> >
> > Breakpoint 1, main (argc=7, argv=0xbff515c4) at sample.c:26
> > 26              a = (int *)malloc((argc - 1) * sizeof(int));
> >
> > -------------------------
> > As you can see, the program did not stop at the breakpoint on line24.
> > It stops at line26. If I add another breakpoint on line25, this 2nd
> > breakpoint is skipped as well and the program stops at line26. Why is
> > that? How can I correct it?
>
> First, thanks for providing all the details in your question.  Giving
> enough information to allow a reader to reproduce the problem
> themselves is the right approach.
>
> What's probably going on is that there is no machine code generated
> for lines 24 and 25.  They're just declarations.  The first actual
> machine instruction in main is for line 26, so the 'addresses' of lines
> 24, 25, and 26 are probably all the same.
>
> You can try setting three breakpoints on lines 24, 25, and 26, and
> then comparing the addresses printed for each to see if this is the
> case.
>
> > On my own program which is rather big, it got the same problem. When I
> > use info break xxx, it sometimes point to a different place in "What".
> > For example, I placed the breakpoint in main line 100, but the "what"
> > points to other functions in different line. As the result, these
> > breakpoints never work. I changed my gcc flags with combinations of
> > -glevel -olevel, the problem did not solve. Thanks for your comments.
>
> Have you tried compiling with no optimization at all (-O0)?  When
> optimization is enabled, the compiler may inline functions, rearrange
> code, or remove it altogether.  The debugging information often
> doesn't adequately describe these rearrangements, and the debugger
> gets confused.
>
> If you have compiled your program with -O0, and setting a breakpoint
> in main still results in the breakpoint's location being reported in
> some other function, that sounds like a bug.  For us to help you,
> you'll need to provide enough information for us to make the problem
> happen on our own machines.
>

Thank you all for your prompt reply. But I am still confused. Here is
another toy to demonstrate my problem.

==============================
/* Test.cpp -- Test C++ program to be debugged with ddd
*/
#include <stdio.h>
#include <stdlib.h>
#include <string>
#include <iostream>

class Test{
	public:
		Test();
	private:
		void donothing();
};

void Test::donothing(){
	std::string s = "abc"; // line 16
	s = s+s; // line 17
	std::cout<<s<<std::endl; // line 18
}

Test::Test(){
	std::string s="abc"; // line 22
	s = s+s; // line 23
	std::cout<<s<<std::endl; // line 24
	donothing();
}

int main(int argc, char *argv[]){
	Test test;
	return 0;
}
=============================
 c++ -g -O0 Test.cpp -o test

The breakpoints set at line 22, 23, 24 are all ignored. However, the
breakpoints set at line 16, 17, 18 are all good to break the program.
What's the difference? They are doing the same thing. Why gdb treated
them differently? Thanks for your comments.

zl2k

Re: gdb breakpoint problem

[Daniel Jacobowitz]

On Mon, Jun 11, 2007 at 11:33:15PM -0400, kdsfinger@gmail.com wrote:
> The breakpoints set at line 22, 23, 24 are all ignored. However, the
> breakpoints set at line 16, 17, 18 are all good to break the program.
> What's the difference? They are doing the same thing. Why gdb treated
> them differently? Thanks for your comments.

That's a known bug in GDB - it has trouble with the way GCC generates
constructors for C++ classes.

-- 
Daniel Jacobowitz
CodeSourcery

RE: gdb breakpoint problem

[Dave Korn]

On 12 June 2007 12:20, Daniel Jacobowitz wrote:

> On Mon, Jun 11, 2007 at 11:33:15PM -0400, kdsfinger@gmail.com wrote:
>> The breakpoints set at line 22, 23, 24 are all ignored. However, the
>> breakpoints set at line 16, 17, 18 are all good to break the program.
>> What's the difference? They are doing the same thing. Why gdb treated
>> them differently? Thanks for your comments.
> 
> That's a known bug in GDB - it has trouble with the way GCC generates
> constructors for C++ classes.

  Specifically, it's down to the fact that GCC emits two constructor functions
which are called in different circumstances, but they both have the same name
and function signature (when unmangled - there is a difference in the mangled
names) so GDB is unable to distinguish them.

  NB that you can work around this; here's your testcase again:

/tmp/dosfs $ cat test.cpp
/* Test.cpp -- Test C++ program to be debugged with ddd */
#include <stdio.h>
#include <stdlib.h>
#include <string>
#include <iostream>

class Test{
        public:
                Test();
        private:
                void donothing();
};

void Test::donothing(){
        std::string s = "abc"; // line 16
        s = s+s; // line 17
        std::cout<<s<<std::endl; // line 18
}

Test::Test(){
        std::string s="abc"; // line 22
        s = s+s; // line 23
        std::cout<<s<<std::endl; // line 24
        donothing();
}

int main(int argc, char *argv[]){
        Test test;
        return 0;
}

/tmp/dosfs $ c++ -g -O0 Test.cpp -o test

  Here we see how there are two constructor functions with different mangled
names but they both unmangle to the same thing:

/tmp/dosfs $ nm ./test.exe | grep Test
004016e6 t __GLOBAL__D__ZN4Test9donothingEv
004016ca t __GLOBAL__I__ZN4Test9donothingEv
00401150 T __ZN4Test9donothingEv
004014a2 T __ZN4TestC1Ev
004012f4 T __ZN4TestC2Ev
/tmp/dosfs $ c++filt
__ZN4TestC1Ev
Test::Test()
__ZN4TestC2Ev
Test::Test()


  You can use the underlying mangled names to set breakpoints (remember to
remove the first leading underscore when trying to use a symbol shown by 'nm'
as the C equivalent in gdb):


/tmp/dosfs $ gdb ./test.exe
GNU gdb 6.5.50.20060523-cvs
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-cygwin"...
(gdb) break _ZN4TestC1Ev
Breakpoint 1 at 0x4014a8: file Test.cpp, line 20.
(gdb) break _ZN4TestC2Ev
Breakpoint 2 at 0x40132c: file Test.cpp, line 21.
(gdb) r
Starting program: /tmp/dosfs/test.exe
Loaded symbols for /win/c/WINDOWS/system32/ntdll.dll
Loaded symbols for /win/c/WINDOWS/system32/kernel32.dll
Loaded symbols for /usr/bin/cygwin1.dll
Loaded symbols for /win/c/WINDOWS/system32/advapi32.dll
Loaded symbols for /win/c/WINDOWS/system32/rpcrt4.dll

Breakpoint 1, Test::Test (this=0x23ccb7) at Test.cpp:21
21              std::string s="abc"; // line 22
(gdb) c
Continuing.
abcabc
abcabc

Program exited normally.
(gdb)



    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....