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.
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.
In this code below I try to access the '-1'th element of an array, I don't get any runtime error.
#include <stdio.h>
int A[10] = {0};
int main(){
A[-1] += 12;
printf("%d",A[-1]);
return 0;
}
When I run the code, it outputs 12 that means it is adding 12 to the non-existent A[-1]. Till today whenever I had tried to access an out-of-bounds element, I had got a runtime-error. I had never tried it on a simple code before.
Can anyone explain why does my code run successfully?
I ran it on my computer and also on ideone, in both the cases it ran successfully.
You see, when you allocate a variable like this, it lands on the stack. Stack holds small packages of information about local variables in each function you call, to say it in simple words. The runtime is able to check, whether you exceed the bounds of allocated stack, but not if you write some data in the invalid place on the stack. The stack may look like the following:
[4 bytes - some ptr][4 bytes - A's first element][4 bytes - A's second element] ...
When you try to assign to -1th element of an array, you actually attempt to read four bytes preceding the array (four bytes, because it's an int array). You overwrite some data held on stack - but that's still in valid process's memory, so there are no complaints from the system.
Try running this code in release mode in Visual Studio:
#include <stdio.h>
int main(int argc, char * argv[])
{
// NEVER DO IT ON PURPOSE!
int i = 0;
int A[5];
A[-1] = 42;
printf("%d\n", i);
getchar();
return 0;
}
Edit: in response to comments.
I missed the fact, that A is global. It won't be held in stack, but instead (mostly probably) in .data segment of the binary module, however the rest of explanation stands: A[-1] is still within process's memory, so assignment won't raise AV. However, such assignment will overwrite something, that is before A (possibly a pointer or other part of the binary module) resulting in undefined behavior.
Note, that my example may work and may not, depending on compiler (or compiler mode). For example, in debug mode the program returns 0 - I guess, that memory manager inserts some sentry data between stack frames to catch errors like buffer over/underrun.
C and C++ does not have any bounds checking. It is a part of the language. It is to enable the language to execute faster.
If you want bounds checking use another language that has it. Java perhaps?
As your code executes you are just lucky.
In C++ (and C), the arrays don't check out of range indices. They're not classes.
In C++11, however you could use std::array<int,10> and at() function as:
std::array<int,10> arr;
arr.at(-1) = 100; //it throws std::out_of_range exception
Or you can use std::vector<int> and at() member function.
I am currently learning how to multithread with c++, and for that im using boost::thread.
I'm using it for a simple gameengine, running three threads.
Two of the threads are reading and writing to the same variables, which are stored inside something i call PrimitiveObjects, basicly balls, plates, boxes etc.
But i cant really get it to work, i think the problem is that the two threads are trying to access the same memorylocation at the same time, i have tried to avoid this using mutex locks, but for now im having no luck, this works some times, but if i spam it, i end up with this exception:
First-chance exception at 0x00cbfef9 in TTTTT.exe: 0xC0000005: Access violation reading location 0xdddddded.
Unhandled exception at 0x77d315de in TTTTT.exe: 0xC0000005: Access violation reading location 0xdddddded.
These are the functions inside the object that im using for this, and the debugger is also blaming them for the exception.
int PrimitiveObj::setPos(glm::vec3 in){
boost::try_mutex::scoped_try_lock lock(myMutex);
if ( lock)
{
position = in;
return 1;
}
return 0;
}
glm::vec3 PrimitiveObj::getPos(){
boost::try_mutex::scoped_try_lock lock(myMutex);
if ( lock)
{
glm::vec3 curPos = position;
return curPos;
}
return glm::vec3(0,0,0);
}
This is the function im using to generate each primitiveobj. (updated)
void generatePrimitive(){
PrimitiveObj *obj = new PrimitiveObj();
obj->generate();
obj->setPos(getPlayerPos()+getEye()*4.0f);
prims.push_back(std::shared_ptr<PrimitiveObj>(obj));
}
Any ideas?
Edit: New functions(2), and myMutex is now private to the object. Added the function i use to generate the primitiveobjects.
Edit:
This is the code that the stack is pointing at, and this is running inside the physics thread:
nr = getNumberOfPrimitives();
double currentTime = glfwGetTime();
float deltaTime = float(currentTime - lastTime);
for(int r = 0; r < nr; r++) {
prop = getPrimitive(r);
glm::vec3 pos = prop->getPos()+glm::vec3(0,1.0f*Meter/deltaTime,0);
prop->setPos(pos);
}
Other relevant code:
int getNumberOfPrimitives(){
return prims.size();
}
PrimitiveObj * getPrimitive(int input) {
return prims[input];
}
The first idea is that your PrimitiveObj that you are calling is uninitialized, something like this:
PrimitiveObj* myObject;
myObject->getPos();
The exception you have is most likely you accessing an uninitialized pointer variable (set to 0xdddddddd so the developer recognizes it as uninitialized) and accessing a member on it that is offset by 0x10 (=16) bytes.
Access Exceptions can also happen if you access objects such as std:vector while reading and writing from different threads to the same object at the same time, but the location is often a more random looking number that starts with zeros and is divisible by 4 (e.g. 0x004da358).
Why is that the case? Debug code often initializes memory with some recognizable yet random numbers (0xdddddddd, 0xbaadfood, 0xfefefefe, etc). They are random because if the variables would always be the same, e.g. always initialized to 0, which could cause the developer to miss the fact that some variables are not initialized and the code would stop working in release. They are easy to recognize so we can tell at a glance that the number comes from uninitialized memory.
Formerly valid pointers point to the heap address space, which usually starts from a somewhat low number and counts up. If multiple objects are allocated on the heap, in normal operation each object is aligned, on a memory address divisible by 4, 8, 16, etc. the members of an object are aligned on 4 byte boundaries as well, that's why access violations caused by accessing formerly valid memory are often on addresses that start with zeros and are divisible by 4.
Keep in mind that these are rules of thumb which can and should be used to point you in the right direction, but they are not hard and fast rules. Also, they refer to debug environments. Release environments have very different rules to guessing which Access Violation is caused by what.
I'm getting an access violation on a char array I just created using new.
DispatchCommand(char* cmdStr)
{
// Dispatch
for(int i = 0; i < sizeof(_lpCommands); i++)
{
const int len = strlen(_lpCommands[i].szCommand);
char* cmdblip = new char[len + 1];
memcpy(&cmdblip, cmdStr, len);
cmdblip[len] = '\0'; // Access Violation
if(strcmp(cmdblip, _lpCommands[i].szCommand) == 0)
{
if(strlen(cmdStr) > strlen(_lpCommands[i].szCommand))
(*_lpCommands[i].cbCallback)(&cmdStr[strlen(_lpCommands[i].szCommand)]);
else
(*_lpCommands[i].cbCallback)("");
delete cmdblip;
return;
}
delete cmdblip;
}
// Error and return
*Out::ServerInfo<<"Command not found!"<<ENDL;
}
_lpCommands is an array of Command structures:
struct Command
{
char* szCommand;
CommandCallback cbCallback;
};
The produced error message is:
Unhandled exception at 0x012219cf in Program.exe: 0xC0000005: Access
violation writing location 0x66647366.
This was a rewrite of similar code which was using memcmp, which ended up giving me an access violation as well without be doing a memcpy.
What gives?
Don't pass &cmdblip to memcpy. You should pass a pointer to the destination buffer, not a pointer to that pointer. Pass cmdblip instead.
Edit: I agree that in general, std::string should be used in C++. Still, the technical reason this code crashes is that memcpy corrupts the cmdblip pointer, making it point on a memory location that is actually made of the first 4 bytes of the copied string. Then, cmdblip[len] results in a memory location that is not within the allocated buffer (or any other legally allocated buffer), hence the crash. So, if you want to write better code, use C++ classes. And if you want to understand why the given code crashed, consider the above.
The only possible helpful answer to this question is "Use std::string". The specific problem you are having now will simply re-occur, or an identical one, every time you modify this function or write another like it. The only way to solve the problem in the general case is to move to a class-based solution, which is kindly provided for you as Standard. For example, your current code is exception unsafe, on top of whatever is giving you an access violation, not to mention that it's unreadable and begging for a number of other errors, such as off-by-one, not properly NULL terminating, double deletes, and memory leaks. Oh, and UB because you delete what you new[].
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.