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?

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

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?

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.

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.

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

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.

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 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

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.