Xcodeproj: Xcode project corruption due to UUID conflict

We run into a race condition/UUID conflict that seems to be related to changes made in https://github.com/CocoaPods/Xcodeproj/pull/627

Our sizeable project uses Cocoapods, and when testing with 1.7.0.beta.2 we run into an issue where a specific number of files included in the Pods project resulted in an apparent UUID conflict, which results in a corrupted Pods.xcodeproj generated.

The issue seems to reproduce only when:

Pods project getting constructed in the memory has a specific number of files (meaning adding or removing a file fixes the issue)
Before saving the Pods project, we add a new file ref in post-install hook: common_ref = project.new_file("Some.common.xcconfig")

After the project has been saved, the newly added file reference gets assigned a already existing UUID (46EB2E00000000) and replaces rootObject. With this, the project gets corrupted as root object no longer points to an expected data type (PBXFileReference instead of PBXProject).

% xcodeproj show Pods/Pods.xcodeproj
Traceback (most recent call last):
    7: from /Users/jsuliga/.rvm/gems/ruby-2.6.1/bin/xcodeproj:23:in `<main>'
    6: from /Users/jsuliga/.rvm/gems/ruby-2.6.1/bin/xcodeproj:23:in `load'
    5: from /Users/jsuliga/.rvm/gems/ruby-2.6.1/gems/xcodeproj-1.8.2/bin/xcodeproj:10:in `<top (required)>'
    4: from /Users/jsuliga/.rvm/gems/ruby-2.6.1/gems/claide-1.0.2/lib/claide/command.rb:334:in `run'
    3: from /Users/jsuliga/.rvm/gems/ruby-2.6.1/gems/xcodeproj-1.8.2/lib/xcodeproj/command/show.rb:46:in `run'
    2: from /Users/jsuliga/.rvm/gems/ruby-2.6.1/gems/xcodeproj-1.8.2/lib/xcodeproj/command.rb:60:in `xcodeproj'
    1: from /Users/jsuliga/.rvm/gems/ruby-2.6.1/gems/xcodeproj-1.8.2/lib/xcodeproj/project.rb:112:in `open'
/Users/jsuliga/.rvm/gems/ruby-2.6.1/gems/xcodeproj-1.8.2/lib/xcodeproj/project.rb:231:in `initialize_from_file': undefined method `product_ref_group' for #<Xcodeproj::Project::Object::PBXFileReference:0x00007fb77bee82e0> (NoMethodError)

I’m still trying to find a self-contained project that reproduces the issue, but it’s been quite challenging. Saving the project before adding the new reference seems to work around the issue, but causes us to double-save the project which is wasteful.

About this issue

Original URL
State: open
Created 5 years ago
Comments: 16 (16 by maintainers)

Most upvoted comments

@segiddins Do you remember why the line @jmkk inlined above: project.instance_variable_set(:@generated_uuids, project.instance_variable_get(:@available_uuids)) was important to set during UUID generation? The particular line existed before I generalized the code for multi project generation, but I don’t recall if there was a gotcha here that we had to account for.

In order to fix this in the short term, maybe we can add another installation flag to disable stabilizing target UUIDs since @jmkk 's project already disabled deterministic UUIDs. We would just have to add another validation to incremental installation flag. Thoughts @dnkoutso ?

Sorry this is taking so long to resolve @jmkk and thanks for being so patient.

sebastianv1 on Nov 14, 2019