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
  • #5790
Closed
Open
Issue created Dec 15, 2022 by Derek Bruening@derekbrueningContributor

drmemtrace offline assumes blocks always complete which is broken by asynch thread relocation

drmemtrace's offline instrumentation records one entry at the top of a block and assumes every instruction in that block will then execute. If we have an asynchronous thread relocation (from a synchronous flush, or a reset, or a detach) that finds a safe spot in the middle of the block (any app instr will do; xref a to-be-filed issue on expanding safe spots for client instru; clean calls will do despite their xl8 shortcomings #4912), we'll have not only that promise of all instructions but for a load or store drmemtrace will have recorded its address yet it may not actually execute. Then upon relocation, if it's not detach, the tail block will execute the load/store and duplicate the address. raw2trace will be very confused as it will expect all memrefs in the interrupted block.

One solution could be for DR to provide an event on thread relocation. The client can't tell from the state restore event whether relocation will happen: maybe that could be expanded.

Assignee
Assign to
Time tracking