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-12783] Couldn't IRGen expression, no additional error #4467

Closed
swift-ci opened this issue May 11, 2020 · 16 comments
Closed

[SR-12783] Couldn't IRGen expression, no additional error #4467

swift-ci opened this issue May 11, 2020 · 16 comments
Assignees
Labels
bug Something isn't working LLDB for Swift

Comments

@swift-ci
Copy link

Previous ID SR-12783
Radar rdar://problem/63089113
Original Reporter arturgrigor (JIRA User)
Type Bug
Status Resolved
Resolution Done

Attachment: Download

Environment

Xcode 11.4.1 (11E503a)

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

md5: 2bc1e51cbad50b5f27bbf76dfa2b8642

Issue Description:

The debugger from Xcode 11.4.1 (11E503a) fails to print information about variables using the po, p or e command.

Example command: po insets

Result: error: Couldn't IRGen expression, no additional error

✅ I fixed my issue by removing a linked framework after seeing the debugger logs which I attached to this ticket but I think that the debugger should do better at informing the users about these problems.

@typesanitizer
Copy link

@swift-ci create

@adrian-prantl
Copy link
Member

++Can you post steps to reproduce the failure?

@swift-ci
Copy link
Author

Comment by Artur Grigor (JIRA)

@adrian-prantl I will try to compile a demo project tomorrow with that framework included if that helps.

@swift-ci
Copy link
Author

Comment by Artur Grigor (JIRA)

@adrian-prantl I couldn't upload the demo project here because it exceeds the 10MB limit so I uploaded it to iCloud Drive. Here's the link to it: https://www.icloud.com/iclouddrive/0xJEW8Tco_3VoTVHqzxZ0d7Rg#LLDB_Crash

Look for the `ViewController.swift` file, put a breakpoint on line 17 and run `po self.someVariable` to see the problem.

@adrian-prantl
Copy link
Member

Awesome, I can reproduce it.

@swift-ci
Copy link
Author

Comment by Artur Grigor (JIRA)

Perfect! ✌️

@adrian-prantl
Copy link
Member

LLDB could clearly do a better job of surfacing the error — I had to dig it out of the types log:

SwiftASTContext("Instabug")::GetASTContext() – failed to initialize ClangImporter: error: virtual filesystem overlay file '/Users/khaledElMorabea/Library/Developer/Xcode/DerivedData/Instabug-ccnahiryvffhsohhjpovgyeazflu/Build/Intermediates.noindex/ArchiveIntermediates/Instabug/IntermediateBuildFilesPath/Instabug.build/Release-iphonesimulator/Instabug.build/all-product-headers.yaml' not found

The problem here is with the binary Instabug framework that you are using. The .dSYM files that are generated from Swift code are not (yet) as portable as the ones generated from Clang code. The binary Swift module encode a hardcoded path to a yaml file that only exists on the original developer's machine. You should let them know that they need to compile their binary framework with -no-serialize-debugging-options if they are planning to distribute them to another machine.

@swift-ci
Copy link
Author

Comment by Artur Grigor (JIRA)

Excellent! I will inform them.

Also, I noticed that you've closed this issue. Shouldn't this ticket be open because developers still get this problem and by looking at the answers with solutions from this Stack Overflow link it looks like this problem can have multiple causes.

We should get a better error reporting from the debugger.

Thank you!

@swift-ci
Copy link
Author

Comment by Khaled El Morabea (JIRA)

arturgrigor (JIRA User) Thanks a lot for sharing this answer but could you share what this flag does? -no-serialize-debugging-options

@swift-ci
Copy link
Author

Comment by Artur Grigor (JIRA)

khaled.elmorabea (JIRA User) I can't find much information about this compiler flag except that it's defined in the Swift codebase (https://github.com/apple/swift) and there are some references to it in the Swift Forums (https://forums.swift.org/search?q=no-serialize-debugging-options), but maybe @adrian-prantl can help you with that.

@adrian-prantl
Copy link
Member

> Thanks a lot for sharing this answer but could you share what this flag does? -no-serialize-debugging-options

Sure! LLDB has an embedded Swift compiler that will attempt to load the .swiftmodule for each Swift module in your program. The binary .swiftmodule is embedded in the .dSYM bundle for LLDB to find. When -serialize-debugging-options is enabled the Swift compiler will serialize all Clang options (such as the -ivfsoverlay option added by Xcode's build system to find all-product-headers.yaml). This works really nice on the machine that the swift module was built on, but obviously isn't portable. We are working on lifting this dependency in LLDB, but that is still in progress. The -no-serialize-debugging-options option will omit those clang flags. The price for this is that you may need to pass one or two missing Clang options to LLDB manually via settings set target.swift-extra-clang-flags when you are debugging the framework itself now, but you may also get lucky and LLDB can piece together the necessary Clang flags from the main program.

@adrian-prantl
Copy link
Member

> Also, I noticed that you've closed this issue. Shouldn't this ticket be open because developers still get this problem and by looking at the answers with solutions from this Stack Overflow link it looks like this problem can have multiple causes.

That's exactly the problem. I want to avoid developers googling a symptom that may have multiple causes and then apply magic workaround steps they found on the internet. At the moment the volume of incoming bug reports is low enough that I can actually read them all, and I want to get a good sense of what problems developers are running into to help me prioritize work accordingly. I also don't want to miss out on an important new bug report, just because it happens to have the same symptom as something else.

I prefer one bugreport per issue, it's cheap to mark it as a duplicate, and I want to discourage pointless "I'm seeing this [symptom] too" comments that lack any kind of actionable information.

> We should get a better error reporting from the debugger.

I 100% agree, and I filed a bugreport for myself to track surfacing the underlying missing file error instead of the generic "couldn't IRGen expression" text.

@swift-ci
Copy link
Author

Comment by Artur Grigor (JIRA)

Ok, it makes sense.

Thank you for all your help!

@adrian-prantl
Copy link
Member

#1220

@swift-ci
Copy link
Author

Comment by Rolland Arthur (JIRA)

Hi, sorry to comment on such an old issue, but i'm currently facing the same (-ish) issue, and i'm a bit stuck...

In my case, i'm developing a framework and that issue have been send up to me by one of my user encontering the same issue.

I think i understood that i should use the -no-serialize-debugging-options flag when building my framework (an xcframework actually, no clue if it changes anything here though), but i can't manage to find where to put the dammned flag...

Can anyone help me with that? maybe @adrian-prantl. Thanks

@swift-ci
Copy link
Author

Comment by Rolland Arthur (JIRA)

Ok, don't mind me, i found the answer myself after all.

For reference, if someone face the same issue, here is how to add the -no-serialize-debugging-options flag:

In your framework xcode project, select the project scheme (the blue thingy in the file explorer) > select your framework under target > Build Settings > Search for Other Swift Flags > add BOTH of the following flags: -Xfrontend -no-serialize-debugging-options , each on a separate line. That's it, should be working

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
@shahmishal shahmishal transferred this issue from apple/swift May 7, 2022
jurvis pushed a commit to jurvis/libwally-swift that referenced this issue Aug 5, 2022
Currently, without these Swift flags, importing LibWally as a framework
breaks LLDB.

More information can be found in these LLVM issues:
apple/llvm-project#4467
apple/llvm-project#4464

And a great summary can be found here:
https://steipete.com/posts/couldnt-irgen-expression
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working LLDB for Swift
Projects
None yet
Development

No branches or pull requests

3 participants