New issue
Advanced search Search tips

Issue 818361 link

Starred by 1 user

Issue metadata

Status: Unconfirmed
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug



Sign in to add a comment

Provide in-the-field "data breakpoints"

Project Member Reported by pkasting@chromium.org, Mar 3 2018

Issue description

To track down heap corruption, it would be helpful to be able to instrument the code to perform the equivalent of data breakpoints in the field, e.g.:

* Mark an object as "write protected"
* If any part of this object is written to, crash and report the callstack
* Provide a scoper (or similar) that can disable write protection, for use in functions that actually need to touch the object

CCing some people who might have more insight on the possibilities here.
 

Comment 1 by mark@chromium.org, Mar 3 2018

This is doable if we ensure that the object is the only thing on the page(s) that it occupies. It’ll require a custom allocator.
brucedawson mentioned using separate pages w/memory protection bits to implement this, and I noted that this may make certain bugs fail to reproduce, e.g. if something is getting trampled on because it's always allocated next to a related object that writes outside its bounds.

Apparently there are real CPU breakpoints we could use here but they're very limited in capability?  I'm very ignorant in this area...

Sign in to add a comment