• Benjamin Thaut (45/45) Oct 25 2016 Please consider the following program:
• ag0aep6g (10/22) Oct 25 2016 I can confirm the crash with 2.071.2. But it doesn't happen with

Benjamin Thaut <code benjamin-thaut.de> writes:

Please consider the following program:

import std.experimental.allocator.mallocator;
import std.experimental.allocator.building_blocks.allocator_list 
: AllocatorList;
import std.experimental.allocator.building_blocks.free_list;
import std.experimental.allocator;
import std.stdio;

enum uint size = 1104;

alias ScalableFreeList = AllocatorList!((n) =>
     ContiguousFreeList!(Mallocator, 0, unbounded)(size * 128, 
size)
);

void main(string[] args)
{
   void[][20] allocs;
   ScalableFreeList allocator;

   for(int i=0; i < 100; i++)
   {
     writefln("pass %d", i);
     foreach(ref alloc; allocs)
     {
       alloc = allocator.allocate(size);
       writefln("%x", alloc.ptr);
     }

     foreach(alloc; allocs)
     {
       allocator.deallocate(alloc);
     }
   }
}


I would assume that this program should run forever and never run 
out of memory. But instead it triggers an assert inside 
alocator_list in pass 11. So I assume this is some bug in 
std.allocator?

Also whats interresting. The first allocation in each new pass is 
_not_ the last allocation to be freed. Instead it seems to "leak" 
one allocation each pass.

 From the output of the program:

229a290fd60 <- same
229a2932570 <- leaked?
pass 11
229a290fd60 <- same

Or can anyone see a bug in my program?

Kind Regards
Benjamin Thaut

ag0aep6g <anonymous example.com> writes:

On 10/25/2016 11:30 AM, Benjamin Thaut wrote:
 Please consider the following program:

[...]
 I would assume that this program should run forever and never run out of
 memory. But instead it triggers an assert inside alocator_list in pass
 11. So I assume this is some bug in std.allocator?

I can confirm the crash with 2.071.2. But it doesn't happen with 
2.072.0-b2. So, bug that has already been fixed?

 Also whats interresting. The first allocation in each new pass is _not_
 the last allocation to be freed. Instead it seems to "leak" one
 allocation each pass.

 From the output of the program:

 229a290fd60 <- same
 229a2932570 <- leaked?
 pass 11
 229a290fd60 <- same

Also looks ok with 2.072.0-b2:

7f448c7ccdb0
7f448c7cd200
pass 99
7f448c7cd200
7f448c7ccdb0