0

I'm talking about the memory flag behavior. I notice that there will be 12 bytes of memory flag ahead of the heap memory I new. After I deleted my heap memory, the flag changed. Like:

auto A = new A;
00 00 00 00 59 1f 12 04 7d bf 00 0c | the heap memory of A |
delete A;
00 00 00 00 59 1f 12 04 4e bf 00 0c | the heap memory of A |

also, some other parts of the memory also changed after delete. Here, I just want to figure out what will happen to the memory after new and delete operation. And how to decode the 12 bytes data ahead of the heap memory. BTW, I'm using VS2017 as my compiling tool.

Mr.Ly
  • 153
  • 10
  • 7
    C++ doesn’t define it because it doesn’t matter. Compilers and runtimes can do basically whatever they want and it may be very different between debug and release. And what do you mean by “stack memory”? – Sami Kuhmonen Dec 12 '19 at 11:38
  • "Stack memory" is where the pointer `A` itself lives. Do you really mean that, or where the heap memory was allocated? – Fire Lancer Dec 12 '19 at 11:46
  • @SamiKuhmonen Looks like he might wants VS2017, saying how *Microsoft* did it is probably fine. Of course there isn't a generic answer and Microsoft could well change it, – Fire Lancer Dec 12 '19 at 11:47
  • 3
    Does this answer your question? [Is the pointer guaranteed to preserve its value after \`delete\` in C++?](https://stackoverflow.com/questions/5002055/is-the-pointer-guaranteed-to-preserve-its-value-after-delete-in-c) – Aykhan Hagverdili Dec 12 '19 at 11:49
  • Basically, I'm solving a memory violation problem. I want to make sure whether the corrupted memory is already released before. To my knowledge, under the 'Release' configuration of VS, it won't erase the heap memory of the instance of A. – Mr.Ly Dec 12 '19 at 12:00
  • As for the heap memory, I took a quick look, at a glance it seems MSVC Release builds will call straight into `RtlAllocateHeap` with the original request size. I didn't try to reverse engineer that, there might be some specific data it pre-fixes before for book keeping. I believe the "Debug" MSVC CRT/Builds also do some extra things. – Fire Lancer Dec 12 '19 at 12:02
  • 2
    So using the Visual C++ compiler you'd like to know if something was released. And your hunch is that there is there may be a clue at the pointers location on the stack. You might want to rephrase your question a bit then, because we've left the land of general C++ questions at that point. – Nathan Cooper Dec 12 '19 at 12:05
  • 2
    As a general rule, you can't determined "already released", because the memory can be immediately reused, e.g. say `delete p; p2 = new A; p == p2;` is possible. If you want to track it for the purpose of "already released before" you could maybe put something in the objects *destructor* that you can trace for debug purposes. "valgrind" is also sometimes useful for that, I don't know if Windows/Microsoft have an equivlant. – Fire Lancer Dec 12 '19 at 12:05
  • Thx for your help. This bug only occurred in my customers' devices. It really kills me. I can only debug this problem by the dump file. – Mr.Ly Dec 12 '19 at 12:06
  • I mean, in some situations, just through the 12 bytes memory ahead of the heap memory location, I can tell that this heap memory is released or not in VS2017. But sometimes, things become a little different, so I want to know what exactly happens to heap memory. – Mr.Ly Dec 12 '19 at 12:12
  • 1
    Well, you can try and figure out if that is the case with experimentation. Visual Studio has a fairly handy "dissassembly" view, so you can step through what `new A` and `delete A` actually does, and see if there is any hints there, but it looked like to me digging into `RtlAllocateHeap`, which will mean reading a lot of assembler. If it is always the `A` object, and you can make a "special build", adding some tracing to the constructor and destructor to log/track it is probably easiest. You can then see if a pointer `A*` got used after free, double deleted, etc. – Fire Lancer Dec 12 '19 at 12:15

0 Answers0