urgent parrot bug / PR opportunity

0 views
Skip to first unread message

Michal Wallace

unread,
Aug 3, 2005, 11:33:50 PM8/3/05
to perl6-i...@perl.org

Help! :)

Sam Ruby is giving a speech at OSCON tomorrow
about python on parrot.

The pirate tests run hourly against the latest
repository versions of pirate and parrot at:

http://pirate.tangentcode.com/

And wouldn't you know it... A bug on the parrot
side cropped up out of nowhere to break them!


Watch closely:

[~/pirate]: parrot listcomp.pir
[16, 26]
[~/pirate]: cp listcomp.pir now_it_works.pir
[~/pirate]: parrot now_it_works.pir
[15, 25, 16, 26]


The correct output is [15, 25, 16, 26] but
depending on the *filename* we sometimes get
the short version.

The python source is:

print [x+y for x in (1,2,3,4,5,6,7,8)
if x > 4
for y in (10,20)
if x < 7]

The generated pir code is at the end of this message.

Likewise, this code fails when the pir is read
from stdin (which is why pirate is failing).
On Sam's machine the "listcom.pir" filename
doesn't trigger the bug.

My guess is that something about the filename or
the argument list is changing parrot's behavior.

This is running against a freshly built copy
of parrot from subversion.

I don't have any clue where to look for this,
but if someone happens to know how to fix it
by tomorrow, I would really appreciate it, and
it would certainly leave the OSCON atendees with
a better impression of parrot!


- Michal
http://withoutane.com/


##############################################################

# generated by pirate on Wed Aug 3 23:02:54 2005

.sub __main__ @MAIN
new_pad 0
loadlib P1, 'python_group'
push_eh __py_catch
#
setline 1
new $P0, 'PyList' # (expressListComp:738)
new $P2, 'PyTuple' # (tupleExpression:354)
$P2=8 # (tupleExpression:355)
$P2[0]=1 # (tupleExpression:358)
$P2[1]=2 # (tupleExpression:358)
$P2[2]=3 # (tupleExpression:358)
$P2[3]=4 # (tupleExpression:358)
$P2[4]=5 # (tupleExpression:358)
$P2[5]=6 # (tupleExpression:358)
$P2[6]=7 # (tupleExpression:358)
$P2[7]=8 # (tupleExpression:358)
$P3 = iter $P2 # (visitFor:994)
for0:
unless $P3 goto endfor0 # (visitFor:1000)
$P4 = shift $P3 # (visitFor:1000)
store_lex -1, 'x', $P4 # (visitFor:1009)
setline 2
unless $P4 > 4 goto endif0 # (tupleExpression:354)
new $P5, 'PyTuple' # (tupleExpression:354)
$P5=2 # (tupleExpression:355)
$P5[0]=10 # (tupleExpression:358)
$P5[1]=20 # (tupleExpression:358)
$P6 = iter $P5 # (visitFor:994)
for1:
unless $P6 goto endfor1 # (visitFor:1000)
$P7 = shift $P6 # (visitFor:1000)
store_lex -1, 'y', $P7 # (visitFor:1009)
setline 4
find_lex $P8, 'x' # (lookupName:176)
unless $P8 < 7 goto endif1 # (infixExpression:423)
new $P9, 'PyObject' # (infixExpression:423)
$P9 = $P8 + $P7 # (infixExpression:428)
push $P0, $P9 # (visitListCompExpr:766)
endif1:
goto for1 # (goto:158)
endfor1:
endif0:
goto for0 # (goto:158)
endfor0:
print_item $P0 # (visitPrint:779)
print_newline # (visitPrintnl:787)
#
.return ()
__py_catch:
print_item P5
print_newline
.end

Will Coleda

unread,
Aug 3, 2005, 11:49:39 PM8/3/05
to Michal Wallace, perl6-i...@perl.org
Suggestions for workarounds given the short time frame:

1) Use the last *released* version of parrot, which is from a month
ago. If this is a new issue, just run the slightly older code.
(releases are happening once a month now. This will give you fairly
recent code with a little more stability.)
2) Try running with -G to see if it's a GC bug. If so, then just run
without GC for the presentation and we can try to figure out where
the bug is at a more leisurely pace. (I ran parrot with --gc-debug
and didn't trip anything, though.)
3) for the latest version, did you do a "make realclean;perl
Configure.pl;make" ? some changes require a realclean when they might
not ought to.

