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

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

0 голосов
/ 24 марта 2012

У меня есть приложение 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, подключенным к серверу.(Это мой бета-тестовый компьютер)

Он всегда умирает в Rendered vendor / plugins / 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-bit, debian squeeze).Это происходило на моем ноутбуке время от времени, но не повторяемым образом, и перезапуск направляющих «решил» проблемы.Я еще не пробовал рабочий режим на своем ноутбуке, и я также подозреваю, что он может зависеть от данных!

Ответы [ 2 ]

1 голос
/ 24 марта 2012

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

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

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

 <% 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%>

Ссылка на документ set_trace_func

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

0 голосов
/ 24 марта 2012

Когда я отлаживал проблему бесконечной подкачки в Active Scaffold, я добавил: 

require 'active_scaffold/extensions/paginator_extensions'

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

git bisect и построчное удаление кода нашло это.

...