I am new to gdb and am using gdb to debug a project written by others. In this piece:
int CObjectRecognizer::String2StructInput(const StructInstanceInput &input, StructAlgoResult &aResult, SObjectRecInput &inputInfo)
{
try
{
map<string,string> inputmap = input.field;
if(inputmap.find("att") != inputmap.end())
{
inputInfo.m_att = atoi(inputmap["att"].c_str());
}
}
In gdb, I want to check the value of inputmap, but it gives an error message:
(gdb) next
899 map<string,string> inputmap = input.field;
(gdb) print inputmap
$1 = std::map with 140737488343904 elements<error reading variable: Cannot access memory at address 0x48e7458d48c38958>
(gdb)
Why can't it access memory at the particular address 0x48e7458d48c38958?
EDIT: following suggestion:
(gdb) print inputmap
$2 = std::map with 0 elements
It seems the map is empty. Why doesn't this line create a map?:
map<string,string> inputmap = input.field;
When a GDB line or function entry breakpoint is hit, or when you use the step or next commands, the target program is stopped at the beginning of the first statement of a line, before any code in that line has been executed.
This behavior is usually exactly what you want, for example if your program has a line a[i+j] = b[i] + c[j]; and you want to check for an array out-of-bounds access before it happens.
In your case, the line's statement declares an object whose address is known but whose contents won’t be defined until after the statement has been executed, including the call to its initializer. So print at this point shows the contents of the object’s known, but uninitialized, memory.
As #HolyBlackCat suggested in a comment, you can type next, and GDB will execute the current line's statement or statements, including any initializers and function calls, and stop just before the next line of source code to be executed in the current function[1].
At that point, print inputmap will show the correct value[2].
[1] or its caller, if you're at a return statement
[2] assuming it wasn’t a return statement
Related
For the past 2 days I've been stuck on a violation which I can't seem to get to go away.
I've used break points and located where the error is, but I'm just hoping one of you will know what the issue is without me having to copy+paste all my code -.-
I'm getting
First-chance exception at 0x1027cb1a (msvcr100d.dll) in Escape.exe: 0xC0000005: Access violation writing location 0xcccccccc.
Unhandled exception at 0x1027cb1a (msvcr100d.dll) in Escape.exe: 0xC0000005: Access violation writing location 0xcccccccc.
Now, a quick google search makes me think there's something peculiar going on. All the search results talk about pointers not actually pointing anywhere (0xccccccccc is a low memory address?).
I'm yet to use pointers in my code but either way I'll paste the function and point out the line the exception gets thrown (in bold):
void mMap::fillMap(){
for(int i = 0; i <= 9; i++){
for(int z = 0; z <= 19; z++){
Tile t1; // default Tile Type = "NULLTILE"
myMap[i][z] = t1;
}
}
}
Now myMap is a 2d array of type Tile. I had this working a couple of days ago until I added some other classes and it all stopped working!
Either an uninitialized pointer, or a pointer stored in memory that's been freed. I think cccccccc is the first and cdcdcdcd is the second, but it varies with compiler/library implementation.
For your particular code, probably myMap hasn't been allocated yet, then myMap[0][0] would result in an access attempt to 0xcccccccc.
It can also happen that myMap is the beginning of your class, and the class pointer was uninitialized:
class mMap
{
Tile myMap[10][20];
public:
void f() { myMap[0][0] = 0; }
};
mMap* what;
what->f(); // what is an invalid pointer
This happens because the member function is not virtual, so the compiler knows what code to run and passes the object pointer as a hidden parameter. Eventually the compiler emits a calculation like:
this + offsetof(Whatever::myMap) + z * sizeof(myMap[0]) + i * sizeof(myMap[0][0])
this, being uninitialized, is 0xcccccccc. Evidently the offsetof part is zero, and i and z are both zero the first time through your loop, so you get 0xcccccccc + 0 + 0 + 0 as the memory address.
To debug this, use the call stack and find the function that called fillMap. Then check in that function where the pointers used for member access (->) came from.
On MSVC++ and in debug mode, the debugging memory allocator sets all returned memory to 0xcccccccc, as a way to find cases of undefined behavior. In all likelihood, you never initialized myMap , or some of the pointers inside of myMap. Check your initialization code for bugs.
For all of the answers and comments happening in this question, here are good references about memory fills in Visual C++:
http://msdn.microsoft.com/en-us/library/bebs9zyz.aspx
When and why will an OS initialise memory to 0xCD, 0xDD, etc. on malloc/free/new/delete?
Had similar error when I tried to fill string value in table element of my own-class type with for-loop. I declared 1000 elements in that table, so I've put something like that:
for (int i = 0; i <= 1000; i++)
{
TAble[i].name = "Some Guy";
TAble[i].age = 4;
}
Unfortunately as with string it occurred that I'm perhaps insisting on fillinf element that doesn't exist witch is element number 1000 in table. I managed to solve this by changing loop header, deleting equal sign before 1000.
Try to see whether you're not trying to call something that doesnt exist.
For the past 2 days I've been stuck on a violation which I can't seem to get to go away.
I've used break points and located where the error is, but I'm just hoping one of you will know what the issue is without me having to copy+paste all my code -.-
I'm getting
First-chance exception at 0x1027cb1a (msvcr100d.dll) in Escape.exe: 0xC0000005: Access violation writing location 0xcccccccc.
Unhandled exception at 0x1027cb1a (msvcr100d.dll) in Escape.exe: 0xC0000005: Access violation writing location 0xcccccccc.
Now, a quick google search makes me think there's something peculiar going on. All the search results talk about pointers not actually pointing anywhere (0xccccccccc is a low memory address?).
I'm yet to use pointers in my code but either way I'll paste the function and point out the line the exception gets thrown (in bold):
void mMap::fillMap(){
for(int i = 0; i <= 9; i++){
for(int z = 0; z <= 19; z++){
Tile t1; // default Tile Type = "NULLTILE"
myMap[i][z] = t1;
}
}
}
Now myMap is a 2d array of type Tile. I had this working a couple of days ago until I added some other classes and it all stopped working!
Either an uninitialized pointer, or a pointer stored in memory that's been freed. I think cccccccc is the first and cdcdcdcd is the second, but it varies with compiler/library implementation.
For your particular code, probably myMap hasn't been allocated yet, then myMap[0][0] would result in an access attempt to 0xcccccccc.
It can also happen that myMap is the beginning of your class, and the class pointer was uninitialized:
class mMap
{
Tile myMap[10][20];
public:
void f() { myMap[0][0] = 0; }
};
mMap* what;
what->f(); // what is an invalid pointer
This happens because the member function is not virtual, so the compiler knows what code to run and passes the object pointer as a hidden parameter. Eventually the compiler emits a calculation like:
this + offsetof(Whatever::myMap) + z * sizeof(myMap[0]) + i * sizeof(myMap[0][0])
this, being uninitialized, is 0xcccccccc. Evidently the offsetof part is zero, and i and z are both zero the first time through your loop, so you get 0xcccccccc + 0 + 0 + 0 as the memory address.
To debug this, use the call stack and find the function that called fillMap. Then check in that function where the pointers used for member access (->) came from.
On MSVC++ and in debug mode, the debugging memory allocator sets all returned memory to 0xcccccccc, as a way to find cases of undefined behavior. In all likelihood, you never initialized myMap , or some of the pointers inside of myMap. Check your initialization code for bugs.
For all of the answers and comments happening in this question, here are good references about memory fills in Visual C++:
http://msdn.microsoft.com/en-us/library/bebs9zyz.aspx
When and why will an OS initialise memory to 0xCD, 0xDD, etc. on malloc/free/new/delete?
Had similar error when I tried to fill string value in table element of my own-class type with for-loop. I declared 1000 elements in that table, so I've put something like that:
for (int i = 0; i <= 1000; i++)
{
TAble[i].name = "Some Guy";
TAble[i].age = 4;
}
Unfortunately as with string it occurred that I'm perhaps insisting on fillinf element that doesn't exist witch is element number 1000 in table. I managed to solve this by changing loop header, deleting equal sign before 1000.
Try to see whether you're not trying to call something that doesnt exist.
The following program is running into segmentation fault and I cannot figure why.
vector<int> *A::B(vector<int> *prefix, vector<int> *projected_tids, int support) {
vector<int> *result = NULL;
for(it_vec it = projected_tids->begin(); it != projected_tids->end(); ++it) {
if(projected_tids == NULL) {
cout<<"NULL";
} else {
cout<<"abc"<<endl;
cout<<&projected_tids<<"address"<<endl;
}
cout<<"here"<<projected_tids->size()<<" "<<prefix->size()<<endl;
cout<<"iteration: "<<projected_tids->at(1)<<endl; //seg fault here
map<int, bool> *transaction = (*processed_input)[*it]; //seg fault here as well, because of *it
bool found = true;
//some more code
}
}
The prompt looks like this:
abc
0x7ffe3894a198address
here16 1
Segmentation fault (core dumped)
GDB is also confusing, might be because I am using C++ after a long time, but I cannot figure why? Below is GDB output:
(gdb) print projected_tids == (void *)0
$14 = false
(gdb) print *(projected_tids._M_impl._M_start)#1
Cannot access memory at address 0x0
(gdb) print *(projected_tids._M_impl._M_start)#3
Cannot access memory at address 0x0
(gdb) print projected_tids
$15 = (std::vector<int, std::allocator<int> > *) 0x60e000
The allocation of pointer to vector is done as in the calling class:
vector<int> *projected_tids = new vector<int>();
Please let me know if any more information is needed.
OK So a number of things going wrong. Concentrating on the question, it looks like:
projected_tids is not NULL (as you're done your check with cout)
Your code then dumps out the address of the projected_tids pointer, (which is on the stack), not the address of the vector. There's nothing wrong with that, but will be a bit misleading.
It reports that projected_tids contains 16 elements
It then seg faults (i.e. invalid use of pointer) when you look at the 2nd item (at(1) use a 0-index). This is the big hint that something is a bit wrong.
It looks like projected_tids is not a valid vector. Whatever is passing the data into your A::B method is passing in a bad pointer somehow. Perhaps uninitialised? You say it's allocated, but maybe it was deleted then?
A few other bits
As mentioned, you're using projected_tids before checking if it was NULL
What's the processed_input pointer all about? There's no reference to it anywhere
Why not use references? They're safer and just as performant as passing pointers.
You already call a member function on a pointer-to-object without checking for NULL first:
for(it_vec it = projected_tids->begin(); it != projected_tids->end(); ++it) {
^^^^^^^^^^^^^^^^^^^^^^^
unconditional call to member function
if(projected_tids == NULL) {
^^^^^^^^^^^^^^^^^^^^^^^^^^
Only here you test for NULL or not
So the logic in your program is flawed (big time) and anything might happen.
Also you cannot use ->at(1) without checking that the size is at least 2. In your example the size of the vector is 0.
As an aside: why don't you pass the vectors in by reference?
The logic does not seem correct.
if(projected_tids == NULL) {
cout<<"NULL";
} else {
you check for null.If it is null, you print null and then go ahead and dereference it.
cout<<"iteration: "<<projected_tids->at(1)<<endl;
If it is NULL, donot dereference it.
Here is an extremely simplified version of my class:
Class MyClass {
public:
int sizeDesired;
};
I'm creating a vector of MyClass instances in main:
int main(int argc, char **argv) {
std::vector<MyClass> myvec;
for(int i=0; i<10; ++i)
myvec.push_back(MyClass());
for(int i=0; i<myvec.size(); ++i)
doWork(myvec[i]);
return 0;
}
There's some memory corruption (I think) error that is causing my program to crash. I have observed that the value of MyClass::sizeDesired is garbage when the program crashes. So, I want to set a watchpoint on each MyClass:sizeDesired member so I can see exactly when any of these members' values changes.
Using GDB, how can I do this?
When I break after pushing all the instances of MyClass onto the std::vector<MyClass> in main, I then do
(gdb) watch myvec[0].sizeDesired
but GDB just hangs. It doesn't display a new command prompt (i.e., it doesn't show (gdb) on the succeeding line... just a blank line and nothing seems to be happening).
I'm open to non-GDB based solutions. If this type of inspection/monitoring is not possible in GDB, is there an alternative tool that could be used?
I did not do much C++ debugging in gdb, so these are probably all well known issues.
The problem with your watchpoint seems to be caused by gdb's inability to actually execute some methods, like [] operator or at() method. You can try this by just giving print myvec.at(0). It looks like this test is missing from watchpoint code, and it freezes the gdb. (It's probably known gdb bug, but I'll check.)
Now for the workaround. You can access n-th element of the vector using:
(MyClass*)(myvec._M_impl._M_start+n)
For sizeDesired that would then be:
(((MyClass*)(myvec._M_impl._M_start+n))->sizeDesired)
Adding a watchpoint to this expression still freezes gdb for some reason.
But print works, so if you do something like:
print &(((MyClass*)(myvec._M_impl._M_start+3))->sizeDesired)
You will get pointer to the field you want to watch. Something like this will get printed out:
$1 = (int *) 0x40508c
Now issue:
watch *((int*)0x40508c)
continue
Hardware access (read/write) watchpoint 3: ((int)0x40508c)
...
BTW: Ideas how to print std containers were snitched from http://sourceware.org/ml/gdb/2008-02/msg00064/stl-views.gdb.
For the past 2 days I've been stuck on a violation which I can't seem to get to go away.
I've used break points and located where the error is, but I'm just hoping one of you will know what the issue is without me having to copy+paste all my code -.-
I'm getting
First-chance exception at 0x1027cb1a (msvcr100d.dll) in Escape.exe: 0xC0000005: Access violation writing location 0xcccccccc.
Unhandled exception at 0x1027cb1a (msvcr100d.dll) in Escape.exe: 0xC0000005: Access violation writing location 0xcccccccc.
Now, a quick google search makes me think there's something peculiar going on. All the search results talk about pointers not actually pointing anywhere (0xccccccccc is a low memory address?).
I'm yet to use pointers in my code but either way I'll paste the function and point out the line the exception gets thrown (in bold):
void mMap::fillMap(){
for(int i = 0; i <= 9; i++){
for(int z = 0; z <= 19; z++){
Tile t1; // default Tile Type = "NULLTILE"
myMap[i][z] = t1;
}
}
}
Now myMap is a 2d array of type Tile. I had this working a couple of days ago until I added some other classes and it all stopped working!
Either an uninitialized pointer, or a pointer stored in memory that's been freed. I think cccccccc is the first and cdcdcdcd is the second, but it varies with compiler/library implementation.
For your particular code, probably myMap hasn't been allocated yet, then myMap[0][0] would result in an access attempt to 0xcccccccc.
It can also happen that myMap is the beginning of your class, and the class pointer was uninitialized:
class mMap
{
Tile myMap[10][20];
public:
void f() { myMap[0][0] = 0; }
};
mMap* what;
what->f(); // what is an invalid pointer
This happens because the member function is not virtual, so the compiler knows what code to run and passes the object pointer as a hidden parameter. Eventually the compiler emits a calculation like:
this + offsetof(Whatever::myMap) + z * sizeof(myMap[0]) + i * sizeof(myMap[0][0])
this, being uninitialized, is 0xcccccccc. Evidently the offsetof part is zero, and i and z are both zero the first time through your loop, so you get 0xcccccccc + 0 + 0 + 0 as the memory address.
To debug this, use the call stack and find the function that called fillMap. Then check in that function where the pointers used for member access (->) came from.
On MSVC++ and in debug mode, the debugging memory allocator sets all returned memory to 0xcccccccc, as a way to find cases of undefined behavior. In all likelihood, you never initialized myMap , or some of the pointers inside of myMap. Check your initialization code for bugs.
For all of the answers and comments happening in this question, here are good references about memory fills in Visual C++:
http://msdn.microsoft.com/en-us/library/bebs9zyz.aspx
When and why will an OS initialise memory to 0xCD, 0xDD, etc. on malloc/free/new/delete?
Had similar error when I tried to fill string value in table element of my own-class type with for-loop. I declared 1000 elements in that table, so I've put something like that:
for (int i = 0; i <= 1000; i++)
{
TAble[i].name = "Some Guy";
TAble[i].age = 4;
}
Unfortunately as with string it occurred that I'm perhaps insisting on fillinf element that doesn't exist witch is element number 1000 in table. I managed to solve this by changing loop header, deleting equal sign before 1000.
Try to see whether you're not trying to call something that doesnt exist.