Upgrading to 7.1.0 from 7.0.0, now we can't `po` anything in lldb due to GTMSessionFetcher import issue.

[marcpalmer]

Describe the bug

We are seeing issues in lldb related to GTMSessionFetcher since updating to 7.1.0, where it complains it cannot import GTMSessionFetcher any time we try to po a value from our code in the debugger — which is obviously very bad news.

I'm far from an expert on this but in our case the problem "goes away" if we change the conditional import in GIDGoogleUser.h

GoogleSignIn-iOS/GoogleSignIn/Sources/Public/GoogleSignIn/GIDGoogleUser.h

Line 26 in ec20caf

#ifdef SWIFT_PACKAGE

so that it never uses the @import modular import variant.

Why this is suddenly a problem - as this has been in the GoogleSignIn code for a while – is not clear. We relatively recently (months back) added one SPM package to our app. The rest are all Cocoapods, including GSI and its dependencies. Perhaps this has triggered the problem, but we certainly only noticed it recently when switching from 7.0.0 to 7.1.0.

The clear implication is that SWIFT_PACKAGE is now defined for our builds where it wasn't previously, but this is breaking lldb for some reason, perhaps because GSI is still built with Cocoapods, not SPM?

To Reproduce

Sorry, we don't know.

Expected behavior

We should not have any issues using the debugger, least of all complaints about failure of lldb to import GTMSessionFetcher.

Screenshots

Environment

• Browser: Xcode 15.2 / Xcode 15.3

Additional context

[mdmathias]

cc @thomasvl for any ideas on this.

[mdmathias]

I was able to reproduce this problem in a sample app (linked below). I created an app with a Podfile depending on GoogleSignIn. I also added an arbitrary Swift Package from Apple. I then did pod install to get GSI 7.1.0, and built and ran from the .xcworkspace.

All pos did not cause an lldb error. Only pos like po GIDSignIn.sharedInstance.currentUser caused an error. Note, if I did let user = GIDSignIn.sharedInstance.currentUser, and then po user, then there would be no lldb error. This might be a workaround for you...

One thing to note is that GSI 7.0.0 depended upon GTMAppAuth 2.0.0, where GSI 7.1.0 depends upon GTMAppAuth 4.1.1+. GTMAppAuth release 4.0.0 rewrote that library in Swift. In between GSI 7.0.0 and 7.1.0, this import in GIDGoogleUser.h:

// We have to import GTMAppAuth because forward declaring the protocol does
// not generate the `fetcherAuthorizer` property below for Swift.
#ifdef SWIFT_PACKAGE
@import GTMAppAuth;
#else
#import <GTMAppAuth/GTMAppAuthFetcherAuthorization.h>
#endif

changed to

#ifdef SWIFT_PACKAGE
@import GTMSessionFetcherCore;
#else
#import <GTMSessionFetcher/GTMSessionFetcher.h>
#endif

I made this change because GIDGoogleUser.h refers to GTMFetcherAuthorizationProtocol here, which is presumably why GTMAppAuth was previously imported in GIDGoogleUser.h (to grab GTMFetcherAuthorizationProtocol transitively via GTMAppAuth, which depends upon GTMSessionFetcher). GIDGoogleUser does not itself need anything from GTMAppAuth.

I created another test app that was pure Swift Package Manager (linked below). I put a breakpoint in a spot after I used let user = GIDSignIn.sharedInstance.currentUser, and did: po user and also po GIDSignIn.sharedInstance.currentUser. Neither produced an lldb error.

I think the issue has something to do with GTMAppAuth's change to Swift combined with CocoaPods...something. I'm not sure yet. This problem reminds me google/gtm-session-fetcher#384, but looks like that was included in https://github.com/google/gtm-session-fetcher/releases/tag/v3.4.0, which I can confirm is being used in my tests below. Not sure...

I made a final test app that is pure CocoaPods (see link below) that depends upon GSI. I was able to po user and po GIDSignIn.sharedInstance.currentUser without a problem. So, I think this means that there is some issue with lldb and projects that are made from a combination of SPM and CocoaPods. It may or may not have anything to do with GTMAppAuth and GTMSessionFetcher.

I will do some more digging and ask around.

Test.zip (SPM + CocoaPods)
Test (SPM).zip
Test (CocoaPods Only).zip

[mdmathias]

Anecdotally, I think this issue demonstrates that mixing SPM and CocoaPods leads to some complexity. Is it possible for you to use one or the other?

[marcpalmer]

First, @mdmathias thank you so much for going to the effort to repro this. It is really appreciated.

