Hello!
I'm using Debian 7 system and dmd 2.062.

I use some array functions to test memory allocation process in D and
have a segmentation fault as a result of this test.

How it works:

 1 iteration.
     Before allocation we have over 9.5 Mb of virtual memory used.
     After allocation we have over 582 Mb used.
     After disposing the used memory stays over 582 Mb.
 2 iteration.
     Before allocation we have over 582 Mb of virtual memory used.
     After allocation we have over 1.1 Gb used.
     After disposing the used memory stays over 1.1 Gb Mb.
 3 iteration.
     Before allocation we have over 1.1 Gb of virtual memory used.
     After allocation we have over 1.7 Gb used.
     After disposing the used memory stays over 1.7 Gb Mb.

 and so on..

result: crash application

Why "arr.length = length" allocate a new memory block at the second and other iterations, if before it used "clear(arr)" and "arr.length=0" function ?

<===EXAMPLE=====================================================>

	writeln("Before allocation. Press a key.");
	stdin.readln();

	int arr[];
	int length = 100_000_000;
	for (int i=0; i<10; i++)
	{
		arr.length = length; // always new memory blocks, why?
		arr[90] = 20;
		writeln("After allocation. Press a key.");
		stdin.readln();

		clear(arr);
		arr.length = 0; // must be deallocation? but nothing happens

		writeln("After disposing. Press a key.");
		stdin.readln();

	}

<===============================================================>

With many thanks.

On 64 bit may cause crash: arr.length = length, fixed in next version.

>
>arr.length = 0; // must be deallocation?
>
Not necessarily. You can manually do a garbage collection.

On 04/10/2013 10:04 PM, Andrey wrote:> Hello!

>      int arr[];
>      int length = 100_000_000;
>      for (int i=0; i<10; i++)
>      {
>          arr.length = length; // always new memory blocks, why?

The slice does not know what other slices may be sharing the same elements. So, increasing the length of a slice will relocate the elements (almost always, with exceptions.) The following article goes into a lot of detail:

  http://dlang.org/d-array-article.html

>          arr[90] = 20;
>          writeln("After allocation. Press a key.");
>          stdin.readln();
>
>          clear(arr);
>          arr.length = 0; // must be deallocation? but nothing happens

Are you compiling as a 32-bit application? Then, chances are random bit patterns look like references into these slices. (dmd uses a conservative garbage collector). Try compiling with -m64.

Ali

On Thursday, 11 April 2013 at 06:39:53 UTC, Traveler wrote:
> On 64 bit may cause crash: arr.length = length, fixed in next version.
>
>>
>>arr.length = 0; // must be deallocation?
>>
> Not necessarily. You can manually do a garbage collection.

The manual calling function GC.collect() has no effect (tested under x32 and x64 versions).

<=========>
.......
	clear(arr);
	arr.length = 0;

	GC.collect(); // useless calling, the used memory will be increase

	writeln("After dispose. Press a key.");
	stdin.readln();
.......
<=========>

On Thursday, 11 April 2013 at 06:55:41 UTC, Ali Çehreli wrote:
> On 04/10/2013 10:04 PM, Andrey wrote:> Hello!
>
> >      int arr[];
> >      int length = 100_000_000;
> >      for (int i=0; i<10; i++)
> >      {
> >          arr.length = length; // always new memory blocks,
> why?
>
> The slice does not know what other slices may be sharing the same elements. So, increasing the length of a slice will relocate the elements (almost always, with exceptions.) The following article goes into a lot of detail:
>
>   http://dlang.org/d-array-article.html
>
> >          arr[90] = 20;
> >          writeln("After allocation. Press a key.");
> >          stdin.readln();
> >
> >          clear(arr);
> >          arr.length = 0; // must be deallocation? but nothing
> happens
>
> Are you compiling as a 32-bit application? Then, chances are random bit patterns look like references into these slices. (dmd uses a conservative garbage collector). Try compiling with -m64.
>
> Ali

Sorry, You're right, it's my mistake, x64 version has no memory disposing trouble, but x32 version it has.
I have check it twice. Thanks for right ideas.