Bug 4009 – OPTLINK ruins the day yet again

Status
RESOLVED
Resolution
FIXED
Severity
regression
Priority
P1
Component
tools
Product
D
Version
D1 (retired)
Platform
Other
OS
Windows
Creation time
2010-03-26T04:27:00Z
Last change time
2017-01-10T01:40:30Z
Keywords
link-failure, Optlink
Assigned to
nobody
Creator
nfxjfg

Comments

Comment #0 by nfxjfg — 2010-03-26T04:27:51Z
Compile the following source code with dmd x.d -g OPTLINK will crash: Unexpected OPTLINK Termination at EIP=0041338F EAX=6F733231 EBX=6F733231 ECX=00000000 EDX=1D8CC66F ESI=0033FE7C EDI=1D8CC66F EBP=0033FED4 ESP=0033FD60 First=0042000 (copied by hand) It doesn't crash without -g. It doesn't crash when you reduce the number of template instantiations, or reduce the references to instantiated templates (you can vary these by changing the numbers in the program). Bug 3870 is probably the same bug, but I can't possibly know (the register contents are completely different). The test case works perfectly fine on Linux. ---- this is file x.d: template Tuple(T...) { alias T Tuple; } template Repeat(int count) { static if (!count) { alias Tuple!() Repeat; } else { alias Tuple!(count-1, Repeat!(count-1)) Repeat; } } void sometemplate(int T)() { foreach (x; Repeat!(62)) { sometemplate!(T)(); } } void main() { foreach (x; Repeat!(298)) { sometemplate!(x)(); } }
Comment #1 by nfxjfg — 2010-03-29T18:18:20Z
Funny thing: if I name _exactly_ the same file x2.d, OPTLINK doesn't crash! copy x.d x2.d dmd x.d -g -- OPTLINK crashes dmd x2.d -g -- OPTLINK doesn't crash Let me repeat: this bug is not reproduceable if you change the filename. Makes me wonder what the flying fuck is going on. (Maybe I should mention that I did this under wine on Linux, but I also had someone reproduce the crash on a real Windows.)
Comment #2 by samukha — 2010-03-30T00:32:55Z
I think it has something to do with module names being part of symbol names. When you change the file name the symbol names change as well. FWIW, my development branch of QtD (compiled with dmd 2.042) doesn't link on Windows. This bug may be the cause.
Comment #3 by nfxjfg — 2010-05-07T06:00:12Z
In dmd 1.060, the example above doesn't crash anymore, but this does: ------- x.d template Tuple(T...) { alias T Tuple; } template Repeat(int count) { static if (!count) { alias Tuple!() Repeat; } else { alias Tuple!(count-1, Repeat!(count-1)) Repeat; } } void sometemplate(int T)() { foreach (x; Repeat!(320)) { sometemplate!(T)(); } } void main() { foreach (x; Repeat!(498)) { sometemplate!(x)(); } } ------- wine dmd x.d -g Unexpected OPTLINK Termination at EIP=0041338F EAX=0200000A EBX=0200000A ECX=00000000 EDX=65D474DD ESI=0033FE7C EDI=65D474DD EBP=0033FED4 ESP=0033FD60 First=00402000 There's lots of similarities in the test case and register dump, so I suppose it's the same bug.
Comment #4 by nfxjfg — 2010-05-31T13:09:20Z
Does anyone know what Walter thinks about this? When can we expect a fix?
Comment #5 by e.insafutdinov — 2010-05-31T13:20:31Z
(In reply to comment #4) > Does anyone know what Walter thinks about this? > When can we expect a fix? Same question. This bug(or a similar one) has been a pain for building QtD on Windows. It occurs or it doesn't depending on some unrelated factors.
Comment #6 by bugzilla — 2010-08-25T12:31:20Z
I can reproduce it, it appears to be related to the -g switch. The object file is very large, it perhaps is caused by a counter overflow.
Comment #7 by bugzilla — 2010-09-01T01:08:56Z
Fixed with link 8.00.6
Comment #8 by h3r3tic — 2010-09-01T04:07:12Z
(In reply to comment #7) > Fixed with link 8.00.6 I haven't tested against this very example, but your latest patch also seems to fix a crash at a different EIP I've been getting since the last few days (repro too large): EIP=00425343 EAX=0001B04C EBX=00000202 ECX=00000004 EDX=01160000 ESI=0043B544 EDI=01164000 EBP=0012FFF0 ESP=0012FF7C First=00402000 If this is true and not just a random magical arrangement of electrons and planets, I might arrange a little party tonight O_O Much appreciated!
Comment #9 by nfxjfg — 2010-09-01T10:38:34Z
It's like the fixing of bug 424 all over again!
Comment #10 by bugzilla — 2010-09-05T03:28:45Z
The overflow would happen when some of the data structures exceeded 128K in size. I checked the other seg faults for optlink in Bugzilla, but those apparently have different causes.