For us lldb chokes on anything we try — although if memory serves that is probably Swift symbols only as I don't recall recently trying to po ObjC expressions.

I suspect your theory is correct re: mixing SPM and Cocoapods however I know that we did not have this problem until updating to 7.1.0 — which we did ~2 weeks ago and we've had the SPM dep in there for months. So I think it is more nuanced than this. On paper I don't think there is any reason that mixing these should cause problems - they both just build libraries and frameworks. I don't think switching over fully to SPM is viable for us due to some legacy dependencies but it is already on my to-do list to investigate this.

Perhaps there is an issue with GSI where it does not have the dependency on GTMSessionFetcher fully expressed, or at least it seems like lldb doesn't see it available as a dependency so maybe there lies a clue? Because again, even with that SWIFT_PACKAGE check it worked before when it was transitive via GTMAppAuth.

[marcpalmer]

Oh @mdmathias I will add... isn't it wrong that the SWIFT_PACKAGE branch of the #if is being used at all, because we're exclusively building GoogleSignIn and its deps using Cocoapods.

The fact that we do have SPM enabled in Xcode causes SWIFT_PACKAGE to be defined doesn't it? So this is falsely thinking that it has built modules and can use module imports for GTMSessionFetcherCore which it hasn't? So presumably when building with Cocoapods that is not defined or we wouldn't even get as far as a successful build — and so when lldb is running it evals the header (my poor understanding is that lldb will re-evaluate headers/re-imports) and SWIFT_PACKAGE is defined then so it fails?

EDIT: This still doesn't explain why it was OK previously with GTMAppAuth as the dep.

[mdmathias]

I agree that the issue sits somewhere in between GTMAppAuth's conversion to Swift in versions 4+ and the mixing of SPM and CocoaPods, with what I expect to be the majority of the onus on the mixing of SPM and CocoaPods.

I don't think we can point too strongly to GTMAppAuth's Swift conversion since that is more or less moot: the library has full rights to be Swift or Objective-C. So, IMO, the issue has more to do with mixing the package managers.

This leads me to your next point about how the .xcworkspace project is somehow hitting the positive case in the #ifdef SWIFT_PACKAGE check in GIDGoogleUser.h. I'm not exactly sure how or why that's happening, but you're theory sounds right. I guess that kind of highlights my point about combining CocoaPods and SPM being a bit brittle and yielding undefined behavior.

I will keep investigating this on my end.

[marcpalmer]

I think that the key thing is probably (?) that SWIFT_PACKAGE does not mean "built with SPM". It just means "SPM is supported by this toolchain". If correct, this makes it the wrong thing to switch on here... although I'm not sure there is a "right thing" available. I think what it's trying to do is determine if GTMAppAuth was built as a modular framework, which seems like quite a different thing.

[fuchenxi]

I have a similar issue in my project, which involves a mix of Objective-C and Swift.

When I use pod 'GoogleSignIn' to import your library and execute the po command in a Swift file, I receive the following error:

error: couldn't IRGen expression: Clang importer error
error: /Users/Product***/Pods/GoogleSignIn/GoogleSignIn/Sources/Public/GoogleSignIn/GIDGoogleUser.h:27:9: error: module 'GTMSessionFetcherCore' not found
@import GTMSessionFetcherCore;

If I add @import GoogleSignIn; or#import <GoogleSignIn/GoogleSignIn.h>to the bridging-header.h file, and then execute the po command again, I get the following error:

error: Expression evaluation failed. Retrying without binding generic parameters
error: Could not evaluate the expression without binding generic types.

This problem has been bothering me for a long time and I hope to get help。

Currently, I've switched to integrating your library using SPM, and I don't encounter this issue anymore.

[mdmathias]

@fuchenxi I'm not sure how your project is set up, but our Swift sample project using CocoaPods does not have this issue.

[fuchenxi]

If I provide my podfile file, can you analyze the problem?

[Kharauzov]

I can confirm the same issue, mentioned by @marcpalmer .
I tried this hot fix:

I'm far from an expert on this but in our case the problem "goes away" if we change the conditional import in GIDGoogleUser.h

And it works for me.

But I wish there can be some fulfil solution to this bug.

[mdmathias]

@marcpalmer I've created #403 to address this. There is a sample project linked in a comment on that PR, but I would appreciate you pointing your dependency to https://github.com/google/GoogleSignIn-iOS/tree/mdmathias/fix-lldb-crash and testing in your project as well. Would you mind doing that? Let me know if this change fixes the issue for you. Thanks!