http://d.puremagic.com/issues/show_bug.cgi?id=6178


Maxim Fomin <maxim@maxim-fomin.ru> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |maxim@maxim-fomin.ru


--- Comment #10 from Maxim Fomin <maxim@maxim-fomin.ru> 2012-12-13 09:59:34 PST ---
*** Issue 9084 has been marked as a duplicate of this issue. ***

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6178


SomeDude <lovelydear@mailmetrash.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |lovelydear@mailmetrash.com


--- Comment #11 from SomeDude <lovelydear@mailmetrash.com> 2012-12-28 05:58:45 PST ---
Different output for different compilers: http://dpaste.dzfl.pl/c94eea76

Success with GDC 2.060 both 32/64 bits
0 opAssign called
1 dtor called
0 dtor called

Fails identically with LDC 2.060 32 and 64 bits
-1 opAssign called
1 dtor called
-1 dtor called

Success with DMD 2.060 32 bits, fails in 64 bits


Compilation error with Git HEAD 32 bits and failure in 64 bits

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6178


Dmitry Olshansky <dmitry.olsh@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dmitry.olsh@gmail.com


--- Comment #12 from Dmitry Olshansky <dmitry.olsh@gmail.com> 2013-01-15 14:19:41 PST ---
I've just hit another case of this bug on Win32.

It's a major impediment for new std.uni as it may result in memery corruption if a set of code points is written to AA like this:

//this one calls destructor twice and no postblit and causes memory corruption props["Set"] = CodepointSet(a1, a2+1);

//While this one is fine (it calls postblit):
auto set = CodepointSet(a1, a2+1);
props["Set"] = set;

There is no opAssign only postblit + destructor.

The problem is that in the real world the destructor is tricky and expects at least T.init or some valid object else it blows up quite nasty.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6178



--- Comment #13 from Maxim Fomin <maxim@maxim-fomin.ru> 2013-01-16 01:18:30 PST ---
Well, seems in 2.061 the behavior was changed.

Without any options, the output is like:

-1154412584 opAssign called (big value)
1 dtor called
-1154412584 dtor called

With -release or -noboundscheck the output is more robust:

0 opAssign called
1 dtor called
0 dtor called

With -O option output is:

32638 opAssign called // close to signed short int max
1 dtor called
32638 dtor called

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6178



--- Comment #14 from Dmitry Olshansky <dmitry.olsh@gmail.com> 2013-01-16 01:46:18 PST ---
(In reply to comment #13)
> Well, seems in 2.061 the behavior was changed.
> 
> Without any options, the output is like:
> 
> -1154412584 opAssign called (big value)
> 1 dtor called
> -1154412584 dtor called
> 
> With -release or -noboundscheck the output is more robust:
> 
> 0 opAssign called
> 1 dtor called
> 0 dtor called
> 
> With -O option output is:
> 
> 32638 opAssign called // close to signed short int max
> 1 dtor called
> 32638 dtor called

This is shitty but I'll use -release for the moment. BTW it seems
to require both module with struct  *and* the one where AA is used to be
compiled wiht -release.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6178



--- Comment #15 from Maxim Fomin <maxim@maxim-fomin.ru> 2013-01-16 02:18:45 PST ---
(In reply to comment #14)
> This is shitty but I'll use -release for the moment. BTW it seems
> to require both module with struct  *and* the one where AA is used to be
> compiled wiht -release.

Than this a part of a bigger shit.

/* Known as a problem of filling newly created space of AA array
   with T.init before assigning actual object.
   If operation is interrupted, this leads to AA array containing
   "orphan" T.init objects by no reason. Was reported in BZ.
*/
import std.stdio;

int foo()
{
    throw new Exception("");
}

int[int] array;

void main()
{
    try
    {
        array[1] = foo();
    }
    catch(Exception e)
    {

    }
    writeln(array);
}

Compiling with -O => [1:0]
Compiling with -release => []
Compiling with -noboundscheck => []

So, it appears that there is not only bug with AA assignment, but the bug depends on compiler options.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6178



--- Comment #16 from Kenji Hara <k.hara.pg@gmail.com> 2013-04-04 03:11:17 PDT ---
(In reply to comment #15)
> Than this a part of a bigger shit.
> 
> /* Known as a problem of filling newly created space of AA array
>    with T.init before assigning actual object.
>    If operation is interrupted, this leads to AA array containing
>    "orphan" T.init objects by no reason. Was reported in BZ.
> */
> import std.stdio;
> 
> int foo()
> {
>     throw new Exception("");
> }
> 
> int[int] array;
> 
> void main()
> {
>     try
>     {
>         array[1] = foo();
>     }
>     catch(Exception e)
>     {
> 
>     }
>     writeln(array);
> }
> 
> Compiling with -O => [1:0]
> Compiling with -release => []
> Compiling with -noboundscheck => []
> 
> So, it appears that there is not only bug with AA assignment, but the bug depends on compiler options.

It was bug 3825, and has already fixed in 2.063 (git head).

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6178


Kenji Hara <k.hara.pg@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |samukha@voliacable.com


--- Comment #17 from Kenji Hara <k.hara.pg@gmail.com> 2013-09-07 10:05:52 PDT ---
*** Issue 5234 has been marked as a duplicate of this issue. ***

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6178


Kenji Hara <k.hara.pg@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |canidae@exent.net


--- Comment #18 from Kenji Hara <k.hara.pg@gmail.com> 2013-09-07 10:06:57 PDT ---
*** Issue 7503 has been marked as a duplicate of this issue. ***

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6178


Kenji Hara <k.hara.pg@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |szabobogdan@yahoo.com


--- Comment #19 from Kenji Hara <k.hara.pg@gmail.com> 2013-09-07 10:07:18 PDT ---
*** Issue 10356 has been marked as a duplicate of this issue. ***

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------