Skip to content

[20210107][Frontend] Only compile modules if not already finalized #3104

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Jul 17, 2021

Conversation

bnbarham
Copy link

@bnbarham bnbarham commented Jul 16, 2021

Cherry-pick https://reviews.llvm.org/D105328


It was possible to re-add a module to a shared in-memory module cache
when search paths are changed. This can eventually cause a crash if the
original module is referenced after this occurs.

  1. Module A depends on B
  2. B exists in two paths C and D
  3. First run only has C on the search path, finds A and B and loads
    them
  4. Second run adds D to the front of the search path. A is loaded and
    contains a reference to the already compiled module from C. But
    searching finds the module from D instead, causing a mismatch
  5. B and the modules that depend on it are considered out of date and
    thus rebuilt
  6. The recompiled module A is added to the in-memory cache, freeing
    the previously inserted one

This can never occur from a regular clang process, but is very easy to
do through the API - whether through the use of a shared case or just
running multiple compilations from a single CompilerInstance. Update
the compilation to return early if a module is already finalized so that
the pre-condition in the in-memory module cache holds.

Resolves rdar://78180255

Differential Revision: https://reviews.llvm.org/D105328

It was possible to re-add a module to a shared in-memory module cache
when search paths are changed. This can eventually cause a crash if the
original module is referenced after this occurs.
  1. Module A depends on B
  2. B exists in two paths C and D
  3. First run only has C on the search path, finds A and B and loads
     them
  4. Second run adds D to the front of the search path. A is loaded and
     contains a reference to the already compiled module from C. But
     searching finds the module from D instead, causing a mismatch
  5. B and the modules that depend on it are considered out of date and
     thus rebuilt
  6. The recompiled module A is added to the in-memory cache, freeing
     the previously inserted one

This can never occur from a regular clang process, but is very easy to
do through the API - whether through the use of a shared case or just
running multiple compilations from a single `CompilerInstance`. Update
the compilation to return early if a module is already finalized so that
the pre-condition in the in-memory module cache holds.

Resolves rdar://78180255

Differential Revision: https://reviews.llvm.org/D105328
@bnbarham bnbarham requested a review from akyrtzi July 16, 2021 23:03
@bnbarham
Copy link
Author

@swift-ci please test

@bnbarham bnbarham merged commit e1a68e2 into swiftlang:apple/stable/20210107 Jul 17, 2021
@bnbarham bnbarham deleted the cherry-cache-uaf branch July 17, 2021 02:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants