ActiveScaffold gibt Stack zu tief Fehler; kann keine Rekursion finden

Question

Ich habe eine 3.0.7 App mit aktiven Gerüst von Github Vhochstein/Master. Ich verwende die 3.x-kompatible Version, die als Anbieter/Plugin verwendet werden kann, anstatt eine Edelstein-Installation zu erfordern.

In der Produktion trifft es ActionView :: Template :: Error (Stapelebene zu tief) :.

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> 

Ich begann in meinem Code für einige Rekursion suchen, und dann für den Zyklus in meinem Datenmodell, das AS wurde vermasseln. Es passierte zuerst mit mod_passenger, aber es tritt auch auf, wenn der Server scripts/rails auf dem Server angemeldet ist. (Dies ist meine Beta-Testmaschine)

Es stirbt immer in gerenderten Anbieter/Plugins/Active_scaffold/Frontends/Standard/views/_list_pagination.html.erb (144,3ms 157). Ich hackte ActionView, um den Kernel.caller.count zu loggen, so dass ich sehen konnte, ob ein Stack wuchs und wuchs, aber ich sehe das nicht. Ich sehe Stapeltiefen so hoch wie 180. Es scheint nicht wichtig zu sein, wenn ich den Stack größer mache, bevor ich mit den Rails starte, aber vielleicht gibt etwas den Stack wieder zurück.

In _list_pagination.html.erb ruft es list_pagination_links auf. Wenn ich das ausrufe, dann scheitern die Dinge nicht. Ich habe versucht, list_pagination_links nichts zu tun (Code nicht drin!), Aber es ist immer noch bei diesem Render-Aufruf gestorben. Ich frage mich, ob es im Render-Code selbst ist, dass der Stack entweder rekursiv oder einfach zu groß ist.

Dies passiert nicht auf meinem Laptop (Debian-Sequeeze, 32-Bit) im Entwicklungsmodus, passiert aber auf meiner Beta-Produktionsmaschine (XEN VM, 32-Bit, debian Squeeze). Es kam manchmal auf meinem Laptop vor, aber nicht in einer wiederholbaren Art und Weise, und das Neustarten der Schienen löste die Probleme. Ich habe den Produktionsmodus noch nicht auf meinem Laptop versucht, und ich vermute auch, dass es datenabhängig sein kann!

Answer 1

Eine verzweifelte Debugging-Methode, die für diese Fälle nützlich ist, die ich bei genau demselben Problem entdeckt habe, ist die set_trace_func-Methode des Kernels.

Es legt grundsätzlich eine Methode fest, die nach jedem Interpreter "Aktion" aufgerufen wird. Wenn Sie dies verwenden, um einige Informationen zu drucken, dann kann es ziemlich ausführlich werden, Ihr Programm wird ärgerlich langsam, aber Sie können genau sehen, was vor sich geht. Und wenn es sich wirklich um eine unendliche Rekursion handelt, dann würde der Name der Funktion, die sich falsch verhalten hat, den Bildschirm in Sekundenschnelle füllen.

Ein Beispiel für den Einsatz in Ihrem Fall wären:

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

ps: Ich weiß, dass dies nicht eine Antwort im eigentlichen Sinne ist, aber es war zu lange ein posten Kommentar

Answer 2

Wenn ich die unendliche Paging-Problem in Active Scaffold Debuggen wurde, habe ich hinzugefügt:

require 'active_scaffold/extensions/paginator_extensions' 

zu meinem Code. Diese Linie scheint die Ursache zu sein. Ich weiß nicht warum.

git Halbierung und Zeile für Zeile Entfernung des Codes gefunden dies.