A c/c++ app throws that error, how to start to debug (better idea than adding print statements)?
views:
942answers:
6
+1
A:
Dfficult to suggest anything, without the code. Try using a debugger and setting breakpoints in your code just before you hit the problem.
dirkgently
2009-04-21 11:35:50
+6
A:
Is the second address a very small number, like 0x00000001 or 0x00000000? If so, you probably just forgot to initialize a pointer.
In any case, standard debugging tricks apply: start isolating the problem by noticing when it happens and narrowing things down from there.
John Feminella
2009-04-21 11:35:58
Small number: initialized a pointer to NULL, never assigned a proper value. Random number way outside your address space (especially if most or all bytes of the pointer are in the range 0x20-0x7f!): forgot to initialize the pointer, contains bytes from other objects.
MSalters
2009-04-22 11:09:37
+1
A:
Depending on your development environment, a map file for your program may help
dmityugov
2009-04-21 12:31:07
+2
A:
The error message suggests that your are developing with Visual Studio. Well, at least that's the only development environment where I've seen this error message in that wording.
If that's the case, you can use the built-in exception debugging to trap the access violation and get the call stack that way.
To do this in the VC++ 2003 I've currently got open, go to Debug->Exceptions, open 'Win32 Exceptions', click on "c0000005 Access Violation" and set "When the exception is thrown" to "Break into debugger".
Timo Geusch
2009-04-21 12:57:05
I've gotten that error from well-known name-brand software that has crashed, I was under the assumption that the message came from Windows. Always thought it was sad that it reports that the memory could not be "read" or "written".
Jason S
2009-04-21 13:40:21
Why's it in speech marks too? It's like it is trying to paraphrase or something.
dreamlax
2009-04-22 11:18:11
A:
Like others have said, if this is reproducible on your development machine, fire up a debugger and either set breakpoints / step through the code.
However, if this is happening on a customer's machine and a debugger is unavailable, you can get some of the same information (callstack, registers, etc) by using SetUnhandledExceptionFilter and writing the information out to a log file, or doing a minidump. I suspect a callstack would be the most useful starting place, so you could use one of the StackWalk functions in the handler and write to a log file. This requires at least either a map file or a set of symbols (PDB) for that build of the application.
Tadmas
2009-04-22 11:07:01