ActiveScaffold дает слишком глубокую ошибку стека; не удается найти рекурсию

Question

У меня есть приложение 3.0.7, использующее активный эшафот от github vhochstein/master. Я использую совместимую версию 3.x, которая может использоваться как поставщик/плагин, а не требует установки gem.

В процессе производства он попадает в ActionView :: Template :: Error (уровень слишком глубокий) :.

beaumont@edouard:~/beaumont/current$ script/rails server -p 4000 
ActionView::Template::Error (stack level too deep): 
    8: depth = Kernel.caller.count 
    9: logger.info "pagination: #{@page} #{depth}" 
    10: %> 
    11:  <%= render :partial => 'list_pagination_links', :locals => { :current_page => @page } if @page.pager.infinite? || @page.pager.number_of_pages > 1 %> 
    12: </div> 
    13: <br clear="both" /><%# a hack for the Rico Corner problem %> 
    14: </div> 

Я начал глядя на некоторые рекурсии в моем коде, а затем цикл в моей модели данных, которая была завинчивания до AS. Это произошло сначала с mod_passenger, но это также происходит с сервером script/rails, запущенным на сервере. (Это моя бета-тестовая машина)

Он всегда умирает в визуализированном поставщике/плагинах/active_scaffold/frontends/default/views/_list_pagination.html.erb (144.3ms 157). Я взломал ActionView, чтобы зарегистрировать Kernel.caller.count, чтобы я мог видеть, растет ли стек и растет, но я этого не вижу. Я вижу, что глубина стека достигает 180. Не кажется важным, если бы я увеличил стек до начала рельсов, но, возможно, что-то снова удалит стек.

В _list_pagination.html.erb он вызывает list_pagination_links. Если я прокомментирую эти звонки, тогда все не получится. Я пробовал сделать list_pagination_links ничего не делать (не имея в нем кода!), Но он все еще умер при этом вызове рендеринга. Интересно, действительно ли это в коде рендеринга, что стек либо рекурсивный, либо просто слишком большой.

Это не происходит на моем ноутбуке (debian sequeeze, 32-bit) в режиме разработки, но происходит на моей бета-машине (XEN VM, 32-разрядная, debian squeeze). Это происходило на моем ноутбуке время от времени, но не повторяется, и перезапуск рельсов «решает» проблемы. Я еще не пробовал режим производства на моем ноутбуке, и я также подозреваю, что он может зависящим от данных!

Answer 1

Отчаянный метод отладки, полезный для этих случаев, который я обнаружил при решении одной и той же проблемы, - это метод set_trace_func Kernel.

В основном он устанавливает способ, который будет вызываться после каждого «действия» интерпретатора. Если tou использовать это, чтобы распечатать некоторую информацию, тогда она может стать довольно многословной, ваша программа становится раздражающе медленной, но вы можете точно видеть, что происходит. И если это действительно бесконечная рекурсия, то вы увидите имя функции, которая неправильно проверила ваш экран за секунду.

Пример использования в вашем случае будет:

<% set_trace_func proc { |event, file, line, id, binding, classname| 
     printf "%8s %s:%-2d %10s %8s\n", event, file, line, id, classname 
     } %> 
<%= render :partial => 'list_pagination_links', :locals => { :current_page => @page } if @page.pager.infinite? || @page.pager.number_of_pages > 1 %> 
<% set_trace_func nil # disables tracing%> 

Link to the set_trace_func doc

пс: Я знаю, что это не ответ в его истинном смысле, но это было слишком долго, чтобы получить возможность отправлять как комментарии

Answer 2

Когда я отладка бесконечного вопроса подкачки в активных строительных лесах, я добавил:

require 'active_scaffold/extensions/paginator_extensions' 

в мой код. Кажется, эта линия является причиной. Я не знаю почему.

git bisect и строка за строкой удаления кода.