import core.sys.windows.windows: MessageBoxA;

void test() {
	for(int i; i != 10; i++) {
		ubyte[] buf;
		for(int j; j != 100000000; j++) buf ~= 65;
		MessageBoxA(null, "--on for--".ptr, "".ptr, 0);
		// delete buf; // if ON - then memory delete in step
	}
	MessageBoxA(null, "--off for--".ptr, "".ptr, 0);
}

void main() {
	test();
	MessageBoxA(null, "--The end--".ptr, "".ptr, 0);
}

----------------
core.exception.OutOfMemoryError@src\core\exception.d(693): Memory allocation failed
----------------

Simple program and error. Why?  Windows 7 (32) dmd 2.072.0

On Sunday, 20 November 2016 at 17:47:50 UTC, MGW wrote:
> import core.sys.windows.windows: MessageBoxA;
>
> void test() {
> 	for(int i; i != 10; i++) {
> 		ubyte[] buf;
> 		for(int j; j != 100000000; j++) buf ~= 65;
> 		MessageBoxA(null, "--on for--".ptr, "".ptr, 0);
> 		// delete buf; // if ON - then memory delete in step
> 	}
> 	MessageBoxA(null, "--off for--".ptr, "".ptr, 0);
> }
>
> void main() {
> 	test();
> 	MessageBoxA(null, "--The end--".ptr, "".ptr, 0);
> }
>
> ----------------
> core.exception.OutOfMemoryError@src\core\exception.d(693): Memory allocation failed
> ----------------
>
> Simple program and error. Why?  Windows 7 (32) dmd 2.072.0

For me there's no exception. Maybe the GC is poluted. Try to add this after each iteration in the first test loop:

        import core.memory: GC;
        GC.collect();

Also note that the text you pas in the message box should be null terminated, eg:

        MessageBoxA(null, "--The end--\0".ptr, "".ptr, 0);

On Sunday, 20 November 2016 at 18:58:04 UTC, Basile B. wrote:
> On Sunday, 20 November 2016 at 17:47:50 UTC, MGW wrote:
>> [...]
>
> For me there's no exception. Maybe the GC is poluted. Try to add this after each iteration in the first test loop:
>
>         import core.memory: GC;
>         GC.collect();
>
> Also note that the text you pas in the message box should be null terminated, eg:
>
>         MessageBoxA(null, "--The end--\0".ptr, "".ptr, 0);

string literals are implicitly null terminated explicitly for the interoperation with C.
there is no need.

On Sunday, 20 November 2016 at 18:58:04 UTC, Basile B. wrote:
> On Sunday, 20 November 2016 at 17:47:50 UTC, MGW wrote:
>> import core.sys.windows.windows: MessageBoxA;
>>
>> void test() {
>> 	for(int i; i != 10; i++) {
>> 		ubyte[] buf;
>> 		for(int j; j != 100000000; j++) buf ~= 65;
>> 		MessageBoxA(null, "--on for--".ptr, "".ptr, 0);
>> 		// delete buf; // if ON - then memory delete in step
>> 	}
>> 	MessageBoxA(null, "--off for--".ptr, "".ptr, 0);
>> }
>>
>> void main() {
>> 	test();
>> 	MessageBoxA(null, "--The end--".ptr, "".ptr, 0);
>> }
>>
>> ----------------
>> core.exception.OutOfMemoryError@src\core\exception.d(693): Memory allocation failed
>> ----------------

This short program doesn't work at Windows 32. Why GC doesn't release memory in case of its shortage in Windows! This is bug?

