www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - memory leaks in phobos?

reply "Andrey" <vangelisforever yandex.ru> writes:
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.
Apr 10 2013
next sibling parent reply "Traveler" <somewhere example.com> writes:
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.
Apr 10 2013
parent "Andrey" <vangelisforever yandex.ru> writes:
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();
.......
<=========>
Apr 11 2013
prev sibling parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
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
Apr 10 2013
parent "Andrey" <vangelisforever yandex.ru> writes:
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.
Apr 12 2013