Access violation reading 0x4753443a
Author
I have a strange reading access violation that I just can't track down due to it's frequency, and my inability to reproduce in debug mode or in release mode with a debugger attached.
The code it seems to crash on doesn't crash all the time. It takes hundreds of calls to this before it happens. Another thing is, it's not always the same code. It either happens on a delete call or on a std::vector push_back. But the crash itself is deep in malloc_base.
Unhandled exception at 0x7c9122ba in App.exe: 0xC0000005: Access violation reading location 0x4753443a.
My question is how do I go to location 0x4753443a? In my map file, I can only see up to 0x0045bf7b, and in the memory window in Visual Studio it seems like it'd take 2 hours of scrolling to get anywhere near 0x4753443a.
If anyone has pointers, it would be great if you could pass them along (if they aren't NULL [lol] - sorry I'm going crazy!) I've searched up and down and can only find information on accessing a null pointer, which I believe is 0x00000000, and doesn't seem to be my problem.
Edit: I'd love to post code but it's basically just crashing on the push_back call, and I have 11,300 lines that I don't want to just dump on everyone.
My guess is that you are corrupting the heap. An easy way to do that is by doing something like calling delete twice on the same pointer. If you have objects that have pointers to data that they own and you don't provide correct copy constructors and assignment operators, this is bound to happen.
You can probably figure out the problem using some tool like Valgrind or Purify to monitor how you are managing memory.
You can probably figure out the problem using some tool like Valgrind or Purify to monitor how you are managing memory.
It's gotta be heap corruption by the sounds of it. Check for things like double free's, or accessing memory just after it is deleted, or buffer overflows. Not going to be an easy search though I imagine, as it could be caused by any bit of code that was executed.
Make sure you always follow the 'rule of three'.
Make sure you always follow the 'rule of three'.
Quote:Original post by Rhaal
in the memory window in Visual Studio it seems like it'd take 2 hours of scrolling to get anywhere near 0x4753443a.
It takes you two hours to type 0x4753443a into the address box of the memory window and hit enter?
Not that it would do you much good. Since you're getting an AV reading it the memory window will probably just show you a bunch of "??"'s.
Quote:Original post by Anon MikeQuote:Original post by Rhaal
in the memory window in Visual Studio it seems like it'd take 2 hours of scrolling to get anywhere near 0x4753443a.
It takes you two hours to type 0x4753443a into the address box of the memory window and hit enter?
Not that it would do you much good. Since you're getting an AV reading it the memory window will probably just show you a bunch of "??"'s.
Could be a buffer overrun. {0x47 0x53 0x44 0x3a} is "GSD:"
Author
Quote:Original post by Anon MikeQuote:Original post by Rhaal
in the memory window in Visual Studio it seems like it'd take 2 hours of scrolling to get anywhere near 0x4753443a.
It takes you two hours to type 0x4753443a into the address box of the memory window and hit enter?
Not that it would do you much good. Since you're getting an AV reading it the memory window will probably just show you a bunch of "??"'s.
You know, I was trying that and I just realized why I couldn't get it to work. I had Enter registered as a hotkey so it wasn't picking it up!
Edit: Woohoo, I found the problem :)
I'm using this library to read text files: http://www.codeproject.com/KB/files/EZUTF.aspx I wasn't calling free_block() on the buffer passed to ReadLine() which was causing a memory leak that eventually lead to the corruption.
Thanks for the tips!
[Edited by - Rhaal on November 7, 2008 3:27:19 PM]
Quote:Original post by Rhaal
I'm using this library to read text files: http://www.codeproject.com/KB/files/EZUTF.aspx I wasn't calling free_block() on the buffer passed to ReadLine() which was causing a memory leak that eventually lead to the corruption.
Memory leaks are certainly problems but they shouldn't cause crashes. Not unless you're not checking memory allocations anyway, but then I would've expected to see a null-pointer dereference instead. If the problem has to do with memory pool corruption then you can get some support from the standard CRT (clicky), though there are certainly far more powerful tools out there.
Anyway blindly hunting for access violations which only occur in "release mode" can be quite painful, and gets worse the larger your code-base is. One thing you may not know about, which you might want to try in the future, is that you can actually generate debugging information even for optimized code. With those you can usually figure out exactly what write operation triggered the violation without too much trouble, even if it occasionally involves deciphering a couple of assembly instructions to straighten things out. I've had to manually specify "/opt:ref" to force MSVC purge dead code, but aside from that and slightly longer compilation times I've not seen any disadvantages in having the debugging symbols around.
Oh, and if running the program inside of the debugger somehow suppresses the error then you should always have the option of attaching it after the fact at the point of the crash.
Quote:Original post by frobMore like ":DSG" considering that we're talking about a little-endian system (0xC0000005 is a Win32 thing.)
Could be a buffer overrun. {0x47 0x53 0x44 0x3a} is "GSD:"
Author
You're right, I inadvertently fixed another problem caused by a memory leak and this one is still there :( I'll be investigating more later, and I really appreciate all the tips. This has been tough :(
Sounds ugly. This sounds like it could be a case of memory stomping, resulting in a corrupted pointer value being written somewhere. I recommend you check any API function call that writes to a provided buffer and ensure that your buffers are correctly sized.
Gamasutra recently had an article that you may want to look at: Debugging Memory Corruption in Game Development
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
