Bug 3544 – optlink termination 0041338f with recursive nested functions

Status
RESOLVED
Resolution
FIXED
Severity
critical
Priority
P2
Component
dmd
Product
D
Version
D1 (retired)
Platform
x86
OS
Windows
Creation time
2009-11-23T04:38:00Z
Last change time
2017-01-10T01:40:04Z
Keywords
ice-on-valid-code, link-failure, Optlink
Assigned to
nobody
Creator
anteusz

Attachments

IDFilenameSummaryContent-TypeSize
515termination.pngthe picture of the errorimage/png58444
516compilerfailuretest.done file that causes the problemapplication/octet-stream3032
517linkcrash.dSomewhat reduced test case.text/plain71567

Comments

Comment #0 by anteusz — 2009-11-23T04:38:17Z
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 by anteusz — 2009-11-23T04:39:21Z
Created attachment 515 the picture of the error
Comment #2 by anteusz — 2009-11-23T04:41:33Z
The program uses a large compile-time generated function which seems to contribute to the problem.
Comment #3 by clugdbug — 2009-11-23T07:08:37Z
The picture doesn't help at all. You need to provide a source file which will reproduce the error.
Comment #4 by anteusz — 2009-11-24T04:45:08Z
Created attachment 516 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 by clugdbug — 2009-11-24T05:00:29Z
(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 by anteusz — 2009-11-24T05:04:37Z
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 by clugdbug — 2009-11-24T06:22:39Z
Created attachment 517 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 by clugdbug — 2009-11-25T05:16:07Z
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 by clugdbug — 2009-11-25T05:29:15Z
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 by bugzilla — 2009-11-30T02:03:52Z
The test case is crashing in dmd, not optlink. It's a stack overflow.
Comment #11 by anteusz — 2009-12-12T00:06:04Z
Hi, Should I repost my example?
Comment #12 by clugdbug — 2010-01-13T00:46:23Z
(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 by anteusz — 2010-02-11T05:23:05Z
Hi, What should I do so it gets fixed? I mean this bug. I reported this in November.
Comment #14 by clugdbug — 2010-02-11T08:33:38Z
(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 by anteusz — 2010-02-11T09:09:12Z
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 by anteusz — 2010-02-11T09:09:56Z
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 by bugzilla — 2010-09-01T19:01:47Z
I cannot reproduce this problem. Please show exactly what commands are given to dmd and the linker.
Comment #18 by clugdbug — 2010-09-01T23:55:47Z
(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).