Open swift-ci opened 3 years ago
@swift-ci create
Comment by 3405691582 (JIRA)
I think #38386 fixes this – I am not seeing this problem recur at HEAD now on OpenBSD.
Yeah, that should fix it, specifically this commit: https://github.com/apple/swift/pull/38386/commits/930c72aee2687224f606dbba95c7f2b30c7340f7
Environment
Linux (clean build and checkout at HEAD) OpenBSD (with pr apple/swift-corelibs-libdispatch#559)Additional Detail from JIRA
| | | |------------------|-----------------| |Votes | 0 | |Component/s | | |Labels | Bug, Concurrency | |Assignee | None | |Priority | Medium | md5: 989fbed04827f8361dfc98879fa3bf00Issue Description:
Presumably all Dispatch-based Concurrency binaries built at HEAD currently crash at
_dispatch_queue_no_activate
.Easy reproduction on Linux is to execute one of the Concurrency tests, e.g.,
./llvm-project/llvm/utils/lit/lit.py -sv --param swift_site_config=./build/Ninja-DebugAssert/swift-linux-x86_64/test-linux-x86_64/lit.site.cfg swift/test/Concurrency/Runtime/async_let_throws.swift
. Test will build./build/Ninja-DebugAssert/swift-linux-x86_64/test-linux-x86_64/Concurrency/Runtime/Output/async_let_throws.swift.tmp/a.out
and crash with SIGILL.I am not completely confident why exactly this is the case but I have some suspicions as to what might be going awry based on some debugging. See e.g. (lightly redacted) GDB session
Observe how
do_kind
– aconst char *
is being interpreted as a function pointer here. Swift tries to manufacture Dispatch-compatible objects when it uses Dispatch to implement Concurrency features (see Task.cpp#L257) . This mismatch seems to suggest there is some variation in the way the object is being laid out on the Swift side versus how it is interpreted on the Dispatch side.However, I suspect that this is not taking to consideration that part of the object header in Dispatch is defined differently when
USE_OBJC
is 1 or 0 (see src/objc_internal.h#L174 – what also may be relevant is that there is a similar deviation whenOS_OBJECT_HAVE_OBJC1
is 1 or 0 (see src/object_internal.h#L436).(The main reason why I am not 100% sure that this is the root cause of the crash is that I am missing is how
_dispatch_queue_no_activate
is reached if the suspect vtable has0x0
fordq_activate
– but the above analysis may nonetheless be relevant to a potential fix. I have not experimented in trying to reorder the metadata inTask.cpp
to try and bring the layouts on Swift/Dispatch into alignment. I suspect perhaps this was not tripped earlier because the code as it stands at HEAD will align correctly with the ObjC-enabled branch)