digitalmars.D.bugs - [Issue 6178] New: Struct inside the AA are not init correctly
- d-bugmail puremagic.com Jun 19 2011
- d-bugmail puremagic.com Jun 19 2011
- d-bugmail puremagic.com Jun 19 2011
- d-bugmail puremagic.com Jun 19 2011
- d-bugmail puremagic.com Jun 19 2011
- d-bugmail puremagic.com Jan 18 2012
- d-bugmail puremagic.com Jan 18 2012
- d-bugmail puremagic.com Jan 19 2012
- d-bugmail puremagic.com Mar 16 2012
- d-bugmail puremagic.com Dec 13 2012
- d-bugmail puremagic.com Dec 13 2012
- d-bugmail puremagic.com Dec 28 2012
- d-bugmail puremagic.com Jan 15 2013
- d-bugmail puremagic.com Jan 16 2013
- d-bugmail puremagic.com Jan 16 2013
- d-bugmail puremagic.com Jan 16 2013
- d-bugmail puremagic.com Apr 04 2013
http://d.puremagic.com/issues/show_bug.cgi?id=6178 Summary: Struct inside the AA are not init correctly Product: D Version: D2 Platform: Other OS/Version: Windows Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: nobody puremagic.com ReportedBy: jsancio gmail.com --- Comment #0 from Jose Garcia <jsancio gmail.com> 2011-06-19 12:39:02 PDT --- -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jun 19 2011
d-bugmail puremagic.com http://d.puremagic.com/issues/show_bug.cgi?id=6178 --- Comment #1 from Jose Garcia <jsancio gmail.com> 2011-06-19 12:45:41 PDT --- Err -- Hit submit without a description... I am going to assume that this was not already filed. If so please accept my apologies. If you create an AA that points to a struct the is not initialized properly. In other word it is not the same as S.init. If this stays that way in can completely confuse the dtor. For example: import std.stdio; struct Bug { this(this) { writefln("%s postblit ctor called", var); } void opAssign(Bug rhs) { writefln("%s opAssign called", var); } ~this() { writefln("%s dtor called", var); } int var = 0; } void main() { Bug[int] map; { map[0] = Bug(1); } } This yields the following output (you need -O or you will hit bug 6177): dmd -w -O map_test.d && ./map_test 3 opAssign called 1 dtor called 3 dtor called Where in the world is 3 coming from? You output may be slightly different. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jun 19 2011
http://d.puremagic.com/issues/show_bug.cgi?id=6178 Jose Garcia <jsancio gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P2 |P1 Component|DMD |druntime Platform|Other |x86 OS/Version|Windows |Linux Severity|normal |blocker --- Comment #2 from Jose Garcia <jsancio gmail.com> 2011-06-19 12:47:14 PDT --- Moving it to druntime since it probably belongs there. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jun 19 2011
http://d.puremagic.com/issues/show_bug.cgi?id=6178 --- Comment #3 from Jose Garcia <jsancio gmail.com> 2011-06-19 13:20:15 PDT --- I am getting around this issue with: enum : uint { TOKEN = 987654321 } struct Bug { ~this() { if(token == TOKEN) { ...} } private uint token = TOKEN; } -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jun 19 2011
http://d.puremagic.com/issues/show_bug.cgi?id=6178 kennytm gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kennytm gmail.com Component|druntime |DMD --- Comment #4 from kennytm gmail.com 2011-06-19 14:56:10 PDT --- With an opAssign, an assignment to an AA struct will become something like Bug __aatmp1234 = void; // <--- __aatmp1234.opAssign(1); map.set(0, __aatmp1234); map[0].___postblit(); the '3' is likely due to the '<---' line. See bug 2451. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jun 19 2011
http://d.puremagic.com/issues/show_bug.cgi?id=6178 Andrei Alexandrescu <andrei metalanguage.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |andrei metalanguage.com --- Comment #5 from Andrei Alexandrescu <andrei metalanguage.com> 2012-01-18 08:40:19 PST --- Update - with the dmd from the head the example causes Internal error: backend/cgcs.c 162 If the destructor is commented out, the printed message on my machine is -2084965984 opAssign called -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jan 18 2012
http://d.puremagic.com/issues/show_bug.cgi?id=6178 --- Comment #6 from Jose Garcia <jsancio gmail.com> 2012-01-18 18:22:55 PST --- Andrei, Do you still get the compiler internal error with -0? See bug 6177. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jan 18 2012
http://d.puremagic.com/issues/show_bug.cgi?id=6178 --- Comment #7 from Andrei Alexandrescu <andrei metalanguage.com> 2012-01-19 07:11:42 PST --- (In reply to comment #6)Andrei, Do you still get the compiler internal error with -0? See bug 6177.
I don't understand the question. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jan 19 2012
http://d.puremagic.com/issues/show_bug.cgi?id=6178 hsteoh quickfur.ath.cx changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hsteoh quickfur.ath.cx --- Comment #8 from hsteoh quickfur.ath.cx 2012-03-16 08:10:42 PDT --- I think he meant -O, not -0. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Mar 16 2012
http://d.puremagic.com/issues/show_bug.cgi?id=6178 --- Comment #9 from Don <clugdbug yahoo.com.au> 2012-12-13 09:35:46 PST --- On Linux, I see the bug only with 32 bits, it works OK with 64 bits. With -m64 and -m64 -O, I get 0 opAssign called 1 dtor called 0 dtor called whereas with -m32 I get -142997715 opAssign called 1 dtor called -142997715 dtor called and with -m32 -O 2 opAssign called 1 dtor called 2 dtor called -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Dec 13 2012
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: -------
Dec 13 2012
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: -------
Dec 28 2012
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: -------
Jan 15 2013
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: -------
Jan 16 2013
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: -------
Jan 16 2013
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: -------
Jan 16 2013
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: -------
Apr 04 2013