On Wed, Oct 4, 2017 at 5:32 PM, Jim Ingham <[email protected]> wrote:
> This also sounds like the sort of thing that is internal to swift and > should have been caught by testing on the swift side before it got to > lldb. But maybe I'm missing something... I completely agree. I did in fact catch a similar instance of an issue during the testing and PR CI builds. I was speaking with Chris Bieneman about this earlier, I think that we should just fleh out the `-objc-interop` path on Linux so that we can have the full coverage on both targets. The thing about the failing tests is that they are all ObjC interop related. > > Jim > > > > On Oct 4, 2017, at 4:34 PM, Saleem Abdulrasool <[email protected]> > wrote: > > > > > > On Wed, Oct 4, 2017 at 3:52 PM Jim Ingham <[email protected]> wrote: > > Here's where we are asserting: > > > > * thread #1, queue = 'com.apple.main-thread', stop reason = signal > SIGABRT > > frame #0: 0x00007fff713bffce libsystem_kernel.dylib`__pthread_kill > + 10 > > frame #1: 0x00007fff714fd150 libsystem_pthread.dylib`pthread_kill + > 333 > > frame #2: 0x00007fff7131c32a libsystem_c.dylib`abort + 127 > > frame #3: 0x00007fff712e4380 libsystem_c.dylib`__assert_rtn + 320 > > frame #4: 0x000000010a29cae7 _lldb.so`swift:: > TargetClassMetadata<swift::External<swift::RuntimeTarget<8u> > > >::getDescription(this=0x00007f8500e05bc0) const at Metadata.h:1469 > > * frame #5: 0x000000010a298ef1 _lldb.so`swift::remote:: > MetadataReader<swift::External<swift::RuntimeTarget<8u> >, (anonymous > namespace)::RemoteASTTypeBuilder>::readAddressOfNominalTypeDescriptor(this=0x00007f8500e05a00, > metadata=0x00007ffeeee83bd0, skipArtificialSubclasses=false) at > MetadataReader.h:1192 > > frame #6: 0x000000010a291d63 _lldb.so`swift::remote:: > MetadataReader<swift::External<swift::RuntimeTarget<8u> >, (anonymous > namespace)::RemoteASTTypeBuilder>::readNominalTypeFromMetadata(this=0x00007f8500e05a00, > origMetadata=swift::remote::MetadataReader<swift:: > External<swift::RuntimeTarget<8> >, (anonymous namespace):: > RemoteASTTypeBuilder>::MetadataRef @ 0x00007ffeeee83bf0, > skipArtificialSubclasses=false) at MetadataReader.h:1308 > > frame #7: 0x000000010a28e81d _lldb.so`swift::remote:: > MetadataReader<swift::External<swift::RuntimeTarget<8u> >, (anonymous > namespace)::RemoteASTTypeBuilder>::readTypeFromMetadata(this=0x00007f8500e05a00, > MetadataAddress=4294976120, skipArtificialSubclasses=false) at > MetadataReader.h:693 > > frame #8: 0x000000010a28b6a9 _lldb.so`(anonymous namespace):: > RemoteASTContextConcreteImpl<swift::External<swift::RuntimeTarget<8u> > > >::getTypeForRemoteTypeMetadata(this=0x00007f8500e059f0, metadata=(Data = > 4294976120), skipArtificial=false) at RemoteAST.cpp:1031 > > frame #9: 0x000000010a264a2d _lldb.so`swift::remoteAST:: > RemoteASTContext::getTypeForRemoteTypeMetadata(this=0x00007f85009fa4f0, > address=(Data = 4294976120), skipArtificial=false) at RemoteAST.cpp:1115 > > frame #10: 0x000000010bfcc877 _lldb.so`lldb_private:: > SwiftLanguageRuntime::MetadataPromise::FulfillTypePromise(this=0x00007f8500e059b0, > error=0x0000000000000000) at SwiftLanguageRuntime.cpp:1424 > > frame #11: 0x000000010bfd7a99 _lldb.so`lldb_private:: > SwiftLanguageRuntime::GetDynamicTypeAndAddress_Archetype(this=0x00007f8500e042c0, > in_value="self", use_dynamic=eDynamicDontRunTarget, > class_type_or_name=0x00007ffeeee861d8, > address=0x00007ffeeee861c0) at SwiftLanguageRuntime.cpp:2276 > > frame #12: 0x000000010bfdb137 _lldb.so`lldb_private:: > SwiftLanguageRuntime::GetDynamicTypeAndAddress(this=0x00007f8500e042c0, > in_value="self", use_dynamic=eDynamicDontRunTarget, > class_type_or_name=0x00007ffeeee861d8, > address=0x00007ffeeee861c0, value_type=0x00007ffeeee861b8) at > SwiftLanguageRuntime.cpp:2607 > > frame #13: 0x000000010c3da132 _lldb.so`lldb_private:: > ValueObjectDynamicValue::UpdateValue(this=0x00007f8501d8e600) at > ValueObjectDynamicValue.cpp:168 > > frame #14: 0x000000010b7d6cc9 _lldb.so`lldb_private::ValueObject:: > UpdateValueIfNeeded(this=0x00007f8501d8e600, update_format=false) at > ValueObject.cpp:211 > > frame #15: 0x000000010b7d977b _lldb.so`lldb_private:: > ValueObject::GetError(this=0x00007f8501d8e600) at ValueObject.cpp:404 > > frame #16: 0x000000010c8cd424 _lldb.so`lldb_private:: > SwiftUserExpression::ScanContext(this=0x00007f8500d522f0, > exe_ctx=0x00007ffeeee89548, err=0x00007ffeeee877b0) at > SwiftUserExpression.cpp:185 > > frame #17: 0x000000010c8cf762 _lldb.so`lldb_private:: > SwiftUserExpression::Parse(this=0x00007f8500d522f0, > diagnostic_manager=0x00007ffeeee88768, > exe_ctx=0x00007ffeeee89548, execution_policy= > eExecutionPolicyOnlyWhenNeeded, keep_result_in_memory=true, > generate_debug_info=false, line_offset=0) at SwiftUserExpression.cpp:450 > > frame #18: 0x000000010bf36302 _lldb.so`lldb_private:: > UserExpression::Evaluate(exe_ctx=0x00007ffeeee89548, > options=0x00007f84f9a6d950, expr=(Data = "self", Length = 4), prefix=(Data > = 0x0000000000000000, Length = 0), result_valobj_sp=lldb_private::ConstString > @ , error=0x00007ffeeee894d0, line_offset=0, fixed_expression="", > jit_module_sp_ptr=<parent is NULL>) at UserExpression.cpp:247 > > frame #19: 0x000000010c21de19 _lldb.so`lldb_private::Target: > :EvaluateExpression(this=0x00007f84f807c000, expr=(Data = "self", Length > = 4), exe_scope=0x00007f84f9c020a0, result_valobj_sp=lldb_private::ConstString > @ , options=0x00007f84f9a6d950, fixed_expression="") at Target.cpp:2297 > > frame #20: 0x000000010373eedd _lldb.so`lldb::SBFrame:: > EvaluateExpression(this=0x00007f84f9a6d840, expr="self", > options=0x00007f84f7788b10) at SBFrame.cpp:1305 > > frame #21: 0x00000001038fe4f9 _lldb.so`_wrap_SBFrame_ > EvaluateExpression__SWIG_3((null)=0x0000000000000000, > args=0x00000001017b9c80) at LLDBWrapPython.cpp:26687 > > frame #22: 0x000000010385113e _lldb.so`_wrap_SBFrame_ > EvaluateExpression(self=0x0000000000000000, args=0x00000001017b9c80) at > LLDBWrapPython.cpp:26735 > > <Lots of Python frames omitted> > > > > This is all inside the swift::remoteAST & swift::remote classes. I > wonder if you changed something the remoteAST code was implicitly relying > on? > > > > Interesting. So, it’s failing to read the address of the nominal type > descriptor (MetadataReader.h:1192). It is looking at a class and reads the > nominal type descriptor. That changed to an absolute pointer. It is now a > ConstTargetMetadataPointer<Runtime, TargetNominalTypeDescriptor>. The > assertion which is failing is that the bottom bit is set for the metadata > which cannot be true anymore as it is not an offset and we directly access > it. We do control the alignment so it is possible to restore that, but at > the same time, that is also used as an ISA selector on some targets (e.g. > ARM). That can be pretty confusing. I think that the simplest thing in > the short term is to remove that assertion. I’ll try that and upload a > change. > > > > > > Jim > > > > > > > On Oct 4, 2017, at 11:54 AM, Saleem Abdulrasool via swift-lldb-dev < > [email protected]> wrote: > > > > > > Just for those interested, this does not reproduce on a Linux host. > This seems to be specific to a macOS host. > > > > > > On Wed, Oct 4, 2017 at 11:00 AM Saleem Abdulrasool < > [email protected]> wrote: > > > On Wed, Oct 4, 2017 at 10:57 AM Adrian Prantl <[email protected]> > wrote: > > > > > >> On Oct 4, 2017, at 10:54 AM, Saleem Abdulrasool < > [email protected]> wrote: > > >> > > >> Does the lldb test suite not run as part of the CI builds? > > > > > > AFAIK it is currently not running as part of pull request testing. > (Which is obviously not ideal). > > > > > > Getting some minimal coverage would be nice. But I think that would > be outside of the scope of my changes. That can also be done subsequently > to improve coverage. > > > > > > > > >> > > >> It seems that in the mean time, at least two new regressions have > been introduced into the Windows build. That does make me slightly > hesistent since it seems that it is more likely that other regressions will > get introduced. > > >> > > >> In any case, I’m doing a build of lldb and will look into this once > the build completes. Hopefully the failures also reproduces on Linux. > > > > > > Thanks! Jim ([email protected]) should be able to help you with any > LLDB-related questions. > > > > > > Awesome! I might have to take you up on that offer :) > > > > > > > > > -- adrian > > > > > >> > > >> Saleem > > >> > > >> On Wed, Oct 4, 2017 at 10:36 AM Adrian Prantl <[email protected]> > wrote: > > >> > > >>> On Oct 4, 2017, at 10:33 AM, Saleem Abdulrasool < > [email protected]> wrote: > > >>> > > >>> > > >>> On Wed, Oct 4, 2017 at 10:29 AM Jim Ingham <[email protected]> > wrote: > > >>> Nothing significant has changed on the lldb side but we're getting a > bunch of tests asserting here: > > >>> > > >>> 21:01:25 > > >>> Assertion failed: (isTypeMetadata()), function getDescription, file > /Users/buildslave/jenkins/workspace/lldb-master-tools_ > RA/swift/include/swift/Runtime/Metadata.h, line 1469. > > >>> > > >>> Anybody got any clues of what might have changed on the Swift side > to start tripping this assertion? > > >>> > > >>> The type metadata layout has changed. The value witness table > reference is no longer an offset but rather a complete pointer. > > >>> > > >>> It is possible that lldb needs to be updated for that? > > >> > > >> That sounds plausible. Would it be possible to revert the commit > until a solution is found? You can easily build lldb by checking it out > next to swift and adding "-l" to the build script. > > >> > > >> -- adrian > > >> > > >>> > > >>> > > >>> Jim > > >>> > > >>> > > >>> > > >>> > On Oct 3, 2017, at 9:38 PM, [email protected] wrote: > > >>> > > > >>> > [FAILURE] oss-lldb-incremental-osx [#230] > > >>> > > > >>> > Build URL: https://ci.swift.org/job/oss- > lldb-incremental-osx/230/ > > >>> > Project: oss-lldb-incremental-osx > > >>> > Date of build: Tue, 03 Oct 2017 22:55:41 -0500 > > >>> > Build duration: 43 min > > >>> > Identified problems: > > >>> > > > >>> > • Regression test failed: This build failed because a > regression test in the test suite FAILed. Below is a list of all errors: > > >>> > • Indication 1 > > >>> > • Assertion failure: This build failed because of an > assertion failure. Below is a list of all errors in the build log: > > >>> > • Indication 1 > > >>> > > > >>> > Changes > > >>> > > > >>> > • Commit 99e395b7e3f89b1f6f2874296a37add58aece6d6 by github: > > >>> > [APINotes] Add 'RetainCountConvention' (#133) > > >>> > > > >>> > • edit: include/clang/APINotes/Types.h > > >>> > • edit: lib/APINotes/APINotesWriter.cpp > > >>> > • edit: test/APINotes/Inputs/roundtrip.apinotes > > >>> > • edit: lib/APINotes/APINotesYAMLCompiler.cpp > > >>> > • edit: lib/APINotes/APINotesReader.cpp > > >>> > • add: test/APINotes/retain-count-convention.m > > >>> > • edit: test/APINotes/Inputs/Frameworks/SimpleKit. > framework/Headers/SimpleKit.h > > >>> > • edit: lib/Sema/SemaAPINotes.cpp > > >>> > • edit: test/APINotes/yaml-roundtrip.c > > >>> > • edit: test/APINotes/Inputs/Frameworks/SimpleKit. > framework/Headers/SimpleKit.apinotes > > >>> > > > >>> > • Commit 969421f5ac164d98f4650ae0f1a4fd10409cabad by > aprantl: > > >>> > [DebugInfo] Handle endianness when moving debug info for split > integer > > >>> > > > >>> > • edit: lib/CodeGen/SelectionDAG/LegalizeTypes.cpp > > >>> > • add: test/CodeGen/PowerPC/debuginfo-split-int.ll > > >>> > > > >>> > • Commit e77f221279851c2406e824e75ae8904ba7d89ab5 by > aprantl: > > >>> > Add a manpage for llvm-dwarfdump. > > >>> > > > >>> > • edit: docs/CMakeLists.txt > > >>> > • edit: docs/CommandGuide/llvm-dwarfdump.rst > > >>> > > > >>> > • Commit 2850e656c89ac7c4837a01b57c52c036e88c81f7 by > jingham: > > >>> > This test is passing everywhere I can see, so I'm removing the > xfail, to > > >>> > > > >>> > • edit: packages/Python/lldbsuite/ > test/functionalities/thread/exit_during_step/TestExitDuringStep.py > > >>> > > > >>> > • Commit 7e6b564bf551e1ccd4eaff2824d87dd89b71a686 by > dgregor: > > >>> > Add fixed crasher from rdar://problem/33575781 > > >>> > > > >>> > • add: validation-test/compiler_ > crashers_2_fixed/0125-rdar33575781.swift > > >>> > > > >>> > • Commit 086c12114dfdff1b7b7179a6052f43a8d73557ed by > compnerd: > > >>> > IRGen: switch to absolute pointers for nominal type descriptors > > >>> > > > >>> > • edit: include/swift/Runtime/Metadata.h > > >>> > • edit: lib/IRGen/ConstantBuilder.h > > >>> > • edit: stdlib/public/runtime/Metadata.cpp > > >>> > • edit: unittests/runtime/Metadata.cpp > > >>> > • edit: lib/IRGen/GenMeta.cpp > > >>> > • edit: stdlib/public/runtime/ > ProtocolConformance.cpp > > >>> > • edit: test/IRGen/foreign_types.sil > > >>> > • edit: test/IRGen/objc_attr_NSManaged.sil > > >>> > • edit: include/swift/Remote/MetadataReader.h > > >>> > • edit: stdlib/public/runtime/Casting.cpp > > >>> > • edit: test/IRGen/field_type_vectors.sil > > >>> > > > >>> > • Commit 2645a6a4b9cf2df212da6db9a41b3363ff44de56 by > dgregor: > > >>> > [Deserialization] Configure protocol before loading requirement > > >>> > > > >>> > • add: test/Serialization/recursive_ > protocol_merge.swift > > >>> > • add: test/Serialization/Inputs/ > recursive_protocol_merge_b.swift > > >>> > • add: test/Serialization/Inputs/ > recursive_protocol_merge_a.swift > > >>> > • edit: lib/Serialization/Deserialization.cpp > > >>> > > > >>> > • Commit 610aa582ce9647ad377812355d8ae36ec5cf0e31 by > shajrawi: > > >>> > Fixes (another) IRGen compiler crash caused by the new large types > ABI > > >>> > > > >>> > • edit: test/IRGen/big_types_corner_cases.sil > > >>> > • edit: lib/IRGen/LoadableByAddress.cpp > > >>> > > > >>> > • Commit 77554c1ae2b3b2de16b803409d9f7085ad186562 by ghoare: > > >>> > [Stats] Fix typo. > > >>> > > > >>> > • edit: lib/Basic/Statistic.cpp > > >>> > > > >>> > • Commit 0e5b982d2561bc7c102e2abe984e19241735aaa2 by ghoare: > > >>> > [Stats] Only use input filename, not mangled path, in stats file > name. > > >>> > > > >>> > • edit: lib/Basic/Statistic.cpp > > >>> > > > >>> > • Commit c1a4bb490bcdf8d20c962ab43249eaee44ee037f by github: > > >>> > [test] Define out part of this test that's crashing on Linux > (#12258) > > >>> > > > >>> > • edit: test/ClangImporter/clang_builtins.swift > > >>> > > >>> -- > > >>> Saleem Abdulrasool > > >>> compnerd (at) compnerd (dot) org > > >> -- > > >> Saleem Abdulrasool > > >> compnerd (at) compnerd (dot) org > > > -- > > > Saleem Abdulrasool > > > compnerd (at) compnerd (dot) org > > > -- > > > Saleem Abdulrasool > > > compnerd (at) compnerd (dot) org > > > _______________________________________________ > > > swift-lldb-dev mailing list > > > [email protected] > > > https://lists.swift.org/mailman/listinfo/swift-lldb-dev > > > > -- > > Saleem Abdulrasool > > compnerd (at) compnerd (dot) org > > -- Saleem Abdulrasool compnerd (at) compnerd (dot) org
_______________________________________________ swift-lldb-dev mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-lldb-dev
