[perl #38406] [BUG] PGE - truncating PIR code generated by p6rule
Allison Randal
# Please include the string: [perl #38406]
# in the subject line of all future correspondence about this issue.
# <URL: https://rt.perl.org/rt3/Ticket/Display.html?id=38406 >
I've spent too much time on this error, so I'm routing around it, but
I'd love to figure out what's causing it. In my local version of
Punie I get this error when I run 'make test':
t/io_print.....ok 5/8
# Failed test (t/io_print.t at line 29)
# got: 'error:imcc:syntax error, unexpected $undefined,
expecting '\n'
# in file 'EVAL_8' line 67
# '
# expected: 'ok 1
# ok 2
# '
# './parrot languages/punie/punie.pbc /Volumes/lilalUFS/projects/svk/
parrot/languages/punie/t/io_print_6.p1' failed with exit code 18
(The error comes from line 3892 or 3897 of compilers/imcc/imcparser.c.)
Obviously it's a syntax error in some PIR code, and I thought it was
in the PIR code output by Punie. It turns out it's actually the PIR
code output by PGE for TGE's grammar parser. (I discovered this with
TEST_PROG_ARGS="-D20".) For some reason, the generated PIR code for
the 'skip' rule is truncated part-way through the 67th line. (The
rule is defined in compilers/tge/TGE/Parser.pir on line 32.)
The truncated rule code occurs when I run the test code through the
bytecode version of the Punie compiler, punie.pbc (running 'make
test' or 'perl t/io_print.t' or 'parrot languages/punie/punie.pbc
languages/punie/t/io_print_6.p1'). But, if I run t/io_print_6.p1
through punie.pir instead of the bytecode version, the rule code is
fully generated and I get no errors. (I recompiled several times just
to make sure they were simply compiled and source versions the same
code.) Also, if I modify the Punie compiler to dump out generated PIR
to a file before it executes it, I get no errors even on the bytecode
version.
Here are the relevant lines from the truncated rule code (the last 3
lines in the generated code):
65 R: ## 62
66
67 R62: #
And the corresponding lines from the fully generated rule code, and
several lines following:
65 R: ## 62
66
67 R62: # \s {0..2147483647}
68 $I0 = find_not_cclass 32, target, pos, lastpos
69 rep = $I0 - pos
70 if rep < 0 goto fail
71 if rep <= 2147483647 goto R62_1
72 rep = 2147483647
73 R62_1:
...
(Oh, the change that started the error was adding a single rule to
Punie's PGE grammar. It doesn't matter if the new rule gets called
from any other rule, or if the rule even has any content. The name of
the rule also doesn't impact the error (I had a problem before
defining a PGE rule named 'print', so I had to check).)
That's as far as I've debugged it so far. I'd welcome any thoughts on
the cause, or suggestions on ways to debug it further.
Thanks,
Allison
Leopold Toetsch
On Feb 2, 2006, at 2:33, Allison Randal (via RT) wrote:
> I've spent too much time on this error, so I'm routing around it, but
> I'd love to figure out what's causing it. In my local version of
> Punie I get this error when I run 'make test':
[ ... ]
> ... Also, if I modify the Punie compiler to dump out generated PIR
> to a file before it executes it, I get no errors even on the bytecode
> version.
While this all smells like a GC bug, I don't see it with r11401 on
darwin nor x86/linux. I've also run io_print_6 through valgrind on the
latter, which also doesn't show any indication re string truncation.
Anyway, if it's a GC bug, the following should succeed:
punie$ TEST_PROG_ARGS=-G make test
and
$ ./parrot -G languages/punie/punie.pbc
languages/punie/t/io_print_6.p1
> Thanks,
> Allison
leo
Larry Wall
:
As another datapoint on what *might* be the same bug, there are two
PGE failures I get regressing Pugs using embedded Parrot, saying
something like:
error:imcc:syntax error, unexpected ']'
in file 'EVAL_6' line 99
Which seems similar though not identical to Allison's error message.
Anyway, it still fails using TEST_PROG_ARGS=-G on the Pugs test, though
I don't know if the embedding interface examines TEST_PROG_ARGS.
And it could well be a Pugs bug, though the fact that that tests
pass with external rather than embedded Parrot seems to indicate not.
That's all FWIW. No time to pursue it further, unfortunately...
Larry
Patrick R. Michaud
>
> >I've spent too much time on this error, so I'm routing around it, but
> >I'd love to figure out what's causing it. In my local version of
> >Punie I get this error when I run 'make test':
>
> darwin nor x86/linux. I've also run io_print_6 through valgrind on the
> latter, which also doesn't show any indication re string truncation.
>
> Anyway, if it's a GC bug, the following should succeed:
>
> punie$ TEST_PROG_ARGS=-G make test
This may or may not be related, but I'm getting a segfault for
building PGE itself (x86_64/linux), when trying to run mklib.pir
to generate the built-in rules.
This is one of the first times I've tried any of this under
64-bit linux, so it might be totally unrelated. At any rate,
I've *finally* gotten many of my other tasks out of the way so
I'm back on the case. :-)
Pm
Jerry Gay
> On Thu, Feb 02, 2006 at 11:33:25AM +0100, Leopold Toetsch wrote:
> > On Feb 2, 2006, at 2:33, Allison Randal (via RT) wrote:
> >
> > >I've spent too much time on this error, so I'm routing around it, but
> > >I'd love to figure out what's causing it. In my local version of
> > >Punie I get this error when I run 'make test':
> >
> > While this all smells like a GC bug, I don't see it with r11401 on
> > darwin nor x86/linux. I've also run io_print_6 through valgrind on the
> > latter, which also doesn't show any indication re string truncation.
> >
> > Anyway, if it's a GC bug, the following should succeed:
> >
> > punie$ TEST_PROG_ARGS=-G make test
>
> This may or may not be related, but I'm getting a segfault for
> building PGE itself (x86_64/linux), when trying to run mklib.pir
> to generate the built-in rules.
>
> This is one of the first times I've tried any of this under
> 64-bit linux, so it might be totally unrelated. At any rate,
>
cd compilers/pge && ../../parrot -t mklib.pir >PGE/Library.pir
near the end of it's output, reports:
[snip]
3229 callmethodcc P0, "genfixedstr" - P0=Object(PGE::Exp::Literal)=PMC(0x417
020),
1973 get_params PMC_C[266] (7), P2, P0, S3, S2, S5, S4, S0 - , P2=PMCNULL,
P0=PMCNULL, , , , ,
1982 set_args PMC_C[24] (1), P2 - , P2=Object(PGE::Exp::Literal)=PMC(0x4
17020)
1985 get_results PMC_C[236] (5), I3, I0, I4, I1, S-1 - , I3=0, I0=2,
I4=1, I1=0, S-1="(null)"
1992 callmethodcc P2, "quant" - P2=Object(PGE::Exp::Literal)=PMC(0x417
020),
1898 get_params PMC_C[24] (1), P0 - , P0=PMCNULL
[snip]
what the heck is register "S-1" in the get_results op??
when parrot got infinite registers, i don't think that meant they
could be negative, too :)
maybe that'll help track things down.
> I've *finally* gotten many of my other tasks out of the way so
> I'm back on the case. :-)
>
yay! welcome back.
~jerry
Leopold Toetsch
> This may or may not be related, but I'm getting a segfault for
> building PGE itself (x86_64/linux), when trying to run mklib.pir
> to generate the built-in rules.
Yep. Working on that currently. I've simplied it to this testcase now:
.sub main :method
.local int a
(a,$S0) = self."foo"()
self."bar"()
.end
This isn't runnable per se it dies of course with method not found. But
it's revealing that both 'a' and '$S0' aren't getting any register (#
-1) assigned. Both symbols are missing from the symbol list;
$ parrot -dff -tf c.pir 2>&1 | less
This might be some reason for further PGE errors or not, I'm still
investigating the real problem, which just got unhidden by r11402.
> Pm
leo
Patrick R. Michaud
> > This may or may not be related, but I'm getting a segfault for
> > building PGE itself (x86_64/linux), when trying to run mklib.pir
> > to generate the built-in rules.
> >
> i'm getting this, too, on win32. as are others, i think, on many platforms.
>
> > This is one of the first times I've tried any of this under
> > 64-bit linux, so it might be totally unrelated. At any rate,
> >
> cd compilers/pge && ../../parrot -t mklib.pir >PGE/Library.pir
>
> near the end of it's output, reports:
>
> 020),
> 1973 get_params PMC_C[266] (7), P2, P0, S3, S2, S5, S4, S0 - , P2=PMCNULL,
> P0=PMCNULL, , , , ,
> 1982 set_args PMC_C[24] (1), P2 - , P2=Object(PGE::Exp::Literal)=PMC(0x4
> 17020)
> 1985 get_results PMC_C[236] (5), I3, I0, I4, I1, S-1 - , I3=0, I0=2,
> I4=1, I1=0, S-1="(null)"
> 1992 callmethodcc P2, "quant" - P2=Object(PGE::Exp::Literal)=PMC(0x417
> 020),
> 1898 get_params PMC_C[24] (1), P0 - , P0=PMCNULL
> [snip]
>
> what the heck is register "S-1" in the get_results op??
> when parrot got infinite registers, i don't think that meant they
> could be negative, too :)
*Very* interesting -- I got the same problem. The call
that generates the above is
(min, max, islazy, iscut, $S0) = self."quant"()
where the $S0 is a dummy register that isn't used anywhere
else in the subroutine. If I convert this to a real
register, as in
(min, max, islazy, iscut, S8) = self."quant"()
then the segfault goes away. (Through judicious print
statements I was also able to narrow the problem
down to this specific call.)
I see the "-1" registers appear elsewhere in the output,
for example, the following call has $I2 and $I3
which aren't used in the rest of the subroutine:
($I0, $I1, $I2, $I3, $S0) = self."quant"()
It produces:
3165 set_args PMC_C[24] (1), P0 - , P0=Object(PGE::Exp::Literal)=PMC(0x906d10)
3168 get_results PMC_C[236] (5), I1, I0, I-1, I-1, S0 - , I1=0, I0=0, I-1=17, I-1=17,
3175 callmethodcc P0, "quant" - P0=Object(PGE::Exp::Literal)=PMC(0x906d10),
If I need to be doing something else for parameter placeholders,
let me know. I haven't tried the absolute register version
(that doesn't segfault for me) on Allison's code yet, I'll work
on that next.
Pm
Leopold Toetsch
> .sub main :method
> .local int a
> (a,$S0) = self."foo"()
> self."bar"()
> .end
and
> ... get_results PMC_C[236] (5), I3, I0, I4, I1, S-1
This is solved now with r11408 / r11409.
leo
Patrick R. Michaud
> # New Ticket Created by Allison Randal
> # Please include the string: [perl #38406]
> # in the subject line of all future correspondence about this issue.
> # <URL: https://rt.perl.org/rt3/Ticket/Display.html?id=38406 >
>
>
> I've spent too much time on this error, so I'm routing around it, but
> I'd love to figure out what's causing it. In my local version of
> Punie I get this error when I run 'make test':
...as of r11409, I'm not seeing the 'make test' error for punie
(on my Linux/x86_64 box).
I don't know if this is because it's now working, or because you've
routed around the particular problem you were seeing, so let
me know if you're still getting the error and I'll look into it
right away. I definitely would like to make sure it's not a PGE
issue. :-)
Pm