Page Heap verification fails when shrinking allocation using HEAP_REALLOC_IN_PLACE_ONLY - by Chris OBryan

Status : 

 


10
0
Sign in
to vote
ID 804932 Comments
Status Active Workarounds
Type Bug Repros 4
Opened 10/9/2013 6:59:16 AM
Access Restriction Public

Description

I believe this is actually an OS issue (it is in verifier.dll, which I think ships with Windows) but there is no apparent way to file a bug report for a Windows issue.

When using an application with Page Heap enabled and under a debugger, the heap verifier will fail when attempting to free any allocation that was resized (with HEAP_REALLOC_IN_PLACE_ONLY) to require fewer memory pages than the original allocation required. 

This appears to be because when you use HEAP_REALLOC_IN_PLACE_ONLY to shrink an allocation, it doesn't actually free the allocation, it just sets the UserSize to the new value, but the ActualSize is still the same. The heap verification done on the free appears to check if ActualSize is the appropriate size for the current UserSize. Since UserSize is now smaller, but ActualSize didn't change, it triggers a non-continuable verifier stop.

Sign in to post a comment.
Posted by Aleksandr Guteniev on 4/17/2016 at 1:54 AM
GlobalReAlloc / LocalReAlloc are also affected by this issue, if they operate on a memory handle without GMEM_MOVEABLE / LMEM_MOVEABLE specified.

So, the following ATL classes are also affected: CGlobalHeap CGlobalAllocator CLocalHeap CLocalAllocator.

I've seen this issue with BCG pro edit control (CBCGPEditCtrl), it uses GlobalReAlloc with GMEM_DDESHARE.
Posted by SkyLined_ on 7/2/2015 at 5:38 AM
I've found a work around, details are here: http://berendjanwever.blogspot.nl/2015/07/work-around-for-page-heap-reallocate-in.html

It might be possible to create a shim that fixes this issue, but I haven't time to do so myself.
Posted by Chris OBryan on 2/11/2014 at 9:53 AM
Just a ping that this issue is still driving me crazy. It'd be great if you could either say "Yes, this will get fixed." or "No, this will not get fixed." Your current response gives me absolutely no guidance on what to expect. If you tell me it won't be fixed I'll go away :)
Posted by Chris OBryan on 11/5/2013 at 12:57 PM
I'm not exactly sure what the last comment meant, as it gave no 'next step'. Is that saying "Yes, it's a bug. It's in our tracker and will be fixed eventually?" Or is it saying that if I'm not a Microsoft premier customer it won't be fixed?
Posted by Microsoft on 10/21/2013 at 6:32 AM
Thank you for your bug submission. The issue you reported appears to be on a released Windows Product. If this issue is severe, causing critical business situations or blocking your product development or deployment, please go to http://support.microsoft.com or call 1-800-MICROSOFT for assistance. For Microsoft premier customers, please contact your administrator, your Technical Account Manager, or your Microsoft premier account representative.
Other Support links - http://support.microsoft.com/ph/14019#tab13
Posted by Microsoft on 10/10/2013 at 1:36 AM
Thanks for your feedback.

We are rerouting this issue to the appropriate group within the Visual Studio Product Team for triage and resolution. These specialized experts will follow-up with your issue.
Posted by Microsoft on 10/9/2013 at 7:51 AM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)