• Daniel Keep (31/35) Mar 17 2009 Hi all.
• Gide Nwawudu (5/40) Mar 18 2009 This might be the same issue.

Daniel Keep <daniel.keep.lists gmail.com> writes:

Hi all.

I can't seem to get this to work properly.  I'm trying to write a
copy-on-write proxy type.  I'm using postblit and dtors along with the
usual ctors and opAssign to manage the refcount of the shared memory.
However, testing with dmd-2.026 (and a few previous versions a little
while ago), the attached program gives me the following output:

(NB: ">" means entering, "<" means leaving; these messages are printed
from in- and out-contracts.  Printed values are the array being stored
and the ref count (or zero if the ref count pointer is null.))

 opAssign(T[]);            COWArray(0x    0000[0..0])   0
 ~this();                  COWArray(0x  12FE88[0..4424652])   1245120

< ~this();                  COWArray(0x  12FE88[0..4424652])   1245119
< opAssign(T[]);            COWArray(0x  AA2E40[0..4])   1
 this(this);               COWArray(0x  AA2E40[0..4])   1

< this(this);               COWArray(0x  AA2E40[0..4])   2
a: [1,2,3,4]
 ~this();                  COWArray(0x  AA2E40[0..4])   2

< ~this();                  COWArray(0x  AA2E40[0..4])   1

For the following code:

void main()
{
    COWArray!(int) a;
    a = [1,2,3,4];

    // This shouldn't affect ref counts
    auto a_str = a.toString;
    writefln("a: %s", a_str);
}

As you can see, it correctly enters opAssign and leaves with the correct
array reference and ref count.  However, it also spuriously calls the
destructor with what appears to be a random pointer.  It then calls the
postblit when it shouldn't be doing so, resulting in the refcount being
one too high.

I've attached the full source (compile with -debug); does anyone know
what I'm doing wrong, or whether this is a compiler bug?

  -- Daniel

Gide Nwawudu <gide btinternet.com> writes:

On Wed, 18 Mar 2009 17:32:56 +1100, Daniel Keep
<daniel.keep.lists gmail.com> wrote:

Hi all.

I can't seem to get this to work properly.  I'm trying to write a
copy-on-write proxy type.  I'm using postblit and dtors along with the
usual ctors and opAssign to manage the refcount of the shared memory.
However, testing with dmd-2.026 (and a few previous versions a little
while ago), the attached program gives me the following output:

(NB: ">" means entering, "<" means leaving; these messages are printed
from in- and out-contracts.  Printed values are the array being stored
and the ref count (or zero if the ref count pointer is null.))

 opAssign(T[]);            COWArray(0x    0000[0..0])   0
 ~this();                  COWArray(0x  12FE88[0..4424652])   1245120

< ~this();                  COWArray(0x  12FE88[0..4424652])   1245119
< opAssign(T[]);            COWArray(0x  AA2E40[0..4])   1
 this(this);               COWArray(0x  AA2E40[0..4])   1

< this(this);               COWArray(0x  AA2E40[0..4])   2
a: [1,2,3,4]
 ~this();                  COWArray(0x  AA2E40[0..4])   2

< ~this();                  COWArray(0x  AA2E40[0..4])   1

For the following code:

void main()
{
    COWArray!(int) a;
    a = [1,2,3,4];

    // This shouldn't affect ref counts
    auto a_str = a.toString;
    writefln("a: %s", a_str);
}

As you can see, it correctly enters opAssign and leaves with the correct
array reference and ref count.  However, it also spuriously calls the
destructor with what appears to be a random pointer.  It then calls the
postblit when it shouldn't be doing so, resulting in the refcount being
one too high.

I've attached the full source (compile with -debug); does anyone know
what I'm doing wrong, or whether this is a compiler bug?

  -- Daniel

This might be the same issue.
http://d.puremagic.com/issues/show_bug.cgi?id=2674

Gide