Skip to content

Proper fix for ObjC async jump to null #58515

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
May 3, 2022

Conversation

kavon
Copy link
Member

@kavon kavon commented Apr 29, 2022

What makes this PR "proper" is that it is not just a revert of the code that caused the regression, but a fix made on top of that.

when two objc async functions are composed with each other,
i.e., f(g()), then the clean-ups for g() would get emitted
at an unexpected time, namely, during the suspension for
the call to f(). This means that using a clean-up to emit
the executor-hop breadcrumb was incorrect. The hop could
appear between a get_async continuation and its matching
await_continuation, which is an unsupported nested suspension.

This commit fixes that by removing the use of the breadcrumb
clean-up in favor of providing that breadcrumb directly to
the result plan, so that it may be emitted later on when the
result plan sees fit.

One nice benefit of this change is that the hops are now
consistently the first instruction in the successor blocks.

Fixes rdar://91502776

@kavon
Copy link
Member Author

kavon commented Apr 29, 2022

@swift-ci please test

@kavon kavon force-pushed the proper-fix-for-jump-to-null branch from 8a59d48 to bd6b3e9 Compare April 29, 2022 01:51
@kavon kavon changed the title [draft] Proper fix for jump to null Proper fix for ObjC async jump to null Apr 29, 2022
@kavon
Copy link
Member Author

kavon commented Apr 29, 2022

@swift-ci please test

@kavon kavon marked this pull request as ready for review April 29, 2022 01:55
@kavon
Copy link
Member Author

kavon commented Apr 29, 2022

I tried to generalize this late ArgumentScope pop using popPreservingValue so it happens for all applies, but that didn't go so well for reasons that are unclear to me. Perhaps it's guaranteed that another scope wrapping the ArgumentScope exists when doing a foreign async call, but that's not the case in general? Here's the failure for that situation:

Assertion failed: (it.Depth <= size_t(End - Begin)), function checkIterator, file DiverseStack.h, line 185.
Please submit a bug report (https://swift.org/contributing/#reporting-bugs) and include the project and the crash backtrace.
Stack dump:
0.	Program arguments: /Users/kavon/work/public/1/build/Ninja-ReleaseAssert+swift-DebugAssert/swift-macosx-arm64/bin/swift-frontend -target arm64-apple-macosx10.9 -module-cache-path /Users/kavon/work/public/1/build/Ninja-ReleaseAssert+swift-DebugAssert/swift-macosx-arm64/swift-test-results/arm64-apple-macosx10.9/clang-module-cache -sdk /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.1.sdk -swift-version 4 -define-availability "SwiftStdlib 9999:macOS 9999, iOS 9999, watchOS 9999, tvOS 9999" -define-availability "SwiftStdlib 5.0:macOS 10.14.4, iOS 12.2, watchOS 5.2, tvOS 12.2" -define-availability "SwiftStdlib 5.1:macOS 10.15, iOS 13.0, watchOS 6.0, tvOS 13.0" -define-availability "SwiftStdlib 5.2:macOS 10.15.4, iOS 13.4, watchOS 6.2, tvOS 13.4" -define-availability "SwiftStdlib 5.3:macOS 11.0, iOS 14.0, watchOS 7.0, tvOS 14.0" -define-availability "SwiftStdlib 5.4:macOS 11.3, iOS 14.5, watchOS 7.4, tvOS 14.5" -define-availability "SwiftStdlib 5.5:macOS 12.0, iOS 15.0, watchOS 8.0, tvOS 15.0" -define-availability "SwiftStdlib 5.6:macOS 12.3, iOS 15.4, watchOS 8.5, tvOS 15.4" -define-availability "SwiftStdlib 5.7:macOS 9999, iOS 9999, watchOS 9999, tvOS 9999" -typo-correction-limit 10 -module-name SomeModule -typecheck -verify -dump-ast -import-objc-header /Users/kavon/work/public/1/swift/test/Constraints/Inputs/imported_type.h /Users/kavon/work/public/1/swift/test/Constraints/invalid_decl_ref.swift
1.	Swift version 5.7-dev (LLVM 25d6ca487ed4dba, Swift 8a59d48094d3ebf)
2.	Compiling with effective version 4.1.50
3.	While evaluating request ModuleImplicitImportsRequest(SomeModule)
4.	While evaluating request ASTLoweringRequest(Lowering AST to SIL for module Foundation)
5.	While silgen emitFunction SIL function "@$ss20_SwiftNewtypeWrapperP10Foundations5Error_p8RawValueRtzrlE19_bridgeToObjectiveCSo7NSErrorCyF".
 for '_bridgeToObjectiveC()' (at /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.1.sdk/usr/lib/swift/Foundation.swiftmodule/arm64e-apple-macos.swiftinterface:6360:21)
Stack dump without symbol names (ensure you have llvm-symbolizer in your PATH or set the environment var `LLVM_SYMBOLIZER_PATH` to point to it):
0  swift-frontend           0x000000010c0a8da8 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) + 56
1  swift-frontend           0x000000010c0a7c88 llvm::sys::RunSignalHandlers() + 128
2  swift-frontend           0x000000010c0a9418 SignalHandler(int) + 304
3  libsystem_platform.dylib 0x00000001b9f144a4 _sigtramp + 56
4  libsystem_pthread.dylib  0x00000001b9efcee0 pthread_kill + 288
5  libsystem_c.dylib        0x00000001b9e37340 abort + 168
6  libsystem_c.dylib        0x00000001b9e36754 err + 0
7  swift-frontend           0x0000000105ba50b8 swift::DiverseStackBase::checkIterator(swift::DiverseStackBase::stable_iterator) const + 168
8  swift-frontend           0x0000000105c81e88 swift::DiverseStackImpl<swift::Lowering::Cleanup>::find(swift::DiverseStackBase::stable_iterator) + 44
9  swift-frontend           0x0000000105b56c4c swift::Lowering::CleanupManager::forwardCleanup(swift::DiverseStackBase::stable_iterator) + 48
10 swift-frontend           0x0000000105b5d0b8 swift::Lowering::ManagedValue::forwardCleanup(swift::Lowering::SILGenFunction&) const + 132
11 swift-frontend           0x0000000105b5d0f4 swift::Lowering::ManagedValue::forward(swift::Lowering::SILGenFunction&) const + 48
12 swift-frontend           0x0000000105b6b0cc swift::Lowering::RValue::forwardAll(swift::Lowering::SILGenFunction&, llvm::SmallVectorImpl<swift::SILValue>&) && + 180
13 swift-frontend           0x0000000105d5af28 swift::Lowering::SILGenFunction::emitReturnExpr(swift::SILLocation, swift::Expr*) + 984
14 swift-frontend           0x0000000105d5e01c (anonymous namespace)::StmtEmitter::visitReturnStmt(swift::ReturnStmt*) + 376

