929 – Resizing array of associative arrays (uint[char[]][]) causes infinite loop / hang

The following code produces an infinite loop. When executed "before" is printed but "after" is never reached.
import std.stdio;
int main()
{
	uint[char[]][] fractal;
	writefln("before"); 
	fractal.length = 10;
	writefln("after"); 
	
	return 0;
}

http://www.digitalmars.com/d/arrays.html#associative (under "Properties"):
.length 	Returns number of values in the associative array. Unlike for dynamic arrays, it is read-only.
So this shouldn't even compile...

(In reply to comment #1)
> http://www.digitalmars.com/d/arrays.html#associative (under "Properties"):
> .length Returns number of values in the associative array. Unlike for
> dynamic arrays, it is read-only.
> 
> So this shouldn't even compile...
> 
uint[char[]][] fractal;
fractal is a dynamic array, so length is not read-only.

(In reply to comment #2)
> uint[char[]][] fractal;
> 
> fractal is a dynamic array, so length is not read-only.
Ah, I missed the last brackets. Sorry about that.

This worked just fine in DMD1.0. It was broken recently.
I am currently using a workaround - encapsulating uint[char[]] into a class and making an array of those.

Added to DStress as
http://dstress.kuehne.cn/run/l/length_11_A.d
http://dstress.kuehne.cn/run/l/length_11_B.d 

Just stumbled on this when recompiling an older project.
To me dynamic and associative arrays are key features of D.
The bug was introduced with version 1.001.
Therefore increased priority as well as severity and set Version to 1.001.
The bug shows up on upsizing only. Downsizing by assigning to length is possible.
The type `int[int][]' is sufficient to show the bug.

Ouch. This one just bit me too.
So throw in my "vote" or whatever.
This needs a-fixin' pronto.
Thanks for the workaround suggestion, Nick.

*** Bug 1321 has been marked as a duplicate of this bug. ***

Here's a patch against GDC's phobos/internal/gc/gc.d that fixes the issue.
It was caused by incorrect/missing handling of the "init.length is 0" case in array resize (the correct behavior is filling with zeroes).
diff ~/gcc/dgcc/d/phobos/internal/gc/gc.d ~/gcc/gcc-4.1.2/libphobos/internal/gc/gc.d
632c632
< assert(initsize);
---
> // assert(initsize); // size 0 means fill with zeroes
634c634
< assert((sizeelem / initsize) * initsize == sizeelem);
---
> assert(!initsize || ((sizeelem / initsize) * initsize == sizeelem));
714a715,719
> if (initsize == 0)
> {
> memset(newdata + size, 0, newsize - size);
> }
> else

Update: The underlying issue seems to be that the wrong version of _d_arraysetlength gets called - for zero initializers it should be ...lengthT but ...lengthiT is what ends up being called in this case. Seems to be a compiler bug of sorts.

Is there any update to this problem? I've been attempting to write some code like this and have been getting exactly this error with DMD 1.026 on a win32 box.
thanks,
wade

*** Bug 2135 has been marked as a duplicate of this bug. ***

If I am not mistaken, Tomas fixed this in LLVMDC by providing an isZeroInit() overload in TypeAArray that returns TRUE.

(In reply to comment #7)
> Ouch. This one just bit me too.
> So throw in my "vote" or whatever.
> This needs a-fixin' pronto.
> 
> Thanks for the workaround suggestion, Nick.
> 
This just bit me again!
Also one new tidbit of info: in addition to using a class to work around this you can also wrap the AA in a struct.
struct CharToUint
{
 uint[char[]] map;
}
CharToUint[] x; x.length = 20; // no probs

Just to make the patch more explicit: Adding
int TypeAArray::isZeroInit()
{
 return 1;
}
to mtype.c and the matching prototype to mtype.h fixes it. Tested in LDC.

If Walter's looking for low-hanging fruit, it doesn't get much lower than this. A 5-line diff? Why has this been open for almost 2 years, anyway?

*** Bug 1898 has been marked as a duplicate of this bug. ***

From issue 1898: allocating an array of AAs using new also hangs, as in
int[int][] maps;
maps = new int[int][3];
There's a workaround, calling .dup on a static array of AAs, but it requires that the length be known at compile time.

has been fixed in DMD 1.037 and 2.021

Fixed in gdc SVN revision 244 as well, thanks!