dave_the_m just pushed a set of changes that should fix this. It seems the (deep) cause was an overflow of a sequence counter that reached a magic value.

1. p5git://commit=d1bfb649a8c4cc0b39b0fd6371c009b71c0b497f - changes PAD_MAX from I32_MAX to U32_MAX
2. p5git://commit=2df5bdd700b8a6ef036aa5be19d4bda9e3ca20bc - renames PAD_MAX to PERL_PADSEQ_INTRO, as the value is now used as a magic value to signify lexical variable introduction
3. p5git://commit=0d311cdbe540a08e243ac533c7bcdb73529352db - introduces (and documents) the states that an SV can have in a loop (I'm not sure I understand the mechanics involved here):

      COP_SEQ_RANGE_LOW        _HIGH
      -----------------        -----
      PERL_PADSEQ_INTRO            0   variable not yet introduced:   { m
   +y ($x
      valid-seq#   PERL_PADSEQ_INTRO   variable in scope:             { m
   +y ($x)
      valid-seq#          valid-seq#   compilation of scope complete: { m
   +y ($x) }
   [download]

4. p5git://commit=6012dc8015d0c5599f09bcca302ae714d023aced - allow the sequence number to wrap instead of reaching the magic value.
   Surprisingly, this patch touches a lot of places where I would have thought it would touch just the place where the sequence number is incremented. But it seems that the sequence number is incremented in several places.

Looking at the changes involved, I'm not sure whether the eval was necessary to trigger the bug, but that may be due to my lack of understanding the mechanics involved.