• Ellery Newcomer (7/7) Feb 10 2012 when I run
• Timon Gehr (7/14) Feb 10 2012 I seem to have more RAM than you. The behavior is apparently caused by a...
• Ellery Newcomer (8/10) Feb 10 2012 That is likely.
• Timon Gehr (2/13) Feb 10 2012 Probably yes.
• Marco Leise (3/14) Feb 11 2012 I was inclined to say: disable your swap partition.
• Manfred Nowak (8/9) Feb 11 2012 The behavior has nothing to do with fedora, because I can confirm it
• Timon Gehr (3/12) Feb 11 2012 Probably not, but the error message suggests the problem might be in
• Manfred Nowak (9/10) Feb 11 2012 Not necassarily. But it would be a Phobos bug if the allocation cycle
• Timon Gehr (21/33) Feb 11 2012 You didn't quote everything that is relevant:
• Manfred Nowak (6/9) Feb 11 2012 I did not read that in the posts and on dmd 2.057/win32 only an out of
• Ellery Newcomer (3/7) Feb 11 2012 Don't know, but this sort of thing has happened to me quite a bit over
• Timon Gehr (5/12) Feb 12 2012 It is a bug in your code:
• Ellery Newcomer (6/10) Feb 12 2012 Wow.

Ellery Newcomer <ellery-newcomer utulsa.edu> writes:

when I run

dmd -gc -oftopo topo.d multi_index.d replace.d

on the contents of

http://personal.utulsa.edu/~ellery-newcomer/bad.zip

in fedora 16 x86_64 with dmd 2.057 64 bit

dmd starts thrashing like there is no tomorrow and generally locks up my 
entire system. Can anyone confirm this behavior?

Timon Gehr <timon.gehr gmx.ch> writes:

On 02/10/2012 08:38 PM, Ellery Newcomer wrote:
 when I run

 dmd -gc -oftopo topo.d multi_index.d replace.d

 on the contents of

 http://personal.utulsa.edu/~ellery-newcomer/bad.zip

 in fedora 16 x86_64 with dmd 2.057 64 bit

 dmd starts thrashing like there is no tomorrow and generally locks up my
 entire system. Can anyone confirm this behavior?

I seem to have more RAM than you. The behavior is apparently caused by a 
Phobos bug:

/usr/include/d/dmd/phobos/std/functional.d(185): Error: template 
instance 
std.functional.binaryFunImpl!(pred,parm1Name,parm2Name).Body!(dchar,string) 
recursive expansion

Ellery Newcomer <ellery-newcomer utulsa.edu> writes:

On 02/10/2012 01:59 PM, Timon Gehr wrote:
 I seem to have more RAM than you. The behavior is apparently caused by a
 Phobos bug:

That is likely.

The code is a dustmite reduction, so I don't really care what the error 
is, just that it shouldn't be killing my computer.

ulimit -v XXXX

seems to fix it nicely enough (if you don't mind that the only output is 
Error: out of memory)

Think this issue is bugzilla worthy?

Timon Gehr <timon.gehr gmx.ch> writes:

On 02/11/2012 12:16 AM, Ellery Newcomer wrote:
 On 02/10/2012 01:59 PM, Timon Gehr wrote:
 I seem to have more RAM than you. The behavior is apparently caused by a
 Phobos bug:

 That is likely.

 The code is a dustmite reduction, so I don't really care what the error
 is, just that it shouldn't be killing my computer.

 ulimit -v XXXX

 seems to fix it nicely enough (if you don't mind that the only output is
 Error: out of memory)

 Think this issue is bugzilla worthy?

Probably yes.

"Marco Leise" <Marco.Leise gmx.de> writes:

Am 11.02.2012, 00:16 Uhr, schrieb Ellery Newcomer  
<ellery-newcomer utulsa.edu>:

 On 02/10/2012 01:59 PM, Timon Gehr wrote:
 I seem to have more RAM than you. The behavior is apparently caused by a
 Phobos bug:

 That is likely.

 The code is a dustmite reduction, so I don't really care what the error  
 is, just that it shouldn't be killing my computer.

 ulimit -v XXXX

 seems to fix it nicely enough (if you don't mind that the only output is  
 Error: out of memory)

 Think this issue is bugzilla worthy?

I was inclined to say: disable your swap partition.

Manfred Nowak <svv1999 hotmail.com> writes:

Ellery Newcomer wrote:

 Can anyone confirm this behavior?

