Re: [perl #45109] [Lisp] Breakage when an unused PMC is removed
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.0 +0200 +++ lisp.pbc.bad2007-09-01 17:02:05.0 +0200 @@ -1308,8 +1308,8 @@ 0fc1: 0025 0015 get_results_pc 0fc3: 0262 0006 0177 callmethodcc_p_sc 0fc6: 02bb 0003 0045new_p_sc 0fc9: 032f 0012 01c0set_p_pc 0fcc: 02a6 0003 0047 0012 setattribute_p_sc_p 0fc9: 032f 0013 01c0set_p_pc + 0fcc: 02a6 0003 0047 0013 setattribute_p_sc_p 0fd0: 02bb 001a 0035new_p_sc 0fd3: 0336 001a 0168set_p_sc 0fd6: 0024 000d set_args_pc @@ -1325,8 +1325,8 @@ 0ff6: 0025 0015 get_results_pc 0ff8: 0262 0006 008f callmethodcc_p_sc 0ffb: 02bb 0003 0045new_p_sc - 0ffe: 032f 0011 01c4set_p_pc - 1001: 02a6 0003 0047 0011 setattribute_p_sc_p + 0ffe: 032f 0012 01c4set_p_pc + 1001: 02a6 0003 0047 0012 setattribute_p_sc_p 1005: 02bb 001a 0035new_p_sc 1008: 0336 001a 0169set_p_sc 100b: 0024 000d set_args_pc @@ -1342,7 +1342,7 @@ 102b: 0025 0015 get_results_pc 102d: 0262 0006 008f callmethodcc_p_sc 1030: 02bb 0003 0045new_p_sc - 1033: 032f 0013 01b2set_p_pc + 1033: 032f 0011 01b2set_p_pc 1036: 02a6 0003 0047 0013 setattribute_p_sc_p 103a: 02bb 001a 0035new_p_sc 103d: 0336 001a 0161set_p_sc
Re: [perl #45109] [Lisp] Breakage when an unused PMC is removed
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.0 +0200 +++ lisp.pbc.bad2007-09-01 17:02:05.0 +0200 @@ -1308,8 +1308,8 @@ 0fc1: 0025 0015 get_results_pc 0fc3: 0262 0006 0177 callmethodcc_p_sc 0fc6: 02bb 0003 0045new_p_sc - 0fc9: 032f 0012 01c0set_p_pc - 0fcc: 02a6 0003 0047 0012 setattribute_p_sc_p + 0fc9: 032f 0013 01c0set_p_pc + 0fcc: 02a6 0003 0047 0013 setattribute_p_sc_p 0fd0: 02bb 001a 0035new_p_sc 0fd3: 0336 001a 0168set_p_sc 0fd6: 0024 000d set_args_pc @@ -1325,8 +1325,8 @@ 0ff6: 0025 0015 get_results_pc 0ff8: 0262 0006 008f callmethodcc_p_sc 0ffb: 02bb 0003 0045new_p_sc - 0ffe: 032f 0011 01c4set_p_pc - 1001: 02a6 0003 0047 0011 setattribute_p_sc_p + 0ffe: 032f 0012 01c4set_p_pc + 1001: 02a6 0003 0047 0012 setattribute_p_sc_p 1005: 02bb 001a 0035new_p_sc 1008: 0336 001a 0169set_p_sc 100b: 0024 000d set_args_pc @@ -1342,7 +1342,7 @@ 102b: 0025 0015 get_results_pc 102d: 0262 0006 008f callmethodcc_p_sc 1030: 02bb 0003 0045new_p_sc - 1033: 032f 0013 01b2set_p_pc + 1033: 032f 0011 01b2set_p_pc 1036: 02a6 0003 0047 0013 setattribute_p_sc_p 103a: 02bb 001a 0035new_p_sc 103d: 0336 001a 0161set_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
Re: What should Configure.pl do when one of its steps fail?
On 02/09/07, James E Keenan [EMAIL PROTECTED] wrote: On Sep 1, 2007, at 1:58 PM, Gabor Szabo wrote: One thing though, I think it would be really good if at least the exit code of the script would be something different from 0 when any of the steps failed. That will be very important when we try to integrate with the PG Build Farm or any other fully automated smoke test suite to make sure we won't go on when the configuration step fails. While I personally have no big problem with the current setup, Gabor raises an interesting point. Could we get some discussion of the pros and cons of different alternatives? -- Should Configure.pl die when one of its steps fail? -- Should it not die, but exit with a nonzero exit code? -- Should it not die, but trigger a different message on STDOUT? -- Or is the current setup, on balance, best suited for our needs? There are definitely cases in which we should barf, although I'm not sure if we should *always* barf. For instance, if Configure.pl can't find a C-compiler there isn't much use in continuing, however, to continue is the current behaviour. I have the vague feeling that this question has been raised before, but no firm answer has arisen... Just my 0.02 Euro. Paul
Re: [perl #44967] Using a freed variable (Coverity CID 98)
On 01/09/07, Ron Blaschke [EMAIL PROTECTED] wrote:
Paul Cochrane wrote:
I've had a chance to look at this and the implementation looks quite
good to me.
There's one thing that still bothers me. The snipped output is:
Event alias: aliasing (ins)-next with ins2
Also see events: [freed_arg][use_after_free]
At conditional (1): ins2 != 0 taking true path
512 for (ins2 = ins-next; ins2; ins2 = ins2-next) {
...
Event freed_arg: Pointer ins2 freed by function subst_ins [model]
Also see events: [alias][use_after_free]
536 subst_ins(unit, ins2, tmp, 1);
There's Also see events: [freed_arg][use_after_free] and there's a
line saying Event freed_arg: ...
Then there's Also see events: [alias][use_after_free] and a line
saying Event alias: ...
This makes we wonder if there's any line saying Event use_after_free:
... in the report?
Thanks,
Ron
Ron,
Here's the full report (given within the context of the code). I
don't know if this helps, however, I do believe it is time you got an
account on Coverity Prevent yourself :-) You'll need to send an email
to [EMAIL PROTECTED] to get an account.
Paul
479 static int
480 constant_propagation(Interp *interp, IMC_Unit * unit)
481 {
482 Instruction *ins, *ins2, *tmp, *prev;
483 int op;
484 int i;
485 char fullname[128];
486 SymReg *c, *old, *o;
487 int any = 0;
488 int found;
489
490 o = c = NULL; /* silence compiler uninit warning */
491
492 IMCC_info(interp, 2, \tconstant_propagation\n);Event
use_after_free: Using freed pointer (ins)-next
Also see events: [alias][freed_arg]
493 for (ins = unit-instructions; ins; ins = ins-next) {
494 found = 0;
495 if (!strcmp(ins-op, set)
496 ins-opsize == 3 /* no keyed set */
497 ins-r[1]-type == VTCONST
498 ins-r[0]-set != 'P') {/* no PMC consts */
499 found = 1;
500 c = ins-r[1];
501 o = ins-r[0];
502 } else if (!strcmp(ins-op, null) ins-r[0]-set == 'I') {
503 found = 1;
504 c = mk_const(interp, str_dup(0), 'I');
505 o = ins-r[0];
506 } /* this would be good because 'set I0, 0' is reduced
to 'null I0'
507before it gets to us */
508
509 if (found) {
510 IMCC_debug(interp, DEBUG_OPT2,
511 propagating constant %I = \n, ins);Event
alias: aliasing (ins)-next with ins2
Also see events: [freed_arg][use_after_free]
At conditional (1): ins2 != 0 taking true path
512 for (ins2 = ins-next; ins2; ins2 = ins2-next) {At
conditional (2): (ins2)-type 16777216 != 0 taking false path
At conditional (3): (ins2)-bbindex != (ins)-bbindex taking false path
513 if (ins2-type ITSAVES ||
514 /* restrict to within a basic block */
515 ins2-bbindex != ins-bbindex)
516 goto next_constant;
517 /* was opsize - 2, changed to n_r - 1
518 */At conditional (4): i = 0 taking true path
At conditional (8): i = 0 taking true path
At conditional (14): i = 0 taking true path
519 for (i = ins2-n_r - 1; i = 0; i--) {At
conditional (5): strcmp == 0 taking true path
At conditional (9): strcmp == 0 taking true path
At conditional (15): strcmp == 0 taking true path
520 if (!strcmp(o-name, ins2-r[i]-name)) {At
conditional (6): instruction_writes != 0 taking false path
At conditional (10): instruction_writes != 0 taking false path
At conditional (16): instruction_writes != 0 taking true path
521 if (instruction_writes(ins2,ins2-r[i]))
522 goto next_constant;At conditional
(7): instruction_reads != 0 taking false path
At conditional (11): instruction_reads != 0 taking true path
523 else if (instruction_reads(ins2,ins2-r[i])) {
524 IMCC_debug(interp, DEBUG_OPT2,
525 \tpropagating into %I register %i,
526 ins2, i);
527 old = ins2-r[i];
528 ins2-r[i] = c;
529/* first we try subst_constants for e.g. if 10 5 goto next*/
530 tmp = IMCC_subst_constants(interp,
531 unit, ins2-op, ins2-r, ins2-opsize,
532 found);At conditional (12):
found != 0 taking true path
533 if (found) {
534 prev = ins2-prev;At conditional
(13): prev != 0 taking true path
535
Re: [PATCH] Re: perl Configure.pl --gc=malloc does not build either
Andrew Dougherty wrote: Meanwhile, this patch should clean up some bit rot and document it all a little better. Thanks, applied. Allison
Re: [perl #45109] [Lisp] Breakage when an unused PMC is removed
Ron Blaschke via RT schrieb: 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? Yes, I can see the pattern. One possibility to verify this, is to add a 'dummy_5' PMC. I'd expect three hunks again, but the third hunk should than conform to the two first hunks. Is this a register allocator bug? Regards, Bernhard
Re: [perl #45109] [Lisp] Breakage when an unused PMC is removed
Bernhard Schmalhofer wrote:
Ron Blaschke via RT schrieb:
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?
Yes, I can see the pattern. One possibility to verify this, is to add a
'dummy_5' PMC.
I'd expect three hunks again, but the third hunk should than conform to
the two first hunks.
Here's what happens if .local pmc dummy_5 is added, compared to the
current repository version with .local pmc dummy_[1-4].
--- lisp.pbc.workaround 2007-09-01 17:02:22.0 +0200
+++ lisp.pbc.workaround22007-09-02 20:24:32.0 +0200
@@ -1445,7 +1445,7 @@
116b: 0262 0006 008f
callmethodcc_p_sc
116e: 02bb 0003 0045new_p_sc
1171: 032f 0019 01a2set_p_pc
- 1174: 02a6 0003 0047 0019
setattribute_p_sc_p
+ 1174: 02a6 0003 0047 0011
setattribute_p_sc_p
1178: 02bb 001a 0035new_p_sc
117b: 0336 001a 015dset_p_sc
117e: 0024 000d set_args_pc
Is this a register allocator bug?
Not sure yet. I think I've found the source that corresponds to the
opcodes. It's CFUNCTION in Finclude/macros/types.pir.
#.macro FUNCTION(F,L)
#
#.F = new LispFunction
116e: 02bb 0003 0045new_p_sc
== new, P3, constant 0x45 (LispFunction)
#.const .Sub _func = .L
1171: 032f 0019 01a2set_p_pc
== set P25, ???
#setattribute .F, body, _func
1174: 02a6 0003 0047 0019setattribute_p_sc_p
== setattribute P3, constant 0x47 (body), P25
# but when this go bad:
1174: 02a6 0003 0047 0011setattribute_p_sc_p
== setattribute P3, constant 0x47 (body), P17
#
#.endm
The constants (0x45 and 0x47) are indexes into the constant pool.
# 69:
[ 'PFC_STRING', {
FLAGS= 0x61100,
CHARSET = 3961080,
SIZE = 12,
DATA = 'LispFunction'
} ],
# 71:
[ 'PFC_STRING', {
FLAGS= 0x61100,
CHARSET = 3961080,
SIZE = 4,
DATA = 'body'
} ],
The situation in the previous posting was this.
#.macro FUNCTION(F,L)
#
#.F = new LispFunction
1030: 02bb 0003 0045new_p_sc
== new, P3, constant 0x45 (LispFunction)
#.const .Sub _func = .L
1033: 032f 0013 01b2set_p_pc
== set P19, ???
# or:
1033: 032f 0011 01b2set_p_pc
== set P17, ???
#setattribute .F, body, _func
1036: 02a6 0003 0047 0013setattribute_p_sc_p
== setattribute P3, constant 0x47 (body), P19
#
#.endm
I'm currently trying to understand the code well enough to step through
this with a debugger when the instructions are generated.
Ron
duplicate symbols
not surprisingly, it looks like some symbols in libparrot conflict with exported symbols from other libraries. i ran into this when testing mod_parrot on an apache server with PHP 5 configured: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1077226080 (LWP 9187)] 0x4065c4a4 in list_length () from /usr/local/apache2/modules/libphp5.so (gdb) bt #0 0x4065c4a4 in list_length () from /usr/local/apache2/modules/libphp5.so #1 0x40b7f47a in visit_loop_todo_list (interp=0x825c488, current=0x0, info=0xb4e0) at src/pmc_freeze.c:1426 #2 0x40b7f781 in run_thaw (interp=0x825c488, image=0x840978c, what=VISIT_THAW_NORMAL) at src/pmc_freeze.c:1554 #3 0x40b7f9c6 in Parrot_thaw (interp=0x825c488, image=0x840978c) at src/pmc_freeze.c:1663 [snip] obviously parrot is looking for src/list.c:list_length, but instead gets PHP5's list_length, which is already loaded into apache. i'm sure this problem exists for other functions -- any ideas for how to address this? we could prepend a Parrot_ prefix for the PARROT_API functions (which list_length is), but that may not be appropriate for all situations. -jeff
Re: [PATCH] don't allow invalid --gc options
On Sat, 1 Sep 2007, Gabor Szabo wrote: It has biten me so let's make sure invalid --gc options are not allowed. But what if I want to work on --gc=libc? How can I override this? -- Andy Dougherty [EMAIL PROTECTED]
