How do I find out the contents of an address post-crash?
Hi,
I am debugging a very large program that was written by somebody else (I do not have access to the originHi,
I am debugging a very large program that was written by somebody else (I do not have access to the original programmers). I have added some OpenMP directives in attempts to parallelise the program. The program runs smoothly in Debug Mode, and crashes in Release Mode, naturally. To be more specific, the program crashes, and when Windows asks me do I want to debug the crash, it places an access violation to a delete command inside a destructor of a certain object. However, I have been rattling my brain last number of days trying to trace as to how this became an access violation, because the access violation is totally sequential and has nothing to do to the code I changed.
Moreover, I tried to do an Attach process to the Release mode run with my compiler to try and get more information. I have noticed that there is another Access Violation that occurs but does not crash the program right before the original crashing violation.
First-chance exception at 0x7c9504a1 in hl2.exe: 0xC0000005: Access violation reading location 0x00047a5d. // The non-crasher.
First-chance exception at 0x7c9504a1 in hl2.exe: 0xC0000005: Access violation reading location 0x00003135. // The original crasher.
My first question what are those addresses refer to? I mean, is 0x7c9504a1 the address of the executed operation in the program, or the location of the variable being accessed?
Second, and more importantly, is there a way to know what the data that is inside those locations (what those pointers were pointing at, data type, object type...etc )?
My third question, and I suspect it to be unreleastic, can I know who made the call? Who made the access violation?
Note, my questions are regarding the non-crasher more than the crasher.
I hover with my mouse over the locations but I get an integer value which I am not sure if it is the data that is inside those pointers or just the equivelance of the hex number.
The background:
XP, Visual Studio 2008 Pro Ed, OpenMPal programmers). I have added some OpenMP directives in attempts to parallelise the program. The program runs smoothly in Debug Mode, and crashes in Release Mode, naturally.
Thank you
I am debugging a very large program that was written by somebody else (I do not have access to the originHi,
I am debugging a very large program that was written by somebody else (I do not have access to the original programmers). I have added some OpenMP directives in attempts to parallelise the program. The program runs smoothly in Debug Mode, and crashes in Release Mode, naturally. To be more specific, the program crashes, and when Windows asks me do I want to debug the crash, it places an access violation to a delete command inside a destructor of a certain object. However, I have been rattling my brain last number of days trying to trace as to how this became an access violation, because the access violation is totally sequential and has nothing to do to the code I changed.
Moreover, I tried to do an Attach process to the Release mode run with my compiler to try and get more information. I have noticed that there is another Access Violation that occurs but does not crash the program right before the original crashing violation.
First-chance exception at 0x7c9504a1 in hl2.exe: 0xC0000005: Access violation reading location 0x00047a5d. // The non-crasher.
First-chance exception at 0x7c9504a1 in hl2.exe: 0xC0000005: Access violation reading location 0x00003135. // The original crasher.
My first question what are those addresses refer to? I mean, is 0x7c9504a1 the address of the executed operation in the program, or the location of the variable being accessed?
Second, and more importantly, is there a way to know what the data that is inside those locations (what those pointers were pointing at, data type, object type...etc )?
My third question, and I suspect it to be unreleastic, can I know who made the call? Who made the access violation?
Note, my questions are regarding the non-crasher more than the crasher.
I hover with my mouse over the locations but I get an integer value which I am not sure if it is the data that is inside those pointers or just the equivelance of the hex number.
The background:
XP, Visual Studio 2008 Pro Ed, OpenMPal programmers). I have added some OpenMP directives in attempts to parallelise the program. The program runs smoothly in Debug Mode, and crashes in Release Mode, naturally.
Thank you
I had finished writing a reply, yesterday, but I accidentally hit ctrl-R instead of ctrl-T and ended up losing what I wrote. I didn't feel answering any more questions last night.
The memory address that you tried to illegally access.
The OS crashed your program for trying to see them, so no. It wouldn't do you any good, anyway, since those regions don't belong to the program and have nothing relevant.
There are only three ways to fix this kind of bug:
1. Stare at the code really hard. You'll eventually find what's wrong.
2. Try to produce the error in a debug build. If you're lucky, the bug will be close to the place where the buffer overflow occurred. If you're not, the bug can be anywhere in the program and you have to move on to 1 or 3.
3. Use a memory debugger to find all memory issues in the program.
http://en.wikipedia.org/wiki/Memory_debugger
Valgrind, for example, can detect buffer overflows, use of uninitialized data, Illegal memory deallocations, and memory leaks; but it's only for Linux.
| what are those addresses refer to? |
| is there a way to know what the data that is inside those locations (what those pointers were pointing at, data type, object type...etc )? |
There are only three ways to fix this kind of bug:
1. Stare at the code really hard. You'll eventually find what's wrong.
2. Try to produce the error in a debug build. If you're lucky, the bug will be close to the place where the buffer overflow occurred. If you're not, the bug can be anywhere in the program and you have to move on to 1 or 3.
3. Use a memory debugger to find all memory issues in the program.
http://en.wikipedia.org/wiki/Memory_debugger
Valgrind, for example, can detect buffer overflows, use of uninitialized data, Illegal memory deallocations, and memory leaks; but it's only for Linux.
I really like the replies that can help me, and can change my programming life for the future!
Thank you so much for that very informative reply! I will try this as soon as possible.
Thank you so much for that very informative reply! I will try this as soon as possible.
Topic archived. No new replies allowed.