0

I'm trying to enable page heap for a small application using GFlags but for some reason it doesn't work.

I've written a small C++ application that all it does is corrupt the heap memory:

int* a;
a= (int*)malloc(1);
*a= 8888800;
return 0;

When running this code the application does not crash. But with page heap enabled I would expect it to, at the third line.

I suspect I didn't not activate GFlags correctly but can't figure out the problem. After running the GFlags exe in the image file tab I copied the path to my exe and marked the enable page heap and stop on exception options. I checked in the CMD and saw the page heap was enabled. What could be the problem?

Thomas Weller
  • 55,411
  • 20
  • 125
  • 222
  • 1
    You have *undefined behavior*. What happens when you have UB is, well, *undefined*, and you can't predict it. In some cases it might seem to work fine, on other it will cause crashes, and sometime you might even get [nasal demons](http://catb.org/jargon/html/N/nasal-demons.html). This is also a very good example of why one should not use `malloc` in C++. – Some programmer dude Mar 15 '17 at 08:37
  • So is there any way I can prove that GFlags works and will work out there for our product? –  Mar 15 '17 at 09:17
  • @Someprogrammerdude: isn't undefined behavior something that abuses the language? IMHO this is not a C++ language abuse, because the compiler knows exactly what to do. So the question is how WIndows handles this case with its memory management. The compiler cannot know how many bytes are allocated by `malloc()`. If the parameter `1` means 1 kb, then everything is fine. – Thomas Weller Mar 17 '17 at 16:50
  • If you tell compiler that it should write four bytes to an array of one byte, isn't that kind of abuse of the language? Going out of bounds of any allocated memory is UB. And the argument to `malloc` is the size ***in bytes***. The compiler can not read minds, and the standard library less so. – Some programmer dude Mar 17 '17 at 18:17
  • @Someprogrammerdude: this is not about an array, it's about a pointer. IMHO it's not an abuse of language, because this is more or less language independent (you can to the same in assembler instead of C++). It's an abuse of memory management. But memory management (I can only speak for Winodws) has a quite good set of rules, e.g. to throw an access violation exception instead of causing undefined behavior (which could be anything like demons). And yes, of course the argument to malloc() is in bytes. But the compiler cannot know that, so if it were in kB hypothetically, the code would work. – Thomas Weller Mar 20 '17 at 10:47

1 Answers1

1

Page heap means that there's a protected page after the page where your variable is in. This also means that you have to access memory in that protected page to let it crash. You're not writing enough data to reach the end of a page.

Something like

int* a;
a= (int*)malloc(1);
*(a+4096)= 8888800;
return 0;

should work (not tested).

Keep in mind, that every single variable on the heap will require 8 kB of memory when page heap is turned on: 4 kB for the accessible page where the variable is in and 4 kB for the protected page that follows.

So all in all, page heap is not a good idea for applications in production but maybe for small test applications. where you need to nail down a buffer overflow (or underrun).

Thomas Weller
  • 55,411
  • 20
  • 125
  • 222