FWIW, I tried it here with a variety of filenames, all generate the
full list; as does piping the program to ./parrot -. (OSX, svn-latest)

Hope one of these helps.

Leopold Toetsch

unread,
Aug 4, 2005, 1:34:41 AM8/4/05
to Michal Wallace, perl6-i...@perl.org

On Aug 4, 2005, at 5:33, Michal Wallace wrote:

> Watch closely:
>
> [~/pirate]: parrot listcomp.pir
> [16, 26]
> [~/pirate]: cp listcomp.pir now_it_works.pir
> [~/pirate]: parrot now_it_works.pir
> [15, 25, 16, 26]

Which OS & architecture is this?

leo

Michal Wallace

unread,
Aug 4, 2005, 2:52:51 AM8/4/05
to Leopold Toetsch, perl6-i...@perl.org
On Thu, 4 Aug 2005, Leopold Toetsch wrote:

> Michal Wallace wrote:
>
>> And wouldn't you know it... A bug on the parrot
>> side cropped up out of nowhere to break them!
>
>

> ==17366== valgrind's libpthread.so: IGNORED call to: pthread_attr_destroy
> ==17366== Invalid read of size 4
> ==17366== at 0x43D5123E: Parrot_PyTuple_get_iter (in
> /home/lt/svn/parrot/leo/runtime/parrot/dynext/python_group.so)
> ==17366== by 0x8115576: Parrot_iter_p_p (ops/experimental.ops:231)
>
> Unfortunately valgrind doesn't show line numbers from the shared lib, but
> PyTuple.get_iter() is short enough so that you should be able to track down
> the problem.

Thanks, Leo!!

I'm afraid this is gibberish to me, but I gave it a shot.

I compared the code for pytuple to pylist and pystring
and noticed they use the python iterator instead of the
enum_class one. Also, pylist references in there several
times but it only appears once for pytuple, which can't
change its length. It looks like the other length tests
for pytuple use PMC_int_val instead so I changed that.
Anyway, I have no idea what I'm doing here but it seems
to have fixed the tests. I don't have commit access.

Assuming you don't see anything horribly wrong here,
would you mind applying this patch?

BTW, the problem is on red hat enterprise linux 3.0 with
a fresh build from subversion)

- Michal
http://withoutane.com/

Index: pytuple.pmc
===================================================================
--- pytuple.pmc (revision 8800)
+++ pytuple.pmc (working copy)
@@ -155,12 +155,12 @@
*/

PMC* get_iter () {
- PMC *iter = pmc_new_init(INTERP, enum_class_Iterator, SELF);
+ PMC *iter = pmc_new_init(INTERP, PyBuiltin_PyIter, SELF);
PMC *key = pmc_new(INTERP, enum_class_Key);
PMC_struct_val(iter) = key;
PObj_get_FLAGS(key) |= KEY_integer_FLAG;
PMC_int_val(key) = 0;
- if (!((List *) PMC_data(SELF))->length)
+ if (!((List *) PMC_int_val(SELF)))
PMC_int_val(key) = -1;
return iter;
}

Leopold Toetsch

unread,
Aug 4, 2005, 2:12:23 AM8/4/05
to Michal Wallace, perl6-i...@perl.org
Michal Wallace wrote:

> And wouldn't you know it... A bug on the parrot
> side cropped up out of nowhere to break them!

==17366== valgrind's libpthread.so: IGNORED call to: pthread_attr_destroy
==17366== Invalid read of size 4
==17366== at 0x43D5123E: Parrot_PyTuple_get_iter (in
/home/lt/svn/parrot/leo/runtime/parrot/dynext/python_group.so)
==17366== by 0x8115576: Parrot_iter_p_p (ops/experimental.ops:231)

Unfortunately valgrind doesn't show line numbers from the shared lib,
but PyTuple.get_iter() is short enough so that you should be able to
track down the problem.

leo

Leopold Toetsch

unread,
Aug 4, 2005, 3:28:16 AM8/4/05
to Michal Wallace, perl6-i...@perl.org
Michal Wallace wrote:

> + PMC *iter = pmc_new_init(INTERP, PyBuiltin_PyIter, SELF);

Done - r8801

> - if (!((List *) PMC_data(SELF))->length)
> + if (!((List *) PMC_int_val(SELF)))

~~~~~~~~~

Bogus. Changed to !SELF.elements()

leo

Reply all
Reply to author
Forward
0 new messages