Unhandled exception at 0x523d14cf (msvcr100d.dll) in IntellitracTCPIP.exe: 0xC0000005: Access violation reading location 0x00000008.
what can cause this error? and how to solve it
The address you're attempting to read suggests that you have a struct consisting of a number of 4-byte integers. You have a pointer to that struct type, but that pointer is null. Your program wants to read the third one — the offset of the third integer field would be 8. Add that to the null-pointer address 0, and you get 0x00000008. (It could be a struct of smaller or larger types, or even an array, but my experience tells me 4-byte integers is most likely.)
The error message indicates that the offending line of code belongs to msvcr100d.dll. That's not your code; you have probably passed a null pointer to some C run-time function. That function has assumed you provided a valid pointer and attempted to read the third field of the struct, but since that pointer is not valid, the OS intercepted the read attempt and threw an exception instead.
Find the last line of code in your program before that error occurs. To do that, you can use the call stack to see the chain of function calls that your program made to get to the point it crashed. Go down the list until you find one of your functions. Do you see any pointers? Can you guarantee that they're all valid when you call that function? If not, then are you sure you're supposed to call that function? Either make sure the pointer is valid, or avoid calling the function with null pointers.
0xC0000005: Access violation reading location 0x00000008.
This indicate a bad pointer. No pointers show point to such a low address as 0x00000008. You are not giving enough information on this, try running the program under a debugger.
Related
Certain functions in my program get a bad pointer with a low probability.
The pointer is the CComPtr <IHTMLDocument2> m_htmldocument2 variable.
Moving the m_htmldocument2 variable to a local variable causes an access violation error if m_htmldocument2 is not a valid value.
I did not have a way to check if m_htmldocument2 was a valid value, and tried to process it as __try __except, but I could not do it because there was a destructor.
Is there a safe way to move to a local variables?
I've created a class, say I named it MyClass, as well as another that inherits from it, say MyClassDaughter then I tried the following:
MyClassDaughter *MyClassDaughterPointer;
vector <MyClass*> MyClassVector;
MyClassVector.push_back(MyClassDaughterPointer);
MyClassVector[0]->SetSomethingInMyClassDaughter;
When I try to run the executable it says "Segmentation Violation".
(I think must say that my code has some Root stuff in it... Could that be the problem? Anyways, I know that, usually, segmentation violation errors are cause by trying to access memory that we don't have permission to access, but I think I do have permission to access this memory. Am I wrong?)
You do not initialize MyClassDaughterPointer, so you push some random (wild) pointer to the vector.
You need to create new instance of MyClassDaughterPointer. Assuming you have a default constructor, it will look like this:
MyClassDaughter *MyClassDaughterPointer = new MyClassDaughterPointer();
The pointer
MyClassDaughter *MyClassDaughterPointer;
Was never set to anything but there is some uninitialized content if that was on the stack or just null is that was static. Therefore you cannot try to access it as you do, that causes Undefined Behavior.
MyClassVector[0]->SetSomethingInMyClassDaughter; // that is same pointer set in vector entry
Unsure what compiler does as long as it usually has such code to be optimized out and that should not have any effect - no job for CPU here at all as long as that pointer is not used. But debug mode is right always attempting to load the address to some register.
What is the behavior of calling a null function pointer?
void (*pFunc)(void) = NULL;
pFunc();
Why is it advisable to initialize yet unused function pointers to NULL?
In C and C++, this is called undefined behaviour, meaning that this can lead to a Segmentation fault, nothing or whatever such a case will cause based on your compiler, the operating system you're running this code on, the environment (etc...) means.
Initializing a pointer to a function, or a pointer in general to NULL helps some developers to make sure their pointer is uninitialized and not equal to a random value, thereby preventing them of dereferencing it by accident.
What happnes when u try to access NULL?
Following is true about data as well as code, and this is what
happens when you try to read NULL(or any address from 0 to
4096,i.e atleast first page of segment). Root cause of this lies in
OS and microprocessor segmentation/paging architecture
When you try to access NULL( or 0) address, in any of data or code
section, it causes segmentation fault(which is actually a killer
page fault). First page of section is treated as out of( or invalid
part of) virtual address space. That is purposefully that first page
is kept invalid( or not present) so atleast one address that pointer
contains could be represented as invalid in program at execution
time.
Page descriptor of the 1st page(which contains virtual address 0,
NULL), has first bit "present" as 0 (means its invalid page). Now if
you try to access NULL pointer(0 address) it will cause to raise a
page fault as page is not present, and OS will try to handle this
page fault. When page fault handler see that its trying to access
1st page, which is treated as a invalid part of virtual address
space it kills the process. This is all about user space process. If
you try to access NULL pointer in system process(kernel level code),
it will fail your OS an crash the system.
Links: http://en.wikipedia.org/wiki/Page_fault#Invalid
http://en.wikipedia.org/wiki/Memory_protection#Paged_virtual_memory
http://pdos.csail.mit.edu/6.828/2005/readings/i386/s05_02.htm
Above is sufficient bt as i think u should read this as well
http://www.iecc.com/linker/linker04.txt
Why function pointer is initialized to NULL?
Although if you try to call the with NULL its going to give page/segment fault. NULL signifies its invalid function. If it
contains any garbage address but in valid virtual address space of
code section, i think any code at that address will be called, which
could be even more disaster(spl in case of real time systems).
Initialize funcp = funct_foo_name + 1; now call function using
function pointer. Function pointer points to valid virtual address
space of code section. bt function will start from incorrect place
to execute. which could result into wrong code execution or wrong
order.
It's advisable for the same reason as initializating "normal" (data) pointers to NULL: because it potentially makes some errors easier to track down. Opinions on whether this is useful or not of course vary :-)
I have a problem inserting elements into a pointer to a vector of some elements I defined in my code (in this case Recipes). In some other parts of the code, using push_back seems to work fine, but if I use it in this code:
{
Recipe defaultRec;
this->recipes_ = new vector<Recipe>;
this->recipes_->push_back(defaultRec);
}
I get the following error message:
"Unhandled exception at 0x01164031 in Assignment 2.exe: 0xC0000005: Access violation reading location 0xcccccce0"
The declaration of recipes_ is:
vector<Recipe>* recipes_;
Hope anyone can help me, thanks in advance.
Your code looks fine to me. I'm sure the problem is somewhere else.
By the way, why do you use pointer to vector? Why not this:
vector<Recipe> recipes_; //member
Recipe defaultRec;
recipes_.push_back(defaultRec);
Atleast this saves you from allocation and deallocation. Besides, most likely, pointer to vector doesn't serve you any better than the above!
There is nothing wrong with your code. The problem likely lies elsewhere. Problems like this are often caused by memory over writing such as writing past the end of an array or writing to an uninitialised memory location.
I'm trying to do some classic C development in Visual C++ 2008 that will modify the characters of a string like so:
void ModifyString(char *input)
{
// Change first character to 'a'
*input = 'a';
}
I'm getting a unhandled exception when I try to change a character. It seems like I could do this in Visual Studio 6 or using gcc, but maybe I'm just forgetting something. Does Visual Studio somehow pass char* by value (managing memory). If so, how do I turn this off?
You're probably passing a string literal somewhere:
ModifyString("oops"); // ERROR!
C and C++ allow you to implicitly cast from string literals (which have type const char[]) to char*, but such usage is deprecated. String constants are allowed to be allocated in read-only memory (and they usually are), so if you attempt to modify them, you'll get an access violation (aka segmentation fault or bus error). If the compiler doesn't put string constants in read-only memory, the program will still work, but it is undefined behavior.
The correct way to do this is to copy the string into a writeable buffer:
// one way:
char mystring[] = "test";
ModifyString(mystring); // ok
// another way:
char mystring[64]; // make sure this is big enough!!
strcpy(mystring, "test");
ModifyString(mystring); // ok
Is the input a string literal? That's probably the problem. Otherwise you'll need to post more code, as the pointer has somehow ended up pointing at a readonly location in memory.
It's impossible to answer this question without seeing how ModifyString is called. The function itself is correct assuming it's contract is to be passed a non-NULL value.
However it's possible for the call site to fail by doing any number of things
Passing NULL
Passing const char by means of an evil cast
I can't say exactly why this doesn't work, but the problem is in your code, not Visual Studio. For some reason, you are passing an invalid pointer to the function. It is either a null pointer, or it points to some address you don't have read access to.
If you post some more of the code (where is the function called from, and how is it called?), we may be able to point out the exact problem.
The reason it worked in GCC or VC6 is quite simply that it is undefined behavior. The C++ standard doesn't say that "this should work", or "this should cause a crash". Anything can happen if you write to memory you don't have access to. And depending on the compiler, and the system you're running the application on, the address you end up accessing will vary. By sheer luck, you hit an address that caused an access violation when compiled with VC2008. Under GCC and VC6, you weren't as lucky, and got code which appeared to work, and simply wrote to some garbage address.