Cocoapods 1.0.0 - SystemStackError - stack level too deep - Subspecs cross ref. #5362

WiesnerPeti · 2016-05-18T17:13:47Z

[ x] I've read and understood the *CONTRIBUTING guidelines and have done my best effort to follow.

Tried to [search|https://github.com/CocoaPods/CocoaPods/search?q=stack+level+too+deep&type=Issues] for issues only found either for older cocoapods version or not for subspecs

Report

What did you do?

Updated cocoapods from 0.39 to 1.0

Updated Podfile and Podspecs to fix install errors. (Only missing description or home page properties)

Run pod install

What did you expected to happen?

Install all pod dependencies correctly.

What happened instead?

At the Generating Pods project, the script stopped with the following error:

SystemStackError - stack level too deep
/usr/local/lib/ruby/gems/2.3.0/gems/cocoapods-1.0.0/lib/cocoapods/target/pod_target.rb:191:in `each'
/usr/local/lib/ruby/gems/2.3.0/gems/cocoapods-1.0.0/lib/cocoapods/target/pod_target.rb:191:in `flat_map'
/usr/local/lib/ruby/gems/2.3.0/gems/cocoapods-1.0.0/lib/cocoapods/target/pod_target.rb:191:in `recursive_dependent_targets'

This each - flat_map - recursive_dependent_targets runs for ~100 lines, then:

/usr/local/lib/ruby/gems/2.3.0/gems/cocoapods-1.0.0/lib/cocoapods/generator/xcconfig/pod_xcconfig.rb:66:in `generate'
/usr/local/lib/ruby/gems/2.3.0/gems/cocoapods-1.0.0/lib/cocoapods/generator/xcconfig/pod_xcconfig.rb:35:in `save_as'
/usr/local/lib/ruby/gems/2.3.0/gems/cocoapods-1.0.0/lib/cocoapods/installer/target_installer/pod_target_installer.rb:204:in `create_xcconfig_file'
/usr/local/lib/ruby/gems/2.3.0/gems/cocoapods-1.0.0/lib/cocoapods/installer/target_installer/pod_target_installer.rb:22:in `block in install!'
/usr/local/lib/ruby/gems/2.3.0/gems/cocoapods-1.0.0/lib/cocoapods/user_interface.rb:144:in `message'
/usr/local/lib/ruby/gems/2.3.0/gems/cocoapods-1.0.0/lib/cocoapods/installer/target_installer/pod_target_installer.rb:17:in `install!'
/usr/local/lib/ruby/gems/2.3.0/gems/cocoapods-1.0.0/lib/cocoapods/installer.rb:621:in `block (2 levels) in install_libraries'
/usr/local/lib/ruby/gems/2.3.0/gems/cocoapods-1.0.0/lib/cocoapods/installer.rb:619:in `each'
/usr/local/lib/ruby/gems/2.3.0/gems/cocoapods-1.0.0/lib/cocoapods/installer.rb:619:in `block in install_libraries'
/usr/local/lib/ruby/gems/2.3.0/gems/cocoapods-1.0.0/lib/cocoapods/user_interface.rb:144:in `message'
/usr/local/lib/ruby/gems/2.3.0/gems/cocoapods-1.0.0/lib/cocoapods/installer.rb:618:in `install_libraries'
/usr/local/lib/ruby/gems/2.3.0/gems/cocoapods-1.0.0/lib/cocoapods/installer.rb:170:in `block in generate_pods_project'
/usr/local/lib/ruby/gems/2.3.0/gems/cocoapods-1.0.0/lib/cocoapods/user_interface.rb:63:in `section'
/usr/local/lib/ruby/gems/2.3.0/gems/cocoapods-1.0.0/lib/cocoapods/installer.rb:167:in `generate_pods_project'
/usr/local/lib/ruby/gems/2.3.0/gems/cocoapods-1.0.0/lib/cocoapods/installer.rb:119:in `install!'
/usr/local/lib/ruby/gems/2.3.0/gems/cocoapods-1.0.0/lib/cocoapods/command/install.rb:37:in `run'
/usr/local/lib/ruby/gems/2.3.0/gems/claide-1.0.0/lib/claide/command.rb:334:in `run'
/usr/local/lib/ruby/gems/2.3.0/gems/cocoapods-1.0.0/lib/cocoapods/command.rb:50:in `run'
/usr/local/lib/ruby/gems/2.3.0/gems/cocoapods-1.0.0/bin/pod:55:in `<top (required)>'
/usr/local/bin/pod:23:in `load'
/usr/local/bin/pod:23:in `<main>'

CocoaPods Environment

Sorry sensitive information, but I will try to describe the problem:
Environment: Cocoapods 1.0.0 (0.39 also installed), ruby 2.3.0
The developer pods causing the issues have only subspecs. One of the developer pod's subspec refers to the suspec of the other and vice versa. This recursion was introduced earlier, but in the 0.39 version this was not a problem as I understand, the true recursion for target dependency resolution was only introduced in the 1.0.0 9 days ago, I believe here: ef854ab

I will try to reproduce the podspec environment:
In s1.podspec:

Pod::Spec.new do |s1|
   s1.subspec 'subspecA' do |subspecA|
       subspecA.dependency 's2/subspecB'
   end
   s1.subspec 'subspecB' do |subspecB|
      subspecB.source_files = './**/*.{h,m}'
   end
end


In s2.podspec:
Pod::Spec.new do |s2|
   s2.subspec 'subspecA' do |subspecA|
        subspecA.dependency 's1/subspecB'
   end
   s2.subspec 'subspecB' do |subspecB|
      subspecB.source_files = './**/*.{h,m}'
   end
end
Sample app pod env (without private repos):
   CocoaPods : 1.0.0
        Ruby : ruby 2.3.0p0 (2015-12-25 revision 53290) [x86_64-darwin15]
    RubyGems : 2.5.1
        Host : Mac OS X 10.11.4 (15E65)
       Xcode : 7.3.1 (7D1014)
         Git : git version 2.7.4 (Apple Git-66)
Ruby lib dir : /Users/peterwiesner/.rvm/rubies/ruby-2.3.0/lib

Installation Source

Executable Path: /Users/peterwiesner/.rvm/gems/ruby-2.3.0/bin/pod

Plugins

cocoapods-deintegrate : 1.0.0
cocoapods-plugins     : 1.0.0
cocoapods-search      : 1.0.0
cocoapods-stats       : 1.0.0
cocoapods-trunk       : 1.0.0
cocoapods-try         : 1.0.0

Podfile

# Uncomment this line to define a global platform for your project
# platform :ios, '9.0'

target 'SubSpecCircular' do
  # Uncomment this line if you're using Swift or would like to use dynamic frameworks
  # use_frameworks!

  # Pods for SubSpecCircular
  pod "Pod3/s3", :path => "./DeveloperPods/Pod3"
  pod "Pod1", :path => "./DeveloperPods/Pod1"
  pod "Pod2", :path => "./DeveloperPods/Pod2"

  project "./SubSpecCircular.xcodeproj"
end

target 'SubSpecCircularTests' do
    project "./SubSpecCircular.xcodeproj"
end

target 'SubSpecCircularUITests' do
    project "./SubSpecCircular.xcodeproj"
end

Question

Is this a valid construction of using subspecs? (As this was correctly installed for 0.39) Can you suggest a resolution for this? (extract these subspecs to a separate developer pod)
Thank you!

The text was updated successfully, but these errors were encountered:

segiddins · 2016-05-18T17:19:05Z

That's a circular dependency, the resolver should be erroring over that. Please share a project we can use to reproduce so we can raise the appropriate error. Thanks!

WiesnerPeti · 2016-05-18T17:42:29Z

Hi @segiddins,
thank you so much for the quick answer! I'm working on a sample project to recreate this scenario. (So far pod recognised the circularity [!] There is a circular dependency between Pod2/s2 and Pod1/s1 This means, that the original case a bit more complex (it fails on the Generating Pod Folder and not at fetching)

segiddins · 2016-05-18T19:07:23Z

OK, well I'll the the issue open for a bit if you're able to boil it down to a reproducible case you can share.

WiesnerPeti · 2016-05-19T08:08:17Z

@segiddins Updated the example in the issue reporting, it is now closer to the current state. I over-simplified the cross-references. Still working on the example project, the example app still runs correctly.

WiesnerPeti · 2016-05-19T20:25:23Z

@segiddins Finally I could reproduce it. Here is the project. If you run pod 1.0.0 install you can see the infinite recursion. Running it with verbose shows me, that the recursion starts when pod wants to create the xconfig for the targets. The pod install won't error for circular dependency at the beginning, maybe because we refer to a different subspec from the other spec? If I manually revert ef854ab back, everything is working fine. I will update the issue with the sample project pod env.

WiesnerPeti · 2016-05-23T14:12:17Z

Hi @segiddins,

is there an update on this? is this usage of sub-specs supported in 1.0.0 or this error should have been reported earlier in the install process?

Cheers,

segiddins · 2016-05-23T14:15:00Z

I don't think anyone on the team has managed to check in yet. A project that we could run pod install on would make debugging much easier though

WiesnerPeti · 2016-05-23T14:18:03Z

Please tell me how I should update the demo project here: https://www.dropbox.com/s/p3mrm4sdk05eogf/SubSpecCircular.zip?dl=0 to help this process :)

segiddins · 2016-05-23T17:04:43Z

Never mind, this is actually a bug -- it's happening since the subspecs have no circular dependence, but the PodTargets taken as a whole do -- the solution will be to manually walk the graph, stopping when we get to self or something already in the list of recursive_dependent_targets

WiesnerPeti · 2016-06-14T06:13:03Z

Thank you @segiddins and @champo ! :)

