Sign in to follow this  
Rhaal

Access violation reading 0x4753443a

Recommended Posts

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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'.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Quote:
Original post by Anon Mike
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.


Could be a buffer overrun. {0x47 0x53 0x44 0x3a} is "GSD:"

Share this post


Link to post
Share on other sites
Quote:
Original post by Anon Mike
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.


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: [url]http://www.codeproject.com/KB/files/EZUTF.aspx[/url] 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]

Share this post


Link to post
Share on other sites
Quote:
Original post by Rhaal
I'm using this library to read text files: [url]http://www.codeproject.com/KB/files/EZUTF.aspx[/url] 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 frob
Could be a buffer overrun. {0x47 0x53 0x44 0x3a} is "GSD:"
More like ":DSG" considering that we're talking about a little-endian system (0xC0000005 is a Win32 thing.)

Share this post


Link to post
Share on other sites
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 :(

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this