GWP‑ASan Based Heap Memory Error Detection and Debugging on Windows

Background

Heap crash dumps are among the hardest to analyse because the faulty code is often invisible at the moment of heap corruption. In the video editing SDK used by the Jianying Pro app, both Use‑after‑free and Buffer‑overflow errors are common, and errors in one module can affect others, making root‑cause localisation extremely challenging.

GWP‑ASan Overview

GWP‑ASan (Google‑Weighted‑Probability AddressSanitizer) is a Google‑led tool that samples memory allocations to catch heap issues. It is based on the classic Electric Fence malloc debugger. Unlike the full‑blown AddressSanitizer (ASan), which instruments every allocation and incurs a 2‑3× performance penalty, GWP‑ASan samples allocations, making its overhead negligible and suitable for production environments.

Use‑after‑free

Buffer‑underflow

Buffer‑overflow

Double‑free

free‑invalid‑address

GWP‑ASan can be deployed on Windows with a non‑intrusive integration that works with the internal APM‑PC platform.

Technical Solution

Monitoring Principle

Create a protected memory pool consisting of n * page‑size pages. Allocatable pages are called Slot , while guard pages are called Guard Page . The layout is Guard Page – Slot – Guard Page – Slot … Guard Page . All Slot s are surrounded by Guard Page s, which are marked non‑readable/non‑writable.

Sample allocation requests. For each request, randomly decide whether to allocate from a free Slot (GWP‑ASan) or let the system allocate normally. When a Slot is used, record the allocation stack.

On free, check whether the address belongs to a protected pool. If it does, free the Slot , record the free stack, and mark the slot as free for future allocations.

Continuously monitor the protected pool. When an access hits a Guard Page , the runtime raises an exception. The exception handler inspects the surrounding metadata to classify the error (UAF, underflow, overflow, double‑free, invalid free) and records the relevant stack traces.

Heap Allocation API

Only the standard malloc/free family is hooked because higher‑level APIs such as HeapAlloc , VirtualAlloc or legacy GlobalAlloc either do not reflect application‑level heap behaviour or are too low‑level for useful stack information.

#include <malloc.h>
void* my_malloc(size_t size) { return malloc(size); }
void my_free(void* p) { free(p); }

The Detours library (Microsoft’s official hooking library) is used to replace the original malloc and free with the GWP‑ASan aware versions. Note that Detours works only with MD‑runtime libraries; MT‑runtime libraries require providing custom allocation function pointers.

Stack Recording and Minidump Integration

GWP‑ASan relies on crash‑monitoring. When an exception occurs, the tool captures the allocation stack, free stack (if any), error type, allocation address, size, and the start/end of the protected pool. These details are serialized with Protobuf and attached to the minidump as a separate gwpasan_stream . The backend then symbolises the stacks using module symbols and presents a complete view of the bug.

Monitoring Flow

Extended Scenarios

In the “no‑crash” mode, GWP‑ASan marks the offending page as readable/writable after reporting the error, allowing the process to continue without a forced termination. This improves user experience while still providing diagnostic data.

Practical Case Studies

Case 1 – Use‑After‑Free in VENotify

The crash occurred in VENotify::notify when a listener was invoked after its owning object had been destroyed. GWP‑ASan identified the error as USE‑AFTER‑FREE and showed the allocation and free stacks, pointing to MediaInfoViewModel as the source of the dangling pointer. The fix was to ensure VENotify::instance().removeListener(this) is called in the destructor and to protect the listener list with a mutex.

Case 2 – Use‑After‑Free in QUICollectionViewItem

GWP‑ASan captured a UAF caused by a QT deleteLater() call that freed a QUICollectionViewItem while its parent still held a reference. Adding a removal of the child from the parent before deletion resolved the issue.

Case 3 – Buffer‑Overflow in VideoSettingsData

The overflow happened when updateKeyframeSeqTimeList accessed m_segmentPtrs[index] without verifying that segmentPtr was non‑null. GWP‑ASan reported the exact line and the valid memory range, leading to a guard against the out‑of‑bounds access.

Case 4 – Buffer‑Overflow in EncryptUtilsImpl

The function EncryptUtilsImpl::getOriginEncryptText treated a binary buffer as a C‑string and called strlen , causing an early termination at a zero byte and subsequent overflow in a memcpy . The fix was to pass the data as a std::string (which carries its length) instead of a raw pointer.

References

Windows memory management functions: https://docs.microsoft.com/en-us/windows/win32/memory/memory-management-functions#general-memory-functions

Comparing memory allocation methods: https://docs.microsoft.com/en-us/windows/win32/memory/comparing-memory-allocation-methods

GWP‑ASan documentation: https://chromium.googlesource.com/chromium/src.git/+/HEAD/docs/gwp_asan.md

GWP‑ASan article: https://sites.google.com/a/chromium.org/dev/Home/chromium-security/articles/gwp-asan