segiddins added the s1:awaiting input Waiting for input from the original author label May 18, 2016

segiddins removed the s1:awaiting input Waiting for input from the original author label May 19, 2016

segiddins added t2:defect These are known bugs. The issue should also contain steps to reproduce. PRs welcome! s3:detailed Issues with in-depth explanations and examples that make it easier to troubleshoot labels May 23, 2016

This was referenced Jun 2, 2016

[PodTarget] Make #recursive_dependent_targets handle cyclic dependencies #5451

Merged

[PodTarget] Add a cyclic dependencies between subspecs case CocoaPods/cocoapods-integration-specs#72

Merged

segiddins closed this as completed in #5451 Jun 14, 2016

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Cocoapods 1.0.0 - SystemStackError - stack level too deep - Subspecs cross ref. #5362

Cocoapods 1.0.0 - SystemStackError - stack level too deep - Subspecs cross ref. #5362

WiesnerPeti commented May 18, 2016 •

edited

Loading

segiddins commented May 18, 2016

WiesnerPeti commented May 18, 2016

segiddins commented May 18, 2016

WiesnerPeti commented May 19, 2016

WiesnerPeti commented May 19, 2016

WiesnerPeti commented May 23, 2016

segiddins commented May 23, 2016

WiesnerPeti commented May 23, 2016

segiddins commented May 23, 2016

WiesnerPeti commented Jun 14, 2016

Cocoapods 1.0.0 - SystemStackError - stack level too deep - Subspecs cross ref. #5362

Cocoapods 1.0.0 - SystemStackError - stack level too deep - Subspecs cross ref. #5362

Comments

WiesnerPeti commented May 18, 2016 • edited Loading

Report

What did you do?

What did you expected to happen?

What happened instead?

CocoaPods Environment

Installation Source

Plugins

Podfile

Question

segiddins commented May 18, 2016

WiesnerPeti commented May 18, 2016

segiddins commented May 18, 2016

WiesnerPeti commented May 19, 2016

WiesnerPeti commented May 19, 2016

WiesnerPeti commented May 23, 2016

segiddins commented May 23, 2016

WiesnerPeti commented May 23, 2016

segiddins commented May 23, 2016

WiesnerPeti commented Jun 14, 2016

WiesnerPeti commented May 18, 2016 •

edited

Loading