Can an access violation be a disguised out-of-memory error?

user_4279155 0
Viewed 1217

I'm debugging a 64-bit C++ (managed) crash dump (access violation).

The dump has a total size of 32.374.535 kb.

The application is multi-threaded, and the corresponding call stack only mentions mscvrt.dll!memcpy (I don't know which other thread is creating this one). Obviously there is no corresponding source code.

The Visual Studio Locals window is empty.

The unhandled exception mentions Access violation writing location 0x000000F02A6BB000, but on that location, there seems to be nothing:

0x000000F02A6BAF84  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ..............................................................
0x000000F02A6BAFC2  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ..............................................................
0x000000F02A6BB000  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??  .............................................................. <= here it is.
0x000000F02A6BB03E  ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??  ..............................................................

I don't see any reason why the writing on this memory location would cause any problem, therefore I believe (based on the size of the dump) that I'm dealing with a memory error (meaning it would impossible to copy something into memory, because so many memory is already used that there's no room left). However, if this would be true, shouldn't there be some information in that memory location?

Does anybody have an idea about this?

access-violation memcpy crash-dumps memory-management c++
3 Answers

Without seeing the source code, there's no way to know what it might do if it encounters an out-of-memory error. There are certainly lots of programs out there that don't check every memory allocation for failure and their code could go completely off the rails as a result.

The most common result of an out-of-memory error that isn't checked is an access violation, but it's usually at an address that's either very small or has some obvious nonsenical pattern in it. This is because many memory allocation functions return zero when they're out of memory and a failure to check could result in accessing an address near the returned value. Also, some functions leave the result uninitialized and return a separate error. Failing to check that error might result in using the uninitialized value to access memory and that usually looks very strange.

Here, the address looks reasonable. But who knows. Maybe the code allocates a new buffer, frees the old one, and switches the old address for the new one but, on an error, doesn't switch addresses but does free the old address, causing an access after free. Without the source code, there's no way to know.

user_7212690

Intuitively, it does not look to me like an out of memory error. Memory allocation system services on some poorly designed operating systems will return successfully values when they have failed to allocate the memory. As many flaws as Windoze has, I do not believe it is such a system. If you were running on a system that does do some kind of delayed allocation, then I'd suspect what you suspect.

Methinks, that you are getting a memory overrun that is causing a write to a page that has not been mapped into the address space.

user_33440030

It is indeed possible that an access violation is in fact an out-of-memory error (or other kind of memory related error), as mentioned in the comments of Scheff and Peter.

In this particular case, the large size of the dump (±33Gb) is an indication that the application (together with other applications) might consume too much memory.

user_42791550
Related