Уровень отладки стека слишком глубоко в Ruby

Question

У меня есть программа ruby, которая слишком глубоко работает на уровне стека (SystemStackError) и заканчивается на datamapper:

from /usr/local/lib/ruby/gems/1.8/gems/dm-core-1.0.0/lib/dm-core/collection.rb:510:in `each'
from /usr/local/lib/ruby/gems/1.8/gems/dm-core-1.0.0/lib/dm-core/query/conditions/comparison.rb:616:in `map'
from /usr/local/lib/ruby/gems/1.8/gems/dm-core-1.0.0/lib/dm-core/query/conditions/comparison.rb:616:in `expected'
from /usr/local/lib/ruby/gems/1.8/gems/dm-core-1.0.0/lib/dm-core/query/conditions/comparison.rb:461:in `matches?'
from /usr/local/lib/ruby/gems/1.8/gems/dm-core-1.0.0/lib/dm-core/query/conditions/operation.rb:498:in `matches?'
from /usr/local/lib/ruby/gems/1.8/gems/extlib-0.9.15/lib/extlib/inflection.rb:103:in `any?'
from /usr/local/lib/ruby/gems/1.8/gems/dm-core-1.0.0/lib/dm-core/query/conditions/operation.rb:159:in `each'
from /usr/local/lib/ruby/1.8/set.rb:195:in `each'
 ... 5188 levels...

Есть ли способ отладить его? Как заглядывать в скрытые 5188 уровней? Ruby-debug не смог мне помочь, и встроенный ruby-профилировщик умрет с «[FATAL] не удалось выделить память»

Answer 1

Проблема, кроме поиска профилировщика ruby, который может справиться с переполнением стека, заключалась в злоупотреблении ленивостью Datamapper

Приложение получало текстовое свойство (, которое является ленивым ) внутри запроса (который также ленив), внутри другого запроса (, который также является ленивым ). Несмотря на то, что вся эта лень обычно превращает запрос N + 1 в запрос O (k) (что обычно означает 4 запроса), это, как оказалось, приводит к переполнению стека.

Выполнение теста переполнения в виде простого сценария ruby ​​вне среды rake, rspec и netbeans позволило мне более четко увидеть виновника.

Тем не менее хотелось бы, чтобы профилировщики рубина могли помочь мне с этим.