Skip to content
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

[SR-9092] Could Not Resolve Type during swift Foundation debugging #3603

Closed
swift-ci opened this issue Oct 26, 2018 · 24 comments
Closed

[SR-9092] Could Not Resolve Type during swift Foundation debugging #3603

swift-ci opened this issue Oct 26, 2018 · 24 comments

Comments

@swift-ci
Copy link
Contributor

Previous ID SR-9092
Radar rdar://problem/45595134
Original Reporter levivic (JIRA User)
Type Bug
Status Resolved
Resolution Cannot Reproduce

Attachment: Download

Environment

Linux

Additional Detail from JIRA
Votes 0
Component/s Foundation, LLDB for Swift
Labels Bug
Assignee @adrian-prantl
Priority Medium

md5: d7450fcc100c91a81b47f645eb0f3fe4

Issue Description:

Hi guys, i am trying to debug swift-corelibs-foundatin with lldb in Linux. However, it keeps giving me "<could not resolve type>" when I try to access a variable. Here is my testing example:

 import Foundation
 let c1 = NSDateComponents()
 let c2 = NSDateComponents()
 c2.calendar = c1.calendar
 let c1a = c1.calendar as Any
 print(c1a)
 let c2a = c2.calendar as Any
 print(c2a)

I have set breakpoint at `c2.calendar = c1.calendar`. When i step in, at some point it reaches `NSCalendar.swift` under Foundation as follows:

 (lldb) s
 Process 9448 stopped
 * thread #&#8203;1, name = 'simCalendarCopy', stop reason = step in
 frame #&#8203;0: 0x000003fffd6eff9e libFoundation.so`NSDateComponents.calendar.setter(newValue=<unavailable>, self=<unavailable>) at NSCalendar.swift:1428
 1425 return _calendar
 1426 }
 1427 set {
 -> 1428 if let val = newValue \{ 
1429 _calendar = val 
1430 } else {
 1431 _calendar = nil
 Target 0: (simCalendarCopy) stopped.

Then when i tried to use `fr v` to access variables, the debugger would show me `could not resolve type`. It looks like lldb won't print any variables when it gets into the Foundation code. Any ideas how to fix this?

@dcci
Copy link
Mannequin

dcci mannequin commented Oct 26, 2018

@swift-ci create

@gottesmm
Copy link
Member

Whatever the resolution of this, this seems pretty basic. Could we get an integration test for this?

@dcci
Copy link
Mannequin

dcci mannequin commented Oct 26, 2018

Sure.

@swift-ci
Copy link
Contributor Author

Comment by Jim Ingham (JIRA)

It isn't a matter of ADDING tests. We have lots of regression tests that create a swift module which imports Foundation, and then examines Foundation derived objects. It's just that all those tests are Darwin only at present. What Michael is really asking for - though he didn't know it 😉 - was for us to go sort out which of our Foundation tests run on Linux, and turn those tests on...

@dcci
Copy link
Mannequin

dcci mannequin commented Oct 26, 2018

I'll try to take a look at this as soon as I can, but levivic (JIRA User) if you feel really adventurous, you might consider trying to fix this yourself, and I can probably give you some guidance (if you're up to it).

@swift-ci
Copy link
Contributor Author

Comment by Leo Z (JIRA)

@dcci I don't mind looking into it. But at this moment i have no clue at all on how to fix this, please advise. thx

@dcci
Copy link
Mannequin

dcci mannequin commented Oct 26, 2018

The first thing we might consider looking at is the type logs in ldlb.
when running lldb type at the console

log enable lldb types -f ~/lldb-log.txt

and then attach ~/lldb-log.txt to this SR, so we can have at least a clue of what's failing, and go from there.

@dcci
Copy link
Mannequin

dcci mannequin commented Oct 26, 2018

(type that, then execute the commands that are failing, that is).

@swift-ci
Copy link
Contributor Author

Comment by Leo Z (JIRA)

lldb-log.txt see the log file attached.

@dcci
Copy link
Mannequin

dcci mannequin commented Oct 26, 2018

The log contains the culprit.

lldb             ((SwiftASTContext*)0x3ff6e5c6370)->GetTypeFromMangledTypename('$S10Foundation16NSDateComponentsCD')
lldb             ((SwiftASTContext*)0x3ff6e5c6370)->GetTypeFromMangledTypename('$S10Foundation16NSDateComponentsCD') -- not cached, searching
lldb             ((SwiftASTContext*)0x3ff6e5c6370)->GetTypeFromMangledTypename('$S10Foundation16NSDateComponentsCD') -- error: type for symbolname '' was not found

@dcci
Copy link
Mannequin

dcci mannequin commented Oct 26, 2018

What I would start from is setting a breakpoint in

@swift-ci
Copy link
Contributor Author

Comment by Leo Z (JIRA)

@dcci I have used gdb to debug swift compiler before. But these errors are from lldb. Suppose I have the problematic code example.swift as

 import Foundation
 let c1 = NSDateComponents()
 let c2 = NSDateComponents()
 c2.calendar = c1.calendar
 let c1a = c1.calendar as Any
 print(c1a)
 let c2a = c2.calendar as Any
 print(c2a)

And compile it to executable example. Then i try to debug lldb using gdb by gdb lldb, followed by r example and then r. However, it never hits the breakpoint SwiftASTContext::GetTypeFromMangledTypename.

Another question, as you mentioned debug `swiftc`, how can i debug `lldb` and `swiftc` at the same time?

@dcci
Copy link
Mannequin

dcci mannequin commented Oct 29, 2018

You don't need to debug lldb and swiftc at the same time. Just attach to lldb.

@dcci
Copy link
Mannequin

dcci mannequin commented Oct 29, 2018

If you're not able to hit that breakpoint, still, let me know and I'll take a look. Please note that you need a debug build both of the compiler and the debugger to be effective (i.e. you need to run ./build-script -d -lldb).

@swift-ci
Copy link
Contributor Author

Comment by Leo Z (JIRA)

Following the step provided above, i still don't hit the breakpoint. Both the compiler and debugger are built in debug mode.

@dcci
Copy link
Mannequin

dcci mannequin commented Oct 29, 2018

OK, I'll try to take a look at this myself today. I'll let you know, and thanks for your attempts!

@dcci
Copy link
Mannequin

dcci mannequin commented Nov 6, 2018

I can't reproduce this on Linux x86/64.

@swift-ci
Copy link
Contributor Author

swift-ci commented Nov 6, 2018

Comment by Leo Z (JIRA)

@dcciCan you provide your building steps?

@dcci
Copy link
Mannequin

dcci mannequin commented Nov 6, 2018

./swift/utils/build-script --foundation --libdispatch --release --lldb --test --build-ninja -- --reconfigure --skip-test-cmark --skip-test-swift --skip-build-benchmarks --skip-test-foundation=1

I'm building on ubuntu 16.04 (x86_64)

@adrian-prantl
Copy link
Member

I can't reproduce this either:

(lldb) n
Process 38205 stopped

  • thread Fixing whitespace formatting #1, name = 'a.out', stop reason = step over
    frame #0: 0x00007ffff768ebb6 libFoundation.so`NSDateComponents.calendar.setter(newValue=nil, self=0x000055555558e1c0) at NSCalendar.swift:1407:27
    1404 if let val = newValue {
    1405 _calendar = val
    1406 } else {
    -> 1407 _calendar = nil
    1408 }
    1409 }
    1410 }
    Target 0: (a.out) stopped.
    (lldb) fr v
    (Foundation.Calendar?) newValue = nil
    (Foundation.NSDateComponents) self = 0x000055555558e1c0 {
    Foundation.NSObject = {}
    _calendar = nil
    _timeZone = nil
    _values = 19 values {
    ...

@adrian-prantl
Copy link
Member

How did you build swift / which version are you using?

For reference, I tried this on master using

swift/utils/build-script -r -l --foundation --libdispatch -- --install-prefix=/usr --install-destdir=$PWD/_install --install-foundation --install-libdispatch --install-swift '--swift-install-components=autolink-driver;compiler;clang-builtin-headers;stdlib;swift-remote-mirror;sdk-overlay;license;sourcekit-inproc' '--llvm-install-components=llvm-cov;llvm-profdata;IndexStore' --build-swift-static-stdlib --build-swift-static-sdk-overlay --install-lldb

@swift-ci
Copy link
Contributor Author

swift-ci commented Nov 7, 2018

Comment by Leo Z (JIRA)

./utils/build-script -j 2 -d  --lldb --foundation --xctest --llbuild --swiftpm --libdispatch --   --verbose-build=1         --install-swift --install-foundation --install-xctest --install-llbuild --install-swiftpm --install-libdispatch --install-lldb   --swift-install-components='autolink-driver;compiler;clang-builtin-headers;stdlib;sdk-overlay;license'         --build-swift-static-stdlib=1         --install-prefix=/usr         --install-destdir=$MYDESTDIR

This is what i have been using for the build. And my version is 4.2.

@adrian-prantl
Copy link
Member

I see. It's totally possible that this is broken in swift-4.2-branch. There have been a lot of improvements in that area since. Does it work for you on stable / swift-5.0-branch?

@swift-ci
Copy link
Contributor Author

swift-ci commented Nov 7, 2018

Comment by Leo Z (JIRA)

I haven't tried that since we are not working on the new branch at this moment. But thanks for mentioning it @adrian-prantl

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
@shahmishal shahmishal transferred this issue from apple/swift May 5, 2022
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants