D issues are now tracked on GitHub. This Bugzilla instance remains as a read-only archive.
Issue 3544 - optlink termination 0041338f with recursive nested functions
Summary: optlink termination 0041338f with recursive nested functions
Status: RESOLVED FIXED
Alias: None
Product: D
Classification: Unclassified
Component: dmd (show other issues)
Version: D1 (retired)
Hardware: x86 Windows
: P2 critical
Assignee: No Owner
URL:
Keywords: ice-on-valid-code, link-failure, Optlink
Depends on:
Blocks:
 
Reported: 2009-11-23 04:38 UTC by anteusz
Modified: 2017-01-10 01:40 UTC (History)
3 users (show)

See Also:


Attachments
the picture of the error (57.07 KB, image/png)
2009-11-23 04:39 UTC, anteusz
Details
one file that causes the problem (2.96 KB, application/octet-stream)
2009-11-24 04:45 UTC, anteusz
Details
Somewhat reduced test case. (69.89 KB, text/plain)
2009-11-24 06:22 UTC, Don
Details

Note You need to log in before you can comment on or make changes to this issue.
Description anteusz 2009-11-23 04:38:17 UTC
Hi,

I compiled and linker a program -debug and the linker crashed.
If I use -release flag , then the linker does not crash but then the program crashes.
The program uses CTFE which may have to do with the crash.
Comment 1 anteusz 2009-11-23 04:39:21 UTC
Created attachment 515 [details]
the picture of the error
Comment 2 anteusz 2009-11-23 04:41:33 UTC
The program uses a large compile-time generated function which seems to 
contribute to the problem.
Comment 3 Don 2009-11-23 07:08:37 UTC
The picture doesn't help at all. You need to provide a source file which will reproduce the error.
Comment 4 anteusz 2009-11-24 04:45:08 UTC
Created attachment 516 [details]
one file that causes the problem

this if compiled as 

dmd.exe -g compilerfailuretest.d

will produce the error.
Note download this file too:http://www.dsource.org/projects/scregexp/browser/trunk/scregexp.d
That file is needed to place it in the same directory where compilerfailuretest.d is located.
Comment 5 Don 2009-11-24 05:00:29 UTC
(In reply to comment #4)
> Created an attachment (id=516) [details]
> one file that causes the problem
> 
> this if compiled as 
> 
> dmd.exe -g compilerfailuretest.d
> 
> will produce the error.
> Note download this file
> too:http://www.dsource.org/projects/scregexp/browser/trunk/scregexp.d
> That file is needed to place it in the same directory where
> compilerfailuretest.d is located.

Thanks, I can reproduce the bug now.
Comment 6 anteusz 2009-11-24 05:04:37 UTC
it is possible to influence the occurance of the error by
reducing the size of 
the statement ...auto perlreg = new screg!("/(?:(?<tok>\\#(?:.*?(?:"~eol~")|.*\\z))|
(?<tok>\"(?:(?>\\\\\\\\|\\\\\"|.))*?\")|

when parameter is smaller, the error does not occur.
Comment 7 Don 2009-11-24 06:22:39 UTC
Created attachment 517 [details]
Somewhat reduced test case.

This cuts it down to a single, self-contained file. (Funny -- I recognize my own code in there -- almost all the comments are mine!) There's plenty of work still to be done in cutting in right down.
Comment 8 Don 2009-11-25 05:16:07 UTC
Completely reduced test case shows it's due to nested functions.
----------
char[] foo(int n) {
  if (n == 0)  return "void xxxx() {}";
  return "void xxxx() { void yyyy() { }" ~ foo(n-1) ~ "}";
}

mixin (foo(400));
Comment 9 Don 2009-11-25 05:29:15 UTC
Even smaller test case. Seems it happens with a depth around 512; it's probably exceeding the maximum symbol length.
---
char[] foo(int n) {
  return "void abcde() {" ~ ( n>0 ? foo(n-1): "") ~ "}";
}

mixin (foo(500));
Comment 10 Walter Bright 2009-11-30 02:03:52 UTC
The test case is crashing in dmd, not optlink. It's a stack overflow.
Comment 11 anteusz 2009-12-12 00:06:04 UTC
Hi,

Should I repost my example?
Comment 12 Don 2010-01-13 00:46:23 UTC
(In reply to comment #10)
> The test case is crashing in dmd, not optlink. It's a stack overflow.

If you compile in debug mode, it crashes in DMD. If you compile in release mode, it crashes in OPTLINK.
Comment 13 anteusz 2010-02-11 05:23:05 UTC
Hi,

What should I do so it gets fixed? I mean this bug.
I reported this in November.
Comment 14 Don 2010-02-11 08:33:38 UTC
(In reply to comment #13)
> Hi,
> 
> What should I do so it gets fixed? I mean this bug.
> I reported this in November.

This is in the queue of critical but hard-to-fix and relatively obscure bugs. It is a few months away from being fixed.

Note that when it gets 'fixed', it will generate a compile-time error rather than a link-time one. Bug 2315 is basically the same issue. I don't see any solution other than imposing a limit on CTFE recursion. So don't get the idea that the code will ever 'work'. It'll just fail more nicely.
Comment 15 anteusz 2010-02-11 09:09:12 UTC
A clear error message would suffice. How could I expect more?
It would not be bad if the stack size for ctfre could be set?
Is there a way to set the stack size for ctfe??
Comment 16 anteusz 2010-02-11 09:09:56 UTC
A clear error message would suffice. How could I expect more?
It would not be bad if the stack size for ctfre could be set?
Is there a way to set the stack size for ctfe??
Comment 17 Walter Bright 2010-09-01 19:01:47 UTC
I cannot reproduce this problem. Please show exactly what commands are given to dmd and the linker.
Comment 18 Don 2010-09-01 23:55:47 UTC
(In reply to comment #17)
> I cannot reproduce this problem. Please show exactly what commands are given to
> dmd and the linker.

dmd -g bug.d
This was crashing with DMD2.048 and link 8.00.2.
I have confirmed that link 8.00.6 fixed this. (And it's stayed fixed in 8.00.7).