Re: [perl #25960] [PATCH] COWed stack bug (was IMCC - PerlArray getting trounced)

2004-02-24 Thread Leopold Toetsch 
Luke Palmer [EMAIL PROTECTED] wrote:
 Leopold Toetsch writes:

 As already stated:
 - COWed buffers need distinct buffer headers pointing to the same
   buffer memory
 - unCOWing (regstack_copy_chunk) allocates new buffer memory and
   resets the COW flag

 I headed in to fix this when I saw some new stuff in there.   Has this
 been fixed?

Yep. I can't find any more trails of memory corruption. COW copy of
stacks is rewritten totally, s. stack_common.c.

 Luke

leo

Re: [perl #25960] [PATCH] COWed stack bug (was IMCC - PerlArray getting trounced)

2004-02-23 Thread Luke Palmer 
Leopold Toetsch writes:
 Matt Fowles [EMAIL PROTECTED] wrote:
 
  This patch make the problem case submitted by Jeff Clites work.  All
  tests pass, and his sample has been added to the tests.
 
   struct RegisterChunkBuf* top = stack-top;
   if (top-used  1) {
  +top-used--;
 
 Thanks for the patch *but*:
 
 That's changing the COWed copy. It does the right thing for the test
 case but is still wrong.
 
 As already stated:
 - COWed buffers need distinct buffer headers pointing to the same
   buffer memory
 - unCOWing (regstack_copy_chunk) allocates new buffer memory and
   resets the COW flag

I headed in to fix this when I saw some new stuff in there.   Has this
been fixed?

Luke

[perl #25960] [PATCH] COWed stack bug (was IMCC - PerlArray getting trounced)

2004-02-04 Thread via RT 
# New Ticket Created by  Matt Fowles 
# Please include the string:  [perl #25960]
# in the subject line of all future correspondence about this issue. 
# URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=25960 


All~

This patch make the problem case submitted by Jeff Clites work.  All 
tests pass, and his sample has been added to the tests.

While I am not certain that this is the correct way to solve the 
problem, it seems good to me.

Matt
Index: imcc/t/syn/pcc.t
===
RCS file: /cvs/public/parrot/imcc/t/syn/pcc.t,v
retrieving revision 1.31
diff -u -r1.31 pcc.t
--- imcc/t/syn/pcc.t	20 Jan 2004 01:50:47 -	1.31
+++ imcc/t/syn/pcc.t	4 Feb 2004 02:55:11 -
@@ -1,6 +1,6 @@
 #!perl
 use strict;
-use TestCompiler tests = 34;
+use TestCompiler tests = 35;
 
 ##
 # Parrot Calling Conventions
@@ -1389,3 +1389,30 @@
 42.00
 OUT
 }
+
+output_is('CODE', 'OUT', COW handling on register stacks);
+.pcc_sub _main prototyped
+  $P1 = new PerlUndef
+  print $P1
+  print :
+  _outer()
+  print $P1
+  print \n
+  end
+.end
+.pcc_sub _outer prototyped
+  _inner()
+  .pcc_begin_return
+  .pcc_end_return
+.end
+.pcc_sub _inner prototyped
+  newsub $P1, .Exception_Handler, _ignore
+  .pcc_begin_return
+  .pcc_end_return
+.end
+.sub _ignore
+  noop
+.end
+CODE
+:
+OUT
Index: src/register.c
===
RCS file: /cvs/public/parrot/src/register.c,v
retrieving revision 1.41
diff -u -r1.41 register.c
--- src/register.c	25 Jan 2004 19:33:27 -	1.41
+++ src/register.c	4 Feb 2004 02:55:13 -
@@ -292,11 +292,11 @@
 {
 struct RegisterChunkBuf* top = stack-top;
 if (top-used  1) {
+top-used--;
 /* Before we change anything, is this a read-only stack? */
 if (PObj_COW_TEST((PObj*)top))
 top = stack-top =
 regstack_copy_chunk(interpreter, stack-top, stack);
-top-used--;
 }
 else {
 /* XXX: If this isn't marked COW, we should keep it around to

Re: [perl #25960] [PATCH] COWed stack bug (was IMCC - PerlArray getting trounced)

2004-02-04 Thread Leopold Toetsch 
Matt Fowles [EMAIL PROTECTED] wrote:

 This patch make the problem case submitted by Jeff Clites work.  All
 tests pass, and his sample has been added to the tests.

  struct RegisterChunkBuf* top = stack-top;
  if (top-used  1) {
 +top-used--;

Thanks for the patch *but*:

That's changing the COWed copy. It does the right thing for the test
case but is still wrong.

As already stated:
- COWed buffers need distinct buffer headers pointing to the same
  buffer memory
- unCOWing (regstack_copy_chunk) allocates new buffer memory and
  resets the COW flag

Its like string.c: make_COW_reference() and unmake_COW()

This is needed for the register stacks and for stacks.c too.

leo

Re: IMCC - PerlArray getting trounced

2004-01-29 Thread Will Coleda 
Sorry about the delay in responding.

My current sample program is 2760 lines of imcc in 23 files, plus a 
small .tcl script.

I'll see if I can trim that down to a more reasonable test case.

On Monday, January 26, 2004, at 05:32  AM, Leopold Toetsch wrote:

Will Coleda [EMAIL PROTECTED] wrote:
I'm trying to track down a problem with a PerlArray that is getting
modified on me.

I have a snippet of code like:
Could you please provide a complete program, that imposes the bug?

leo


--
Will Coke Coledawill at coleda 
dot com

COWed stack bug (was: IMCC - PerlArray getting trounced)

2004-01-28 Thread Leopold Toetsch 
Will Coleda wrote:

Well, that was festive. I can reproduce that bug in 22 lines!
Great.

The bug (and other reported curruptions) are definitely coming from the 
COW logic in register.c. This is what happens:

Setting up the exception handler (which is a continuation) triggers COW 
setting of the register stacks. Then on first subroutine return from 
__inner, the register stack is unCOWed (the chunk is copied). When then 
returning from __outer stack-top-used is still 2 end the same chunk 
gets popped off the stack, because the interpreter's stack is still 
unchanged.

The register restoring memcpy is the same *twice*:

memcpy (dstpp=0x824ca50, srcpp=0x4017d9a0, len=64)

So returning from __outer places P17 (the RetContinuation of __inner) in 
mains registers and ruins the PerlUndef that you wanted to print.


:get_string() not implemented in class 'RetContinuation'
... which then causes this error.

Just returning from mark_register_stack_cow() makes the bug vanish 

(but doesn't fix anything)

As mentioned several times, a COWed buffer needs distinct buffer headers 
and shared buffer memory. The current implementation in register *and* 
other stacks is broken. *Fixes welcome*.

You can currently avoid the bug by not using Continuations and Exception 
Handlers.

Thanks for your test program,
leo

Re: IMCC - PerlArray getting trounced

2004-01-28 Thread Will Coleda 
Well, that was festive. I can reproduce that bug in 22 lines!

I expect the following code to print out a single colon (since 
PerlUndef prints as the empty string) and a newline. Instead, I get:

:get_string() not implemented in class 'RetContinuation'

which shows that the PerlUndef I assigned to $P1 in _main has morphed 
into a RetContinuation after the call to __outer in __main.

How to avoid tripping the bug:

1) call __inner from __main directly, instead of outer.
2) comment out the newsub line in __inner. (Or, convert the newsub to a 
$P1 = new PerlString\n$P1 = a, which may be a more useful example)

Note that I never actually set_eh the Exception Handler. I merely 
instantiate it and never call it. (Nor do I call __ignore -- I could 
change the IMC so that the handler called __outer instead of __ignore 
and drop the __ignore, but this is a little clearer, I think.)

I fully expect to be told I'm missing something obvious, which, since 
it's 1:30 in the morning, would be expected, but since I started 
tracking this down when it was still yesterday, would also be rather 
sad. =-)

.pcc_sub __main prototyped
  $P1 = new PerlUndef
  print $P1
  print :
  __outer()
  print $P1
  print \n
  end
.end
.pcc_sub __outer prototyped
   __inner()
  .pcc_begin_return
  .pcc_end_return
.end
.pcc_sub __inner prototyped
  newsub $P1, .Exception_Handler, __ignore
  .pcc_begin_return
  .pcc_end_return
.end
.sub __ignore
  noop
.end
On Tuesday, January 27, 2004, at 07:53  PM, Will Coleda wrote:

Sorry about the delay in responding.

My current sample program is 2760 lines of imcc in 23 files, plus a 
small .tcl script.

I'll see if I can trim that down to a more reasonable test case.

On Monday, January 26, 2004, at 05:32  AM, Leopold Toetsch wrote:

Will Coleda [EMAIL PROTECTED] wrote:
I'm trying to track down a problem with a PerlArray that is getting
modified on me.

I have a snippet of code like:
Could you please provide a complete program, that imposes the bug?

leo


--
Will Coke Coledawill at coleda 
dot com


--
Will Coke Coledawill at coleda 
dot com

Re: IMCC - PerlArray getting trounced

2004-01-26 Thread Leopold Toetsch 
Will Coleda [EMAIL PROTECTED] wrote:
 I'm trying to track down a problem with a PerlArray that is getting
 modified on me.

 I have a snippet of code like:

Could you please provide a complete program, that imposes the bug?

leo

Re: IMCC - PerlArray getting trounced

2004-01-25 Thread Luke Palmer 
Will Coleda writes:
 I'm trying to track down a problem with a PerlArray that is getting 
 modified on me.
 
 I have a snippet of code like:
 
   typeof $S12, tcl_words
   $I12 = tcl_words
   print TYPEOF: 
   print $S12
   print \n
   print SIZEOF: 
   print $I12
   print \n
   (var_start_at,var_length,var_replace_str) = 
 __var_subst(var_current_word)
   typeof $S12, tcl_words
   $I12 = tcl_words
   print TYPEOF: 
   print $S12
   print \n
   print SIZEOF: 
   print $I12
   print \n
 
 Which is displaying:
 
 TYPEOF: PerlArray
 SIZEOF: 7
 TYPEOF: PerlArray
 SIZEOF: 1
 
 if I do a saveall/restoreall around the call to __var_subst, then I get 
 the expected:
 
 TYPEOF: PerlArray
 SIZEOF: 7
 TYPEOF: PerlArray
 SIZEOF: 7
 
 But then my return values are trounced.
 
 Is this a bug, or just a misunderstanding on my part?

It looks okay to me, but that depends on what __var_subst actually does.
Any continuation magic could make this choke.  What if you try a
savetop/restoretop instead?  I'm not sure if that works, because I'm not
sure whether IMCC moves return values into high registers after a call.
Or you could use the user stack to save your return values.

Of course these are temporary fixes.  I'd like to see the code of
__var_subst, and perhaps a few functions that it in turn calls, if any. 

Luke

Re: IMCC - PerlArray getting trounced

2004-01-25 Thread Will Coleda 
If there's magic, it was an unintentional invocation. =-) If I was 
managing my own registers, I'd expect to have to save things - but 
since I'm always (I think) using .locals or the $Ifoo syntax, I'd 
expect IMCC to do the saving, since I have no way of knowing /which/ 
registers it's using for me. Unless, as you say, I should be doing an 
explicit, limited save/restore. It's this expectation that I was trying 
to gauge as unreasonable or not.

Attached, find the definition for __var_subst, and the one function it 
calls, __cmd_set (and the one macro /that/ includes, debug.)

(There are some commented out calls to _dumper (for printing out the 
contents of aggegrate PMCs), but the trouncing occurs without them.)




var_subst.imc
Description: Binary data



set.imc
Description: Binary data



debug.imc
Description: Binary data




On Sunday, January 25, 2004, at 02:28  AM, Luke Palmer wrote:

Will Coleda writes:
I'm trying to track down a problem with a PerlArray that is getting
modified on me.
I have a snippet of code like:

  typeof $S12, tcl_words
  $I12 = tcl_words
  print TYPEOF: 
  print $S12
  print \n
  print SIZEOF: 
  print $I12
  print \n
  (var_start_at,var_length,var_replace_str) =
__var_subst(var_current_word)
  typeof $S12, tcl_words
  $I12 = tcl_words
  print TYPEOF: 
  print $S12
  print \n
  print SIZEOF: 
  print $I12
  print \n
Which is displaying:

TYPEOF: PerlArray
SIZEOF: 7
TYPEOF: PerlArray
SIZEOF: 1
if I do a saveall/restoreall around the call to __var_subst, then I 
get
the expected:

TYPEOF: PerlArray
SIZEOF: 7
TYPEOF: PerlArray
SIZEOF: 7
But then my return values are trounced.

Is this a bug, or just a misunderstanding on my part?
It looks okay to me, but that depends on what __var_subst actually 
does.
Any continuation magic could make this choke.  What if you try a
savetop/restoretop instead?  I'm not sure if that works, because I'm 
not
sure whether IMCC moves return values into high registers after a call.
Or you could use the user stack to save your return values.

Of course these are temporary fixes.  I'd like to see the code of
__var_subst, and perhaps a few functions that it in turn calls, if any.
Luke


--
Will Coke Coledawill at coleda 
dot com

Re: IMCC - PerlArray getting trounced

2004-01-25 Thread Leopold Toetsch 
Will Coleda [EMAIL PROTECTED] wrote:

 If there's magic, it was an unintentional invocation. =-) If I was
 managing my own registers, I'd expect to have to save things - but
 since I'm always (I think) using .locals or the $Ifoo syntax, I'd
 expect IMCC to do the saving,

IMCC does provide the necessary savetop/restoretop register saving ops
around function calls.

Could you try to run your program with the -G command line option. If
that succeeds, the COWed register frame stack copy is the culprit.

leo

Re: IMCC - PerlArray getting trounced

2004-01-25 Thread Will Coleda 
Nope. If I turn on -G and leave off explicit savetop/restoretop, the 
perlArray is still stomped.

Regards.

On Sunday, January 25, 2004, at 09:29  AM, Leopold Toetsch wrote:

Will Coleda [EMAIL PROTECTED] wrote:

If there's magic, it was an unintentional invocation. =-) If I was
managing my own registers, I'd expect to have to save things - but
since I'm always (I think) using .locals or the $Ifoo syntax, I'd
expect IMCC to do the saving,
IMCC does provide the necessary savetop/restoretop register saving ops
around function calls.
Could you try to run your program with the -G command line option. If
that succeeds, the COWed register frame stack copy is the culprit.
leo


--
Will Coke Coledawill at coleda 
dot com

IMCC - PerlArray getting trounced

2004-01-24 Thread Will Coleda 
I'm trying to track down a problem with a PerlArray that is getting 
modified on me.

I have a snippet of code like:

  typeof $S12, tcl_words
  $I12 = tcl_words
  print TYPEOF: 
  print $S12
  print \n
  print SIZEOF: 
  print $I12
  print \n
  (var_start_at,var_length,var_replace_str) = 
__var_subst(var_current_word)
  typeof $S12, tcl_words
  $I12 = tcl_words
  print TYPEOF: 
  print $S12
  print \n
  print SIZEOF: 
  print $I12
  print \n

Which is displaying:

TYPEOF: PerlArray
SIZEOF: 7
TYPEOF: PerlArray
SIZEOF: 1
if I do a saveall/restoreall around the call to __var_subst, then I get 
the expected:

TYPEOF: PerlArray
SIZEOF: 7
TYPEOF: PerlArray
SIZEOF: 7
But then my return values are trounced.

Is this a bug, or just a misunderstanding on my part?

--
Will Coke Coledawill at coleda 
dot com