5

I have a stl::vector (VS 2010 SP1, x86) out-of-bounds read access attempt that causes a crash on only three Windows 10 systems. It is completely reproducible on those systems, but cannot be reproduced on other systems (Windows 10 or otherwise), using the exact same executable and data files.

What security protections could be in place on those three systems that detect the violation, or why might it not be occurring on the other systems?

The errant software is in a C++ static library that is running from a .NET (managed) executable.

Patrick
  • 151
  • 2
  • 2
    Why do you think undefined behaviour in C++ should be reproducible? It isn't. – deviantfan Jun 10 '16 at 14:35
  • 2
    @deviantfan I would expect the heap layout used by the process to be the same on each system (unless ASLR is used, but then it shouldn't be reproducible on a single system). So if the overflow on one system stays within the process heap, it should be that way on all systems. It points to something like a difference in heap management, hence the question. – Patrick Jun 10 '16 at 16:09
  • I'd wonder if there were any noticable differences between the systems? Windows version (not just "Windows 10", but the build version), as well as the .NET version(s) installed on the system. –  Jun 10 '16 at 17:13
  • seems windows never uses 100% of RAM even if a programme requests for more and more allocations, windows uses page file to prevent running out of memory – Dee Apr 09 '21 at 02:53

1 Answers1

3

As someone already pointed out: Don't expect undefined behavior to be reproducible.

That said, there are a lot of variables. Of course there are the obvious ones (like CPU architecture / 32 bit or 64 bit mode; exact versions of the OS or other software involved (like .NET); etc.) but there also are the more subtle ones. Like how much memory the process is given at a time when it asks for some or even how much it asks for at a time.

So if you check how much virtual memory the process has on different machines before crashing, and the numbers are different, this can be a good reason for it crashing on one system but not the other.

How much memory the process is given at a time can depend on a lot of different factors like how much physical memory is available, how much swap space is available, which swap strategy is used, how the memory is currently allocated, etc. If you tested it on a machine with 16 GB of ram 10 times with it currently using 1 GB of ram for the OS and other applications and the process not crashing, you didn't really reproduce that behavior reliably. You kept the variables relatively constant. It might very well crash all 10 times on a machine with the exact same software but only 4 GB of ram and using 3 GB of it.

UTF-8
  • 2,300
  • 1
  • 9
  • 24