The behavior has nothing to do with fedora, because I can confirm it 
for win32. It seems to be rooted in an infinite loop of memory 
allocations.

Is this the first time of a report that an implementation attempt 
stumbles into the holting problem hidden in the evaluation of templates 
during some compilation phase?

-manfred

Timon Gehr <timon.gehr gmx.ch> writes:

On 02/11/2012 02:29 PM, Manfred Nowak wrote:
 Ellery Newcomer wrote:

 Can anyone confirm this behavior?

 The behavior has nothing to do with fedora, because I can confirm it
 for win32. It seems to be rooted in an infinite loop of memory
 allocations.

 Is this the first time of a report that an implementation attempt
 stumbles into the holting problem hidden in the evaluation of templates
 during some compilation phase?

 -manfred

Probably not, but the error message suggests the problem might be in 
std.functional. This would make it a Phobos bug.

Manfred Nowak <svv1999 hotmail.com> writes:

Timon Gehr wrote:

 This would make it a Phobos bug.

Not necassarily. But it would be a Phobos bug if the allocation cycle 
is completely located within Phobos and the possibilty of such a cycle 
is not mentioned in the docs.

An analog argument holds for every templated "library", that uses 
templates out of phobos. But how can one know, whther the extension of 
phobos with a self generated template builds a finite or semi-finite 
allocation-loop or execution-loop?

-manfred

Timon Gehr <timon.gehr gmx.ch> writes:

On 02/11/2012 05:19 PM, Manfred Nowak wrote:
 Timon Gehr wrote:

 This would make it a Phobos bug.

 Not necassarily.

You didn't quote everything that is relevant:

Timon Gehr wrote:
 Probably not, but the error message suggests the problem might be in
 std.functional. This would make it a Phobos bug.

Yes, necessarily.


 But it would be a Phobos bug if the allocation cycle
 is completely located within Phobos and the possibilty of such a cycle
 is not mentioned in the docs.

Exactly.

 An analog argument holds for every templated "library", that uses
 templates out of phobos. But how can one know, whther the extension of
 phobos with a self generated template builds a finite or semi-finite
 allocation-loop or execution-loop?

The error message says

Error: template instance 
std.functional.binaryFunImpl!(pred,parm1Name,parm2Name).Body!(dchar,string) 
recursive expansion

Compare to:

template T1(int x){
     alias T1!(x+1) T1;
}

template T2(int x){
     alias T1!x T2;
}

void main(){
     mixin T2!0;
}

Error: template instance tt.T1!(500) recursive expansion

I'll attempt to analyse what is going on in detail tonight.

Manfred Nowak <svv1999 hotmail.com> writes:

Timon Gehr wrote:

 The error message says

[...]
 recursive expansion

I did not read that in the posts and on dmd 2.057/win32 only an out of 
memory was thrown.


 I'll attempt to analyse

Good luck.

-manfred

Ellery Newcomer <ellery-newcomer utulsa.edu> writes:

On 02/11/2012 07:29 AM, Manfred Nowak wrote:
 Is this the first time of a report that an implementation attempt
 stumbles into the holting problem hidden in the evaluation of templates
 during some compilation phase?

 -manfred

Don't know, but this sort of thing has happened to me quite a bit over 
the years, but usually in much larger projects.

Timon Gehr <timon.gehr gmx.ch> writes:

On 02/10/2012 08:38 PM, Ellery Newcomer wrote:
 when I run

 dmd -gc -oftopo topo.d multi_index.d replace.d

 on the contents of

 http://personal.utulsa.edu/~ellery-newcomer/bad.zip

 in fedora 16 x86_64 with dmd 2.057 64 bit

 dmd starts thrashing like there is no tomorrow and generally locks up my
 entire system. Can anyone confirm this behavior?

It is a bug in your code:

-                ForEachIndex!(N+1, L).result;
+                ForEachIndex!(N+1, L[1..$]).result;

The diagnostic DMD spits out is quite bad.

Ellery Newcomer <ellery-newcomer utulsa.edu> writes:

On 02/12/2012 08:34 AM, Timon Gehr wrote:
 It is a bug in your code:

 - ForEachIndex!(N+1, L).result;
 + ForEachIndex!(N+1, L[1..$]).result;

 The diagnostic DMD spits out is quite bad.

Wow.

In my defense, the original code is right; apparently dustmite did this 
to the reduced case.

I know I had that stuff working last summer.

Thanks for the analysis.