4

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?

Dominique
  • 16,450
  • 15
  • 56
  • 112
  • 4
    Writing to (or even reading from) memory you don't "own" leads to *undefined behavior*. Without source it's really going to be extremely hard to find the problem and what caused it. It's also going to be nigh impossible to fix it anyway. As for *guessing* about possible reasons, perhaps an uninitialized local pointer variable was used? – Some programmer dude Jan 16 '19 at 09:34
  • All the `??` let me think that memory at this address doesn not belong to the debugged process. (Even the debugger is not willing or able to read it.) So, this really looks like an "Access violation". – Scheff's Cat Jan 16 '19 at 09:37
  • @Scheff: What do you mean by "not belonging to the debugged process"? I thought that, in Windows, every process has the permission to use every piece of free memory to do its job, without limitation (except when the computer runs out of memory, of course). Can you confirm this and where can I find information about this? – Dominique Jan 16 '19 at 09:41
  • The memory could be write-protected. Also, if the only thing on the call stack is `memcpy`, you've probably smashed the stack very badly. – molbdnilo Jan 16 '19 at 09:43
  • Definitely not. Every process has to request blocks of memory from the OS (the Windows kernel). Afterwards it may read/write access exclusively this memory. Other parts of overall memory must be in-accessable. This is for protection of processes against each other. [Wikipedia: Memory Protection](https://en.wikipedia.org/wiki/Memory_protection) – Scheff's Cat Jan 16 '19 at 09:44
  • @Scheff: so we could have the following situation here: some applications are using quite a lot of memory. One application wants to use some more (while it already using quite some memory). In order to do this, it wants to reserve a block of memory from the OS kernel. However, there are no more blocks available, and the application crashes. When this is the case, shouldn't I get an `Out-of-Memory` error instead of an access violation? – Dominique Jan 16 '19 at 09:47
  • Yepp - out-of-memory. Though, there are multiple ways to handle out-of-memory - throwing an exception, just remember a null pointer, or trying to use the address without checking. The latter is good for the access violation but the not so bad address value does not look like this. May be, this is an out of bound access that happened just at the end of granted address space. However, it's all guessing without more details... – Scheff's Cat Jan 16 '19 at 09:51
  • @Dominique - that depends on a lot of things. If a program doesn't check if an allocation succeeds, and attempts to use the memory anyway, then using the memory can result in an access violation. The cause of an access violation, and also other symptoms related to abnormal program termination, is often the operating system detecting a program accessing something it shouldn't (e.g. memory that the operating system has not provided to that program) and then forceably terminating the program. – Peter Jan 16 '19 at 09:51
  • When I went out of memory on Windows last time, it looked very different: At first, everything became very slow as system started to swap memory pages. Finally, the overload was so heavy that even the mouse pointer stopped to move. After waiting a bit the whole system was totally unresponsive (though it still did uninterruptedly things with the HDD) and I switched the computer off. :-) – Scheff's Cat Jan 16 '19 at 09:53
  • Thanks for the offer but I think it's not worth a good answer as lacking a clear problem to be answered. It's a lot of guessing. However, if I could help to make things clearer I'm happy with that. ;-) – Scheff's Cat Jan 16 '19 at 09:59
  • As it stands, the question will probably be closed due to a lack of a [mcve], I suggest you provide one. – Passer By Jan 16 '19 at 10:49

3 Answers3

1

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.

David Schwartz
  • 179,497
  • 17
  • 214
  • 278
1

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.

user3344003
  • 20,574
  • 3
  • 26
  • 62
0

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.

Dominique
  • 16,450
  • 15
  • 56
  • 112