It looks like it might be some interaction between Parse::RecDescent and ActivePerl. A quick google search for "parse::recdescent errorprefix" yielded a number of ppm build error logs and a couple of references to use utf8. It looks like the utf8 issue was fixed in an earlier release (of Parse::RecDescent), and it also doesn't look like the code is explicitly working with utf8.

jethro showed that there's an issue with the grammar itself, so maybe PoorLuzer could try fixing up his grammar definition so that it passes, or whittling it down to the minimal case that causes the $errorprefix error.

Comment on Re^2: How to know where I am going wrong in writing the grammar

Warning (line 27): Found an error marker (<error>) after an uncond+itional
<error>
(Hint: An unconditional <error> always causes the prod+uction
containing it to immediately fail. An error mar+ker that
follows an <error> will never be reached. Did y+ou mean
to use <error?> instead?)
ERROR (line 1): Invalid startOfRecord: Was expecting RECORDSTAR+T

Variable "$errortext" is not available at c:/progs/perl5100/site/lib/P+arse/RecDescent.pm line 2917.
Variable "$errorprefix" is not available at c:/progs/perl5100/site/lib+/Parse/RecDescent.pm line 2917.
Use of uninitialized value $errorprefix in formline at c:/progs/perl51+00/site/lib/Parse/RecDescent.pm line 2850.
Use of uninitialized value $errortext in formline at c:/progs/perl5100+/site/lib/Parse/RecDescent.pm line 2850.
Use of uninitialized value $errortext in formline at c:/progs/perl5100+/site/lib/Parse/RecDescent.pm line 2852.
:

Warning (line 27): Found an error marker (<error>) after an uncond+itional
<error>
(Hint: An unconditional <error> always causes the prod+uction
containing it to immediately fail. An error mar+ker that
follows an <error> will never be reached. Did y+ou mean
to use <error?> instead?)
ERROR (line 1): Invalid startOfRecord: Was expecting RECORDSTAR+T

Update: I've never seen that error message before, so here's what diagnostics has to say about it:

(W closure) During compilation, an inner named subroutine or eval +is
attempting to capture an outer lexical that is not currently avail+able.
This can happen for one of two reasons. First, the outer lexical m+ay be
declared in an outer anonymous subroutine that has not yet been cr+eated.
(Remember that named subs are created at compile time, while anony+mous
subs are created at run-time.) For example,
sub { my $a; sub f { $a } }
At the time that f is created, it can't capture the current value +of $a,
since the anonymous subroutine hasn't been created yet. Conversely+,
the following won't give a warning since the anonymous subroutine +has by
now been created and is live:
sub { my $a; eval 'sub f { $a }' }->();
The second situation is caused by an eval accessing a variable tha+t has
gone out of scope, for example,
sub f {
my $a;
sub { eval '$a' }
}
f()->();
Here, when the '$a' in the eval is being compiled, f() is not curr+ently being
executed, so its $a is not available for capture.