Skip to content

[Runtime][Reflection][swift-inspect] Add facilities for tracking and examining backtraces for metadata allocations. #32244

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

Conversation

mikeash
Copy link
Contributor

@mikeash mikeash commented Jun 8, 2020

rdar://problem/63674755

@mikeash mikeash requested review from airspeedswift and tbkka and removed request for airspeedswift June 8, 2020 19:26
@mikeash
Copy link
Contributor Author

mikeash commented Jun 8, 2020

@swift-ci please test

@swift-ci
Copy link
Contributor

swift-ci commented Jun 8, 2020

Build failed
Swift Test OS X Platform
Git Sha - a8e4e5375be6f9bec3ea2c4e81aac27ac4128537

@swift-ci
Copy link
Contributor

swift-ci commented Jun 8, 2020

Build failed
Swift Test Linux Platform
Git Sha - a8e4e5375be6f9bec3ea2c4e81aac27ac4128537

@mikeash mikeash force-pushed the metadata-allocation-backtrace-inspection branch from a8e4e53 to bff26ed Compare June 9, 2020 14:34
@mikeash
Copy link
Contributor Author

mikeash commented Jun 9, 2020

@swift-ci please test

@swift-ci
Copy link
Contributor

swift-ci commented Jun 9, 2020

Build failed
Swift Test OS X Platform
Git Sha - a8e4e5375be6f9bec3ea2c4e81aac27ac4128537

@swift-ci
Copy link
Contributor

swift-ci commented Jun 9, 2020

Build failed
Swift Test Linux Platform
Git Sha - a8e4e5375be6f9bec3ea2c4e81aac27ac4128537

