I've recently started programming in DEV C++ and I've come across an issue that searching the Googleshere for has yet to prove helpful.
In the following code, GDB "hangs" when it hits line 5, std::cout << "Hello" << std::endl;.
#include <iostream>
int main()
{
int tree = 9;
std::cout << "Hello" << std::endl;
tree = 10;
return 0;
}
The program compiles and runs just fine, but when stepping through it always gets stuck here and neither "Next line" or "Continue" seem to work.
Here's some output from the GDB window:
Starting program: C:\XXX\XXX\XXX\XXX\breakGDB.exe
[New Thread 7300.0x2028]
->->new-thread
[New Thread 7300.0x2638]
->->new-thread
->->starting
->->breakpoints-invalid
->->frames-invalid
->->breakpoint 1
Breakpoint 1,
->->frame-begin 0 0x40153d
->->frame-function-name
main
->->frame-args
()
->->frame-source-begin
at
->->frame-source-file
hello.cpp
->->frame-source-file-end
:
->->frame-source-line
5
->->frame-source-end
->->source C:\XXX\XXX\XXX\XXX\hello.cpp:5:38:beg:0x40153d
->->frame-end
->->stopped
->->pre-prompt
(gdb)
->->prompt
->->post-prompt
->->frames-invalid
->->starting
->->frame-begin 0 0x44d2f0
->->frame-address
0x000000000044d2f0
->->frame-address-end
in
->->frame-function-name
std::ostream::operator<<(std::ostream& (*)(std::ostream&))
->->frame-args
()
->->frame-end
->->stopped
->->pre-prompt
(gdb)
->->prompt
->->post-prompt
Single stepping until exit from function _ZNSolsEPFRSoS_E,
which has no line number information.
->->frames-invalid
->->starting
->->frame-begin 0 0x46cf10
->->frame-address
0x000000000046cf10
->->frame-address-end
in
->->frame-function-name
std::basic_ostream<char, std::char_traits<char> >& std::endl<char, std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&)
->->frame-args
()
->->frame-end
->->stopped
->->pre-prompt
(gdb)
->->prompt
I'm quite new to GDB. Is this a feature of GDB? Have I got a setting wrong? What's going on here?
I've got my fingers crossed it's not some foolish error on my part.
I had the same problem and "solved" it by switching the compiler set from 64-bit Debug to 32-bit Debug.
Still need a solution for 64-bit.
// Dev-Cpp 5.11 TDM-GCC x64 4.9.2 Portable
Related
I've been trying to debug a little thingie, and almost went insane while trying to do so. After several hours of figuring out the problem, I finally have a snippet of code that is the root of my problem:
#include <iostream>
#include <vector>
#include <stack>
using namespace std;
int main()
{
std::vector<int> foo = std::vector<int>();
foo.push_back(0);
foo.push_back(11);
foo.push_back(222);
foo.push_back(3333);
std::stack<int> bar = std::stack<int>();
cout << endl << foo.size() << endl << endl;
return 0;
}
With this compiled, using:
g++ -std=c++11 -ggdb -O0 -pedantic -Wall -Wextra -Wno-nonnull -fkeep-inline-functions
I then try the following:
(gdb) br 18
Breakpoint 1 at 0x40170c: file ./....cpp, line 18.
(gdb) r
Starting program: ...
[New Thread 15620.0x3c3c]
Breakpoint 1, main () at ./....cpp:18
18 cout << endl << foo.size() << endl << endl;
(gdb) p foo.size()
$1 = 4293588256
(gdb) c
Continuing.
4
[Inferior 1 (process 15620) exited normally]
(gdb)
Apparenly, 4 is now equal to 4293588256. What the bloody hell is going on?
Also, if I break the program before the stack is created, GDB shows the size properly.
EDIT:
I am on windows 8.1, versions of stuffs are: G++ 4.8.1; GDB 7.6.1
Turns out this really is a problem of either GDB 7.6.1 or G++ 4.8.1.
Updating GDB to 7.8.1 and G++ to version 4.9.2 solved the problem.
Program in C/C++ runs on embedded PowerPC under debugger with HW break points capabilities.
There is global variable 'char Name[256]' known in 2 files and 2 tasks correspondingly. One task reads Name, another fills it with a text, '1234567...', for example.
At some moment, global variable Name gets corrupted. When asked for the variable address gdb shows (and application prints by debug printouts) address equal to 0x31323334.
How to catch this bug with HW breakpoints? I mean at what address to put HWBP.
When I look into assembler, I see:
lis 9,Name#ha
lwz 9,Namel#l(9)
So, how memory corruption can change the code without influencing the application flow - it should crash immediately, no?
Thanks a lot ahead
0x31323334 is "1234" sans null terminator. Further, "Global variable address corruption" does not make much sense "global variables" (whose addresses do not change), nor really for an array of size 256 (unless you're using a pointer somewhere and it's the pointer which is being corrupted). So I suspect you might be unfamiliar with GDB.
When using GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1 on x86 (admittedly, not ppc, but basically the same software) with the following test file:
// g++ test.cpp -g
#include <iostream>
char Name[256] = "123456789";
int main() {
Name[0] = 'a';
std::cout << Name << std::endl;
}
I can get the following output from GDB:
(gdb) break main
Breakpoint 2 at 0x40086a: file test.cpp, line 6.
(gdb) r
Starting program: /home/keithb/dev/mytest/a.out
Breakpoint 2, main () at test.cpp:6
6 Name[0] = 'a';
(gdb) whatis Name
type = char [256]
(gdb) print Name
$1 = "123456789", '\000' <repeats 246 times>
(gdb) print &Name
$2 = (char (*)[256]) 0x6010c0 <Name>
In any case, if you really do want to set a "hardware breakpoint" (GDB calls those "watchpoints"), then you can do get the address of Name prior to corruption. Then just set the watchpoint and wait for your program to write to the address.
(gdb) c
Continuing.
a23456789
[Inferior 1 (process 21878) exited normally]
(gdb) delete 2
(gdb) watch *0x6010c0
Hardware watchpoint 3: *0x6010c0
(gdb) r
Starting program: /home/keithb/dev/mytest/a.out
Hardware watchpoint 3: *0x6010c0
Old value = 875770417
New value = 875770465
main () at test.cpp:7
7 std::cout << Name << std::endl;
(gdb)
int main()
{
typedef unsigned char a4[4];
a4 p1;
a4& p2 = p1;
p2[1]=1;
cout<<sizeof(p2);
return p2[1];
}
Compile, start gdb and put breakpoint on return. If you type p sizeof(p2), gdb will print 8 instead of 4 which will be printed if you start the program. If you write in gdb p sizeof(*p2), the output is 4 (the size of array). I think this is because gdb treats p2 as pointer(reference is implemented behind the scene as pointer).
Tested with compilers GCC 4.8.2 and Clang 4.3 on GDB 7.7 linux arch., ubuntu 13.10,
Is this correct or a bug in gdb?
Here's a modified version of your program. I've changed the array size from 4 to 17 to ensure that its size is distinguishable from anything else. I've also changed the type and variable names to make the code easier to follow, and added #include <iostream> so it actually compiles. I've also removed some unnecessary stuff.
#include <iostream>
int main()
{
typedef unsigned char char17[17];
char17 arr17;
char17& arr17_ref = arr17;
std::cout << "sizeof(arr17) = "
<< sizeof arr17
<< ", sizeof(arr17_ref) = "
<< sizeof(arr17_ref)
<< "\n";
return 0;
}
When I compile and run it on my system, the output is 17.
When I run it under gdb, I get 8 (the size of a pointer on my system):
$ gdb ./c
GNU gdb (GDB) 7.5-ubuntu
[snip]
Reading symbols from /home/kst/c...done.
(gdb) b 12
Breakpoint 1 at 0x40097e: file c.cpp, line 12.
(gdb) r
Starting program: /home/kst/c
sizeof(arr17) = 17, sizeof(arr17_ref) = 17
Breakpoint 1, main () at c.cpp:12
12 return 0;
(gdb) p sizeof(arr17)
$1 = 17
(gdb) p sizeof(arr17_ref)
$2 = 8
(gdb) c
Continuing.
[Inferior 1 (process 23420) exited normally]
(gdb) q
$
Yes, this is a bug in gdb. gdb is supposed to evaluate expressions as they'd be evaluated in a running program; in this case, it fails to do so.
(I'm using gcc 4.7.2 and gdb 7.5 on Linux Mint 14.)
UPDATE :
The OP submitted a bug report: https://sourceware.org/bugzilla/show_bug.cgi?id=16675
and it's been fixed. The patch was approved and committed 2014-04-14. I still see the bug in gdb 7.7.1, but it's fixed in 7.11.1.
I am new to program world. I am learning C with Dev-cpp 5.6.1
I had a problem with my Debugger (GNU gdb (GDB) 7.6.1). When I debug any program, the debugger warned me
Single stepping until exit from function main,
which has no line number information.
and
__mingw_CRTStartup ()
at ../mingwrt-4.0.3-1-mingw32-src/src/libcrt/crt/crt1.c:260
260 ../mingwrt-4.0.3-1-mingw32-src/src/libcrt/crt/crt1.c: No such file or directory.
The problem happened before. I solved it by reinstalling Dev-Cpp (also reset old configure). But after a little time the problem came back again.
Example code:
#include <stdio.h>
int main(void)
{
int a, b;
printf("Please give me number 1: ");
scanf("%d", &a);
printf("Please give me number 2: ");
scanf("%d", &b);
printf("Sum = %d", a + b);
}
The debugger warned me:
C:\Users\Nam\Dropbox\code>gdb sum.exe
GNU gdb (GDB) 7.6.1
Copyright (C) 2013 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 "mingw32".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from C:\Users\Nam\Dropbox\code\sum.exe...done.
(gdb) b main
Breakpoint 1 at 0x4016b3
(gdb) n
The program is not being run.
(gdb) r
Starting program: C:\Users\Nam\Dropbox\code/sum.exe
[New Thread 7148.0x1b6c]
Breakpoint 1, 0x004016b3 in main ()
(gdb) n
Single stepping until exit from function main,
which has no line number information.
Please give me number 1: 3
Please give me number 2: 4
Sum = 7__mingw_CRTStartup ()
at ../mingwrt-4.0.3-1-mingw32-src/src/libcrt/crt/crt1.c:260
260 ../mingwrt-4.0.3-1-mingw32-src/src/libcrt/crt/crt1.c: No such file or di
rectory.
(gdb)
I couldn't know how to fix it.
Anyone helps me please :(. Thanks in advance
I couldn't know how to fix it.
I don't think it is necessary to fix it. You got this message since you had already returned from main() and now you are not in your code, it is mingw code that calls your main(). I did the same test as you and this is backtrace after finishing main:
10 printf("Sum = %d", a + b);
(gdb)
Sum = 311 }
(gdb) bt
#0 main () at t.c:11
(gdb) n
__mingw_CRTStartup () at ../mingw/crt1.c:250
250 ../mingw/crt1.c: No such file or directory.
(gdb) bt
#0 __mingw_CRTStartup () at ../mingw/crt1.c:250
#1 0x00401284 in mainCRTStartup () at ../mingw/crt1.c:264
(gdb) n
252 in ../mingw/crt1.c
(gdb) n
[Inferior 1 (process 1448) exited normally]
(gdb)
Again - you don't have to debug mingw startup code. Just give gdb command "continue" so that it can finish executing your process.
I have found source of this __mingw_CRTStartup here http://gitorious.org/mingw/mingw-runtime/source/be97f73714b4e267e5903fc9bdeb0f23fcc3ac8f:crt1.c#L200. You can take a look at what steps mingw library does after returning from main:
static void __attribute__((noreturn))
__mingw_CRTStartup (void)
{
int nRet;
/* skipped some lines ... */
nRet = main (_argc, _argv, environ);
/*
* Perform exit processing for the C library. This means
* flushing output and calling 'atexit' registered functions.
*/
_cexit ();
ExitProcess (nRet);
}
Some useful links:
1) https://stackoverflow.com/a/4988376/184968
I really like to use some simple interface like in Borland C++, thereby I've installed cygwin with gcc/gdb/vim etc on my laptop(unfortunately, I can not install Linux here :( )
The problem that I have is following: when I try to debug non-parallized program, f.e:
#include <stdio.h>
#include <stdlib.h>
int main(int argc, char **argv) {
int i = argc;
fprintf(stdout, "Hello World %d\n", i);
return 0;
}
my gdb hangs:
$ gdb a.exe
GNU gdb (GDB) 7.3.50.20111026-cvs (cygwin-special)
...
Reading symbols from /cygdrive/c/programming/temp/a.exe...done.
(gdb) b main
Breakpoint 1 at 0x401179: file helloworld.cpp, line 4.
(gdb) r
Starting program: /cygdrive/c/programming/temp/a.exe
**[New Thread 12132.0x11a4]
[New Thread 12132.0x32ac]**
Breakpoint 1, main (argc=1, argv=0x28ac60) at helloworld.cpp:4
4 int main(int argc, char **argv) {
(gdb) n
5 int i = argc;
(gdb)
6 fprintf(stdout, "Hello World %d\n", i);
(gdb) p i
$1 = 1
(gdb) n
.......... nothing here
I cannot terminate this debugging by C-C, C-Z or killing.
I think gdb hangs, because it tries to use 2 threads and something goes wrong. Here is info threads:
(gdb) info threads
Id Target Id Frame
2 Thread 10160.0x31e8 0x775cf8e5 in ntdll!RtlUpdateClonedSRWLock () from /cygdrive/c/Windows/system32/ntdll.dll
* 1 Thread 10160.0x15a8 main (argc=1, argv=0x28ac60) at helloworld.cpp:4
For me, that's pretty strange, that 1-thread program is executed on 2 threads. I've checked gdb on Linux and gdb there uses 1 thread.
My question is: can I say to gdb to use only 1 thread anyhow?
BTW, I didn't have same problem before until I've updated my laptop and cygwin. I tried to rollback gdb(7.3.50 actually is the oldest one that cygwin suggests), but it doesn't help.
Thank you