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
  • #4704
Closed
Open
Issue created Feb 02, 2021 by Derek Bruening@derekbrueningContributor

thread indirect branch tables should be updated after a target-deleted exit

This was discovered in PR #4699 for #4665 (closed): https://github.com/DynamoRIO/dynamorio/pull/4699#discussion_r568753492

There we see one thread resize an IB table and another thread, as expected, exits on a hit in the old table because of a target-deleted pointer we placed there. But, the second thread continues to exit every time it does an IB lookup, still using the old table:

logs/linux.signest.4232.00000000/log.0.4232.html:20911:Exit from fragment deleted but hit in ibl
logs/linux.signest.4232.00000000/log.0.4232.html:20915:Exit from fragment deleted but hit in ibl
logs/linux.signest.4232.00000000/log.0.4232.html:20919:Exit from fragment deleted but hit in ibl
logs/linux.signest.4232.00000000/log.0.4232.html:20923:Exit from fragment deleted but hit in ibl
logs/linux.signest.4232.00000000/log.0.4232.html:20989:Exit from fragment deleted but hit in ibl
logs/linux.signest.4232.00000000/log.0.4232.html:20993:Exit from fragment deleted but hit in ibl
logs/linux.signest.4232.00000000/log.0.4232.html:20997:Exit from fragment deleted but hit in ibl
logs/linux.signest.4232.00000000/log.0.4232.html:21001:Exit from fragment deleted but hit in ibl
logs/linux.signest.4232.00000000/log.0.4232.html:21034:Exit from fragment deleted but hit in ibl
logs/linux.signest.4232.00000000/log.0.4232.html:21038:Exit from fragment deleted but hit in ibl
logs/linux.signest.4232.00000000/log.0.4232.html:21049:Exit from fragment deleted but hit in ibl
logs/linux.signest.4232.00000000/log.0.4232.html:21053:Exit from fragment deleted but hit in ibl
logs/linux.signest.4232.00000000/log.0.4232.html:21057:Exit from fragment deleted but hit in ibl
logs/linux.signest.4232.00000000/log.0.4232.html:21061:Exit from fragment deleted but hit in ibl
logs/linux.signest.4232.00000000/log.0.4232.html:21065:Exit from fragment deleted but hit in ibl
logs/linux.signest.4232.00000000/log.0.4232.html:21079:Exit from fragment deleted but hit in ibl
logs/linux.signest.4232.00000000/log.0.4232.html:21253:Exit from fragment deleted but hit in ibl
logs/linux.signest.4232.00000000/log.0.4232.html:21540:Exit from fragment deleted but hit in ibl
logs/linux.signest.4232.00000000/log.0.4232.html:21573:Exit from fragment deleted but hit in ibl
logs/linux.signest.4232.00000000/log.0.4232.html:21584:Exit from fragment deleted but hit in ibl
logs/linux.signest.4232.00000000/log.0.4232.html:21595:Exit from fragment deleted but hit in ibl
logs/linux.signest.4232.00000000/log.0.4232.html:21793:Exit from fragment deleted but hit in ibl
logs/linux.signest.4232.00000000/log.0.4232.html:21797:Exit from fragment deleted but hit in ibl
logs/linux.signest.4232.00000000/log.0.4232.html:21974:Exit from fragment deleted but hit in ibl
logs/linux.signest.4232.00000000/log.0.4232.html:21978:Exit from fragment deleted but hit in ibl

The code only updates the thread's table pointer on an actual miss: the hit but target-deleted does not trigger it. The code looks for last_exit being marked indirect.

Theoretically, the table might never be updated, and a thread could repeatedly exit on every indirect branch, forever.

The simple fix of marking the target-deleted special linkstub as indirect does fix the problem, but results in an assert later, so it may be simpler to add a check for the special linkstub:

<Application /home/derek/dr/git/build_dbg_tests/suite/tests/bin/linux.signest (31458).  Internal Error: DynamoRIO debug check failure: /home/derek/dr/git/src/core/arch/arch_exports.h:2513 false
(Error occurred @2526 frags)
Assignee
Assign to
Time tracking