On Monday, 21 November 2016 at 03:58:00 UTC, MGW wrote:
> On Sunday, 20 November 2016 at 18:58:04 UTC, Basile B. wrote:
>> On Sunday, 20 November 2016 at 17:47:50 UTC, MGW wrote:
>>> import core.sys.windows.windows: MessageBoxA;
>>>
>>> void test() {
>>> 	for(int i; i != 10; i++) {
>>> 		ubyte[] buf;
>>> 		for(int j; j != 100000000; j++) buf ~= 65;
>>> 		MessageBoxA(null, "--on for--".ptr, "".ptr, 0);
>>> 		// delete buf; // if ON - then memory delete in step
>>> 	}
>>> 	MessageBoxA(null, "--off for--".ptr, "".ptr, 0);
>>> }
>>>
>>> void main() {
>>> 	test();
>>> 	MessageBoxA(null, "--The end--".ptr, "".ptr, 0);
>>> }
>>>
>>> ----------------
>>> core.exception.OutOfMemoryError@src\core\exception.d(693): Memory allocation failed
>>> ----------------
>
> This short program doesn't work at Windows 32. Why GC doesn't release memory in case of its shortage in Windows! This is bug?

You are appending 100_000_000 Times.
Note that this will take up much more then 100 MB.
Because the allocator cannot always grow the array.
All previously allocated blocks are still in scope and could be reached.
Therefore the memory is not released.

At least this is what I think happens.
it would help more if you could post the specs of your machine and what else is running on it.

On 11/21/2016 07:36 AM, Stefan Koch wrote:
> On Monday, 21 November 2016 at 03:58:00 UTC, MGW wrote:
>> On Sunday, 20 November 2016 at 18:58:04 UTC, Basile B. wrote:
>>> On Sunday, 20 November 2016 at 17:47:50 UTC, MGW wrote:
>>>> import core.sys.windows.windows: MessageBoxA;
>>>>
>>>> void test() {
>>>>     for(int i; i != 10; i++) {
>>>>         ubyte[] buf;
>>>>         for(int j; j != 100000000; j++) buf ~= 65;
>>>>         MessageBoxA(null, "--on for--".ptr, "".ptr, 0);
>>>>         // delete buf; // if ON - then memory delete in step
>>>>     }
>>>>     MessageBoxA(null, "--off for--".ptr, "".ptr, 0);
>>>> }
>>>>
>>>> void main() {
>>>>     test();
>>>>     MessageBoxA(null, "--The end--".ptr, "".ptr, 0);
>>>> }
[...]
> You are appending 100_000_000 Times.
> Note that this will take up much more then 100 MB.
> Because the allocator cannot always grow the array.
> All previously allocated blocks are still in scope and could be reached.
> Therefore the memory is not released.

How could they be reached? The only reference is `buf', and when appending triggers relocation, `buf` should point to the new location, no?

On Monday, 21 November 2016 at 06:45:04 UTC, ag0aep6g wrote:
> On 11/21/2016 07:36 AM, Stefan Koch wrote:
>> On Monday, 21 November 2016 at 03:58:00 UTC, MGW wrote:
>>> On Sunday, 20 November 2016 at 18:58:04 UTC, Basile B. wrote:
>>>> On Sunday, 20 November 2016 at 17:47:50 UTC, MGW wrote:
>>>>> [...]
> [...]
>> You are appending 100_000_000 Times.
>> Note that this will take up much more then 100 MB.
>> Because the allocator cannot always grow the array.
>> All previously allocated blocks are still in scope and could be reached.
>> Therefore the memory is not released.
>
> How could they be reached? The only reference is `buf', and when appending triggers relocation, `buf` should point to the new location, no?

Someone could still be hanging on to an old Reference of buf.

On 11/21/2016 08:27 AM, Stefan Koch wrote:
> Someone could still be hanging on to an old Reference of buf.

Who could "someone" be? It's a self-contained example, and buf doesn't leave the test function.

On Monday, 21 November 2016 at 11:22:40 UTC, ag0aep6g wrote:
> Who could "someone" be? It's a self-contained example, and buf doesn't leave the test function.

Anything in .data and .bss sections and stack. See https://issues.dlang.org/show_bug.cgi?id=15723

As for GC compaction: https://issues.dlang.org/show_bug.cgi?id=3284

On Monday, 21 November 2016 at 16:37:32 UTC, Kagamin wrote:
> Anything in .data and .bss sections and stack. See https://issues.dlang.org/show_bug.cgi?id=15723

Ok, not an actual reference then, but a false pointer.