[Catalyst] Dumper bugs (or why each() is dangerous full stop)
Matt S Trout
dbix-class at trout.me.uk
Mon May 22 01:29:04 CEST 2006
Bernhard Graf wrote:
> Hello,
>
> today I encountered a really annoying behaviour (= potential bug) in
> Catalyst:
>
> I was writing a plugin that occasionally modifies
> $c->request->body_parameters and $c->request->query_parameters .
>
> This is done by defining a method prepare_body_parameters() in the
> plugin, expecting prepare_parameters() to run later to merge body and
> query parameters into $c->request->parameters().
>
> But prepare_parameters() fails, because it uses each(). each() uses an
> internal iterator. Previous modifications to the query & body params
> might leave iterators of these hashes at a random position, probably
> at the end - as a consequence the while ( ... each ...) loops aren't
> executed at all.
This isn't normally a problem with correctly-written code.
Unfortunately, the XSUB version of Data::Dumper is not correctly
written; if the sortkeys option is set, which it generally is for
Catalyst debug output, this can leave the each() iterator in an
incorrect position thus causing the exact behaviour you described.
And of course anybody else's buggy code can cause the same problem,
including your own.
DBIx::Class has had a cleanup job where I removed the (sum total two)
instances of each that had crept in; the Catalyst core should probably
get the same.
My general rule of thumb is "unless you own the hash and never pass it
anywhere else, don't use each() unless you reset the iteration position
with keys in void context first."
More information about the Catalyst
mailing list