Bernhard Schmalhofer (via RT) wrote: > # New Ticket Created by Bernhard Schmalhofer > # Please include the string: [perl #45109] > # in the subject line of all future correspondence about this issue. > # <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=45109 > > > > In languages/lisp/system.pir there are 4 unused PMCs declared. > Removing one of them breaks Lisp. > > Here is an example session: > > [EMAIL PROTECTED]:~/devel/Parrot/repos/parrot/languages/lisp$ svn diff > Index: system.pir > =================================================================== > --- system.pir (Revision 20981) > +++ system.pir (Arbeitskopie) > @@ -24,7 +24,6 @@ > .local pmc dummy_1 > .local pmc dummy_2 > .local pmc dummy_3 > - .local pmc dummy_4 > > _init_reader_macros( package ) > > [EMAIL PROTECTED]:~/devel/Parrot/repos/parrot/languages/lisp$ ../../parrot > lisp.pbc t/arithmetics_1.l > wrong number of arguments to %GET-OBJECT-ATTRIBUTE > current instr.: '_error' pc 2065 (read.pir:194) > called from Sub '_get_object_attr' pc 7321 (system.pir:12) > called from Sub '_setq' pc 14048 (cl.pir:941) > called from Sub '_load' pc 7021 (system.pir:436) > called from Sub '_common_lisp' pc 17015 (lisp.pir:77) > [EMAIL PROTECTED]:~/devel/Parrot/repos/parrot/languages/lisp$ uname -a > Linux clou 2.6.20-16-386 #2 Thu Jun 7 20:16:13 UTC 2007 i686 GNU/Linux > [EMAIL PROTECTED]:~/devel/Parrot/repos/parrot/languages/lisp$ cat /etc/issue > Ubuntu 7.04 \n \l > > [EMAIL PROTECTED]:~/devel/Parrot/repos/parrot/languages/lisp$ > > My guess is that this is GC-related, but I haven't verified or falsified > that yet.
I've had a first look at this and I think it's a problem in the compiler. Here's a disassembly comparison between the current version, with the workaround, and a version without ".local pmc dummy_4," as in the diff above. --- lisp.pbc.workaround 2007-09-01 17:02:22.000000000 +0200 +++ lisp.pbc.bad 2007-09-01 17:02:05.000000000 +0200 @@ -1308,8 +1308,8 @@ 0fc1: 00000025 00000015 get_results_pc 0fc3: 00000262 00000006 00000177 callmethodcc_p_sc 0fc6: 000002bb 00000003 00000045 new_p_sc - 0fc9: 0000032f 00000012 000001c0 set_p_pc - 0fcc: 000002a6 00000003 00000047 00000012 setattribute_p_sc_p + 0fc9: 0000032f 00000013 000001c0 set_p_pc + 0fcc: 000002a6 00000003 00000047 00000013 setattribute_p_sc_p 0fd0: 000002bb 0000001a 00000035 new_p_sc 0fd3: 00000336 0000001a 00000168 set_p_sc 0fd6: 00000024 0000000d set_args_pc @@ -1325,8 +1325,8 @@ 0ff6: 00000025 00000015 get_results_pc 0ff8: 00000262 00000006 0000008f callmethodcc_p_sc 0ffb: 000002bb 00000003 00000045 new_p_sc - 0ffe: 0000032f 00000011 000001c4 set_p_pc - 1001: 000002a6 00000003 00000047 00000011 setattribute_p_sc_p + 0ffe: 0000032f 00000012 000001c4 set_p_pc + 1001: 000002a6 00000003 00000047 00000012 setattribute_p_sc_p 1005: 000002bb 0000001a 00000035 new_p_sc 1008: 00000336 0000001a 00000169 set_p_sc 100b: 00000024 0000000d set_args_pc @@ -1342,7 +1342,7 @@ 102b: 00000025 00000015 get_results_pc 102d: 00000262 00000006 0000008f callmethodcc_p_sc 1030: 000002bb 00000003 00000045 new_p_sc - 1033: 0000032f 00000013 000001b2 set_p_pc + 1033: 0000032f 00000011 000001b2 set_p_pc 1036: 000002a6 00000003 00000047 00000013 setattribute_p_sc_p 103a: 000002bb 0000001a 00000035 new_p_sc 103d: 00000336 0000001a 00000161 set_p_sc In all three sections a value is loaded into a register and then set as an attribute on an object. In the first hunk only the used register is changed from 0x12 to 0x13. In the second hunks it's register 0x11 to 0x12. With hunk three it's getting interesting because only the first occurrence changes from 0x13 to 0x11. set_attribute still uses 0x13, which is wrong I think. In the end, the wrong (Sub) value is put into the object's attribute because the wrong register is used. The error that comes up later is not because the arguments are wrong, but because the wrong sub is called. Can anyone tell if I'm on the right track? Ron
