Bug 4904 – Win32 phobos unittest crashes with access violation

dmd r680 phobos trunk r2043 Paste the following code at the bottom of phobos/unittest.d. This simply increases the size of unittest executable. -------------------- unittest { struct K(Q...) { static if (Q.length < 5) static K!(Q, int) next; Q q; } static K!byte a1; static K!short a2; static K!int a3; static K!long a4; static K!ubyte a5; static K!ushort a6; static K!uint a7; static K!ulong a8; static K!float a9; static K!double a10; static K!real a11; static K!char a12; static K!wchar a13; static K!dchar a14; } -------------------- Then, run the phobos unittest on Windows. It will crash. -------------------- >make -f win32.mak unittest ... unittest object.Error: Access Violation -------------------- Access violation seems to start happening when the size of executable exceeds some critical point. Sometimes the AV didn't occur, and alternatively the test showed weird behavior - such as infinitely failing unittests or broken output. See this message and follow ups. http://lists.puremagic.com/pipermail/phobos/2010-September/002609.html Auto tester output: http://d.puremagic.com/test-results/test_data.ghtml?dataid=3525

Even with phobos svn revision 2014, dmd outputs 16424 symbols for the unittest executable, which triggers bug 3372 in optlink. It can generate any kind of bad behaviour.

It looks like Walter's fixes for 3372 have worked, I can't recreate the AV on 2.053. Can we close this?

It was fixed by my refactoring of the makefile into three .obj files for unittest, instead of two.

(In reply to comment #3) > It was fixed by my refactoring of the makefile into three .obj files for > unittest, instead of two. You mean separating modules into SRCS_1, SRCS_2, and SRCS_3, like in the windows makefile? I've tried merging the 3, and it seems to work fine that way.

(In reply to comment #4) > (In reply to comment #3) > > It was fixed by my refactoring of the makefile into three .obj files for > > unittest, instead of two. > > You mean separating modules into SRCS_1, SRCS_2, and SRCS_3, like in the > windows makefile? I've tried merging the 3, and it seems to work fine that way. The SRCS_1, SRCS_2, SRCS_3 in the makefile *is* the change I made. Note that the order is important. (The list of which modules are in which part is not arbitrary).

(In reply to comment #5) > (In reply to comment #4) > > (In reply to comment #3) > > > It was fixed by my refactoring of the makefile into three .obj files for > > > unittest, instead of two. > > > > You mean separating modules into SRCS_1, SRCS_2, and SRCS_3, like in the > > windows makefile? I've tried merging the 3, and it seems to work fine that way. > > The SRCS_1, SRCS_2, SRCS_3 in the makefile *is* the change I made. Note that > the order is important. (The list of which modules are in which part is not > arbitrary). Yeah, the comment in the makefile makes a note of why they're split. But I'm not getting any errors running unittests if I merge and compile them all at once, maybe the new optlink fixes whatever issues were had that made you split he modules like that.

The optlink fix for 3372 increased the number of allowed symbols for each OMF object file from 16384 to 32768. So expect to hit that limit too with growing projects built into a single object file. In that case the compiler now reports an error.