Community

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