@mikeash mikeash requested a review from compnerd June 10, 2020 14:43
@mikeash mikeash force-pushed the metadata-allocation-backtrace-inspection branch from bff26ed to b89894c Compare June 10, 2020 19:38
@mikeash mikeash force-pushed the metadata-allocation-backtrace-inspection branch from b89894c to 65765ab Compare June 10, 2020 21:07
auto Error = Context->iterateMetadataAllocationBacktraces([&]
(auto AllocationPtr, auto Count, auto Ptrs) {
std::vector<swift_reflection_ptr_t> ConvertedPtrs{&Ptrs[0], &Ptrs[Count]};
Call(AllocationPtr, Count, ConvertedPtrs.data(), ContextPtr);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This now makes me wonder ... ConvertedPtrs.data() is effectively just Ptrs. I think that this call is effectively:

Call(AllocationPtr, Count, Ptrs, ContextPtr);

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's true only when swift_reflection_ptr_t and StoredPointer are the same. When they aren't (as is the case for 32-bit targets) then this is needed to convert the values.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, right, the foreign case. A comment about that would be nice!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You got it!

func symbolicatedLong(inspector: Inspector) -> String {
return ptrs.reversed().enumerated().map {
let indent = String(repeating: " ", count: $0 + 1)
return indent + symbolString(ptr: $1, inspector: inspector)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another option would be to pass indentation to the symbolString and have the two just be different separators.

@@ -67,11 +67,19 @@ class Inspector {
}

func getAddr(symbolName: String) -> swift_addr_t {
let symbol = CSSymbolOwnerGetSymbolWithMangledName(swiftCore, symbolName)
let symbol = CSSymbolOwnerGetSymbolWithMangledName(swiftCore,
"_" + symbolName)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Doesn't this need to take into account the platform before adding a user label prefix? Linux, android, Windows x86_64 and ARM do not use _ (Windows x86, MIPS, and Darwin do).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is Darwin-specific code, as the CS* calls are only available there. Support for other OSes will need a new Inspector implementation that uses the appropriate calls for that OS.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fair enough. Though, it raises the question of whether this should be inside CS* or outside still.

}
print(metadata.name)
if let allocation = metadata.allocation {
if let style = backtraceStyle {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could probably pull this bit out into an @inline(__always) function.


func CSSymbolOwnerGetName(_ sym: CSTypeRef) -> String? {
let name = Sym.CSSymbolOwnerGetName(sym)
return name.map({ String(cString: $0) })
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unnecessary parens

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
return name.map({ String(cString: $0) })
func CSSymbolOwnerGetName(_ sym: CSTypeRef) -> String? {
Sym.CSSymbolOwnerGetName(sym)
.map(String.init(cString:))

@mikeash mikeash force-pushed the metadata-allocation-backtrace-inspection branch from 65765ab to 0a6c805 Compare June 11, 2020 16:44
Copy link
Member

@compnerd compnerd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably should address Ben's comment before merging. Thanks for the iteration on this.

…examining backtraces for metadata allocations.

rdar://problem/63674755
@mikeash mikeash force-pushed the metadata-allocation-backtrace-inspection branch from 0a6c805 to cd624bf Compare June 11, 2020 18:50
@mikeash
Copy link
Contributor Author

mikeash commented Jun 11, 2020

@compnerd I made Ben's suggested change as well. Always a pleasure to get good feedback.

@mikeash
Copy link
Contributor Author

mikeash commented Jun 11, 2020

@swift-ci please test

@swift-ci
Copy link
Contributor

Build failed
Swift Test Linux Platform
Git Sha - bff26ed0d33865e92456d3e390562f21e8e1f303

@swift-ci
Copy link
Contributor

Build failed
Swift Test OS X Platform
Git Sha - bff26ed0d33865e92456d3e390562f21e8e1f303

@airspeedswift
Copy link
Member

To be clear, my comment was mostly for my own idle amusement rather than an important change...

Can't wait to use this!

@mikeash
Copy link
Contributor Author

mikeash commented Jun 12, 2020

@airspeedswift I think you just really hate the return keyword. 😄

@mikeash
Copy link
Contributor Author

mikeash commented Jun 12, 2020

@swift-ci please test

@mikeash mikeash merged commit 6527a21 into swiftlang:master Jun 12, 2020
@airspeedswift
Copy link
Member

@mikeash you're not wrong there

@davezarzycki
Copy link
Contributor

Hi @mikeash – Git bisect has revealed this as breaking my Fedora 32 (linux, x86_64) machine. Can we revert this or commit a quick fix?

FAIL: Swift(linux-x86_64) :: stdlib/symbol-visibility-linux.test-sh (12690 of 13369)
******************** TEST 'Swift(linux-x86_64) :: stdlib/symbol-visibility-linux.test-sh' FAILED ********************
Script:
--
: 'RUN: at line 14';   rm -rf "/home/dave/b/u/t/tools/swift/test-linux-x86_64/stdlib/Output/symbol-visibility-linux.test-sh.tmp" && mkdir -p "/home/dave/b/u/t/tools/swift/test-linux-x86_64/stdlib/Output/symbol-visibility-linux.test-sh.tmp"
: 'RUN: at line 16';   /home/dave/b/u/t/bin/llvm-nm --defined-only --extern-only /home/dave/b/u/t/lib/swift/linux/x86_64/libswiftCore.so    | grep -v -e _ZNSt6vectorIjSaIjEE6insertEN9__gnu_cxx17__normal_iteratorIPKjS1_EERS4_              -e _ZNSt6vectorIjSaIjEE13_M_insert_auxIJRKjEEEvN9__gnu_cxx17__normal_iteratorIPjS1_EEDpOT_              -e _ZNSt6vectorIjSaIjEE13_M_insert_auxIJjEEEvN9__gnu_cxx17__normal_iteratorIPjS1_EEDpOT_              -e _ZNSt6vectorISt10unique_ptrIKvSt8functionIFvPS1_EEESaIS6_EE19_M_emplace_back_auxIJS6_EEEvDpOT_              -e _ZNSt6vectorISt10unique_ptrIKvSt8functionIFvPS1_EEESaIS6_EE17_M_realloc_insertIJS6_EEEvN9__gnu_cxx17__normal_iteratorIPS6_S8_EEDpOT_              -e _ZN9__gnu_cxx12__to_xstringINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEcEET_PFiPT0_mPKS8_P13__va_list_tagEmSB_z              -e _ZZNSt19_Sp_make_shared_tag5_S_tiEvE5__tag              -e _ZSt16__once_call_implISt12_Bind_simpleIFPFvPvEDnEEEvv              -e _ZSt16__once_call_implISt12_Bind_simpleIFPFvPvEPA1_cEEEvv              -e _ZSt16__once_call_implISt12_Bind_simpleIFPFvPvEPA8_cEEEvv              -e _ZSt16__once_call_implISt12_Bind_simpleIFPFvPvEPA24_cEEEvv              -e _ZSt16__once_call_implISt12_Bind_simpleIFPFvPvEPA32_cEEEvv              -e _ZSt16__once_call_implISt12_Bind_simpleIFPFvPvEPA40_cEEEvv              -e _ZSt16__once_call_implISt12_Bind_simpleIFPFvPvEPA88_cEEEvv              -e _ZSt16__once_call_implISt12_Bind_simpleIFPFvPvEPA104_cEEEvv    > /home/dave/b/u/t/tools/swift/test-linux-x86_64/stdlib/Output/symbol-visibility-linux.test-sh.tmp/swiftCore-all.txt
: 'RUN: at line 33';   /home/dave/b/u/t/bin/llvm-nm --defined-only --extern-only --no-weak /home/dave/b/u/t/lib/swift/linux/x86_64/libswiftCore.so > /home/dave/b/u/t/tools/swift/test-linux-x86_64/stdlib/Output/symbol-visibility-linux.test-sh.tmp/swiftCore-no-weak.txt
: 'RUN: at line 34';   diff -u /home/dave/b/u/t/tools/swift/test-linux-x86_64/stdlib/Output/symbol-visibility-linux.test-sh.tmp/swiftCore-all.txt /home/dave/b/u/t/tools/swift/test-linux-x86_64/stdlib/Output/symbol-visibility-linux.test-sh.tmp/swiftCore-no-weak.txt
: 'RUN: at line 36';   /home/dave/b/u/t/bin/llvm-nm --defined-only --extern-only /home/dave/b/u/t/lib/swift/linux/x86_64/libswiftRemoteMirror.so    | grep -v -e _ZNSt6vectorIjSaIjEE6insertEN9__gnu_cxx17__normal_iteratorIPKjS1_EERS4_              -e _ZNSt6vectorIjSaIjEE13_M_insert_auxIJRKjEEEvN9__gnu_cxx17__normal_iteratorIPjS1_EEDpOT_              -e _ZNSt6vectorIjSaIjEE13_M_insert_auxIJjEEEvN9__gnu_cxx17__normal_iteratorIPjS1_EEDpOT_              -e _ZNSt6vectorISt10unique_ptrIKvSt8functionIFvPS1_EEESaIS6_EE19_M_emplace_back_auxIJS6_EEEvDpOT_              -e _ZNSt6vectorISt10unique_ptrIKvSt8functionIFvPS1_EEESaIS6_EE17_M_realloc_insertIJS6_EEEvN9__gnu_cxx17__normal_iteratorIPS6_S8_EEDpOT_              -e _ZN9__gnu_cxx12__to_xstringINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEcEET_PFiPT0_mPKS8_P13__va_list_tagEmSB_z              -e _ZZNSt19_Sp_make_shared_tag5_S_tiEvE5__tag              -e _ZSt16__once_call_implISt12_Bind_simpleIFPFvPvEDnEEEvv              -e _ZSt16__once_call_implISt12_Bind_simpleIFPFvPvEPA1_cEEEvv              -e _ZSt16__once_call_implISt12_Bind_simpleIFPFvPvEPA8_cEEEvv              -e _ZSt16__once_call_implISt12_Bind_simpleIFPFvPvEPA24_cEEEvv              -e _ZSt16__once_call_implISt12_Bind_simpleIFPFvPvEPA32_cEEEvv              -e _ZSt16__once_call_implISt12_Bind_simpleIFPFvPvEPA40_cEEEvv              -e _ZSt16__once_call_implISt12_Bind_simpleIFPFvPvEPA88_cEEEvv              -e _ZSt16__once_call_implISt12_Bind_simpleIFPFvPvEPA104_cEEEvv    > /home/dave/b/u/t/tools/swift/test-linux-x86_64/stdlib/Output/symbol-visibility-linux.test-sh.tmp/swiftRemoteMirror-all.txt
: 'RUN: at line 53';   /home/dave/b/u/t/bin/llvm-nm --defined-only --extern-only --no-weak /home/dave/b/u/t/lib/swift/linux/x86_64/libswiftRemoteMirror.so > /home/dave/b/u/t/tools/swift/test-linux-x86_64/stdlib/Output/symbol-visibility-linux.test-sh.tmp/swiftRemoteMirror-no-weak.txt
: 'RUN: at line 54';   diff -u /home/dave/b/u/t/tools/swift/test-linux-x86_64/stdlib/Output/symbol-visibility-linux.test-sh.tmp/swiftRemoteMirror-all.txt /home/dave/b/u/t/tools/swift/test-linux-x86_64/stdlib/Output/symbol-visibility-linux.test-sh.tmp/swiftRemoteMirror-no-weak.txt
--
Exit Code: 1

Command Output (stdout):
--
--- /home/dave/b/u/t/tools/swift/test-linux-x86_64/stdlib/Output/symbol-visibility-linux.test-sh.tmp/swiftRemoteMirror-all.txt  2020-06-13 07:16:26.364449497 -0400
+++ /home/dave/b/u/t/tools/swift/test-linux-x86_64/stdlib/Output/symbol-visibility-linux.test-sh.tmp/swiftRemoteMirror-no-weak.txt 2020-06-13 07:16:26.384449714 -0400
@@ -1,9 +1,3 @@
-000000000008f880 V _ZTCNSt3__118basic_stringstreamIcNS_11char_traitsIcEENS_9allocatorIcEEEE0_NS_13basic_istreamIcS2_EE
-000000000008f808 V _ZTCNSt3__118basic_stringstreamIcNS_11char_traitsIcEENS_9allocatorIcEEEE0_NS_14basic_iostreamIcS2_EE
-000000000008f8d0 V _ZTCNSt3__118basic_stringstreamIcNS_11char_traitsIcEENS_9allocatorIcEEEE16_NS_13basic_ostreamIcS2_EE
-000000000008f7b8 V _ZTTNSt3__118basic_stringstreamIcNS_11char_traitsIcEENS_9allocatorIcEEEE
-000000000008f920 V _ZTVNSt3__115basic_stringbufIcNS_11char_traitsIcEENS_9allocatorIcEEEE
-000000000008f740 V _ZTVNSt3__118basic_stringstreamIcNS_11char_traitsIcEENS_9allocatorIcEEEE
 000000000002bbd0 T swift_reflection_addImage
 000000000002b7e0 T swift_reflection_addReflectionInfo
 0000000000031380 T swift_reflection_allocationMetadataPointer

--


@davezarzycki
Copy link
Contributor

It looks like this test was added recently but nothing (as far as I can tell) in the Swift build system forces the GNU C++ standard library to be used, so if the host compiler defaults to LLVM's C++ library, then this test is at risk of failing.

I've also been using LLVM's C++ standard library for a long time, so this breakage is unfortunate.

@davezarzycki
Copy link
Contributor

@mikeash – So I'm not a python expert. How hard would it be to get the Swift lit setup to run ldd against the stdlib and see which C++ runtime is being used so that we can add a REQUIRES: libstdc++ to the test?

@davezarzycki
Copy link
Contributor

CC: @compnerd because he wrote the brittle test.

@compnerd
Copy link
Member

There’s definitely some assumptions around the C++ runtime on different platforms. I don’t think that the test would fail on libc++ though. The filtering there is to work around the libstdc++ forcing exported symbols.

The diff appears to indicate that you’re building with RTTI? The standard disables RTTI which I think is causing some undesired (weak) exports of the type information.

@davezarzycki
Copy link
Contributor

Weird. My setup is not explicitly disabling RTTI and I wouldn’t knowingly enable RTTI. I’d wager that either the runtime isn’t consistently disabling RTTI or this is pull request is exposing a latent bug in LLVM’s libc++.

@tbkka
Copy link
Contributor

tbkka commented Jun 15, 2020

If we add the symbols you found to that test, would that make the test pass for both C++ libraries?

@davezarzycki
Copy link
Contributor

@tbkka – I'd imagine so, but I didn't write the test and I'm not sure if that is the "right" solution.

@compnerd – What do you think?

@compnerd
Copy link
Member

Yeah, that’s probably a good way to get the tests passing again. Though, we should figure out why libc++ is injecting the vtables in the runtime (sounds like we’re messing up some flags).

davezarzycki added a commit to davezarzycki/swift that referenced this pull request Jun 16, 2020
Pull request swiftlang#32244 introduced the use of `std::stringstream` but that
causes vtables to be generated and we don't want that.
@davezarzycki
Copy link
Contributor

davezarzycki commented Jun 16, 2020

So I debugged this a bit. The problem is std::stringstream. This is probably some kind of bug in LLVM's C++ standard library, but I'm not enough of a C++ expert to file a bug. I'm going to workaround this using snprintf. See pull request: #32406

@davezarzycki
Copy link
Contributor

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.

6 participants