有史以来第一次捆绑安装，堆栈层次太深 [英] First ever bundle install, stack level too deep

问题描述

我使用命令
rails new qbc --database = mysql 创建了一个全新的rails项目。它创建的所有文件都很完美，但在软件包中
安装时出错了。

 
 $ bundle install 
提取来自https：//rubygems.org / gem元数据的元数据/ ........... 
从https://rubygems.org/ .. 
获取gem元数据不幸的是，一个致命错误发生。请参阅http://bit.ly/bundler-issues上的Bundler 
疑难解答文档。谢谢！ 
 / usr / bin / bundle：23：堆栈级别太深（SystemStackError）
 

gist.github.com/3956513

我已经搜索并搜索了这个问题的解决方案，但我似乎无法找到任何其他经历过它的人。我正在Cygwin上开发，如果这与它有关系，我
也不会感到惊讶。

我试着创建一个只有源代码的Gemfile，一个空的
目录中的一个gem和bundle安装仍然会给出相同的错误。我已经遵循所有
的故障排除步骤，重新安装Cygwin和所有包，一切。
持续吸引我的目光是获取gem元数据两次......是否有可能在某种循环中捕获
bundler？

解决方案

Cygwin的pthread_attr_getstack默认报告大约90k。我认为Cygwin报告承诺（used-so-far）堆栈大小，而不是保留（可用总数）大小。然后Ruby将这个数量（即90k）视为有史以来的最大堆栈大小。

更改最初的提交堆栈大小：

  peflags -X409600`which ruby​​` 
  

请注意大写的-X。小写-x会更改保留的堆栈大小，而不是最初提交的堆栈空间。

这为我解决了所有的Ruby + Rails + Cygwin问题。

我不知道Ruby或Cygwin内部结构是否足够了解哪个是正确的修复方法，但它可能就是其中的一个。

• Cygwin从pthread_attr_getstack报告保留的堆栈大小。


• Ruby增加了一个构建步骤来运行上面的peflags命令。 >
  
• Ruby以不同的方式确定可用的堆栈空间。

I have created a brand new rails project using the command rails new qbc --database=mysql. It creates all the files perfectly fine, but at the bundle install it errors out

$ bundle install
Fetching gem metadata from https://rubygems.org/...........
Fetching gem metadata from https://rubygems.org/..
Unfortunately, a fatal error has occurred. Please see the Bundler
troubleshooting documentation at http://bit.ly/bundler-issues. Thanks!
/usr/bin/bundle:23: stack level too deep (SystemStackError)

gist.github.com/3956513

I have searched and searched for the solution to this issue but I can't seem to find anyone else who has experienced it. I am developing on Cygwin and I wouldn't be surprised if that has something to do with it.

I tried creating a Gemfile with just the source and one gem in it in an empty directory and bundle install still gives the same error. I have followed all of the troubleshooting steps, reinstalled Cygwin and all packages, everything. What keeps catching my eye is the Fetching gem metadata twice...is it possible that bundler is caught in some kind of loop?

解决方案

Cygwin's pthread_attr_getstack reports about 90k by default. I think Cygwin is reporting the committed (used-so-far) stack size, not the reserved (total available) size. Then Ruby is treating that (i.e. 90k) as the maximum stack size ever.

To change the initial committed stack size:

peflags -X409600 `which ruby`

Note the capitalized -X. Lowercase -x changes reserved stack size, not initially-committed stack space.

This fixes all Ruby+Rails+Cygwin issues for me.

I don't know Ruby or Cygwin internals well enough to know which is the right fix, but it's probably one of these.

• Cygwin reports reserved stack size from pthread_attr_getstack.
• Ruby adds a build step to run the peflags command above.
• Ruby determines the available stack space a different way.

这篇关于有史以来第一次捆绑安装，堆栈层次太深的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！