@kavon kavon requested review from meg-gupta and jckarter April 29, 2022 02:05
@kavon
Copy link
Member Author

kavon commented Apr 29, 2022

macOS failures from this batch:

********************
Failed Tests (3):
  Swift-validation(macosx-x86_64) :: compiler_crashers_2_fixed/rdar80704984.swift
  Swift-validation(macosx-x86_64) :: compiler_crashers_2_fixed/rdar80704984_2.swift
  Swift-validation(macosx-x86_64) :: compiler_crashers_2_fixed/rdar80704984_3.swift

Seems to indicate that the error value for calling async ObjC methods that return a YES/NO based on whether the handler was invoked are returning the wrong value on the error path:

Command Output (stderr):
--
clang-13: warning: argument unused during compilation: '-fmodules-cache-path=/Users/ec2-user/jenkins/workspace/swift-PR-macos/branch-main/build/buildbot_incremental/swift-macosx-x86_64/swift-test-results/x86_64-apple-macosx10.9/clang-module-cache' [-Wunused-command-line-argument]
/Users/ec2-user/jenkins/workspace/swift-PR-macos/branch-main/swift/validation-test/compiler_crashers_2_fixed/rdar80704984.swift:19:12: error: CHECK: expected string not found in input
 // CHECK: Domain=d Code=1
           ^
<stdin>:1:1: note: scanning from here
nilError
^

@kavon kavon force-pushed the proper-fix-for-jump-to-null branch from 8476f88 to 31a0fc9 Compare May 2, 2022 23:01
@kavon
Copy link
Member Author

kavon commented May 2, 2022

@swift-ci please test

when two objc async functions are composed with each other,
i.e., f(g()), then the clean-ups for g() would get emitted
at an unexpected time, namely, during the suspension for
the call to f(). This means that using a clean-up to emit
the executor-hop breadcrumb was incorrect. The hop could
appear between a get_async continuation and its matching
await_continuation, which is an unsupported nested suspension.

This commit fixes that by removing the use of the breadcrumb
clean-up in favor of providing that breadcrumb directly to
the result plan, so that it may be emitted later on when the
result plan sees fit.

Fixes rdar://91502776
@kavon kavon force-pushed the proper-fix-for-jump-to-null branch from 31a0fc9 to 814fb42 Compare May 3, 2022 01:21
@kavon
Copy link
Member Author

kavon commented May 3, 2022

@swift-ci please test

@kavon
Copy link
Member Author

kavon commented May 3, 2022

@swift-ci please smoke test and merge

1 similar comment
@kavon
Copy link
Member Author

kavon commented May 3, 2022

@swift-ci please smoke test and merge

@kavon
Copy link
Member Author

kavon commented May 3, 2022

@swift-ci please smoke test and merge

@swift-ci swift-ci merged commit 273a550 into swiftlang:main May 3, 2022
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