Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • D dynamorio
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 1,467
    • Issues 1,467
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 44
    • Merge requests 44
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Package Registry
    • Infrastructure Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • DynamoRIO
  • dynamorio
  • Issues
  • #4588
Closed
Open
Issue created Dec 06, 2020 by Derek Bruening@derekbrueningContributor

Windows memory query to find the size fails on weird AllocationBase behavior on GA Server16

This was hit in Dr. Memory https://github.com/DynamoRIO/drmemory/issues/2328

The details are here: https://github.com/DynamoRIO/drmemory/issues/2328#issuecomment-739454412

Basically we have a case where the AllocationBase goes up and then drops back to an original value, and the query loop inside query_memory_internal() (which implements dr_query_memory()) fails when the AllocationBase doesn't match. This causes multiple address space walks in Dr. Memory to fail early, causing Umbra init to mess up, and leak scanning to assert.

Assignee
Assign to
Time tracking