[phobos] FreeBSD 32 still fails unittests for std.datetime

[Jonathan M Davis]

> On 5/2/2011 9:18 PM, Walter Bright wrote:
> > On 5/2/2011 1:14 PM, Jonathan M Davis wrote:
> >> The problem is far worse on Windows than on Linux - both in terms of the
> >> amount of memory eaten by dmd and because the Windows unit tests are all
> >> compiled together instead of separately, but dmd still eats too much
> >> memory on OSes other than Windows. FreeBSD would have the unit tests
> >> compiled separately like on Linux, so dmd shouldn't be running out of
> >> memory in the same way as occurs on Windows, but it could still be
> >> using a lot of memory, and if Walter's machine doesn't have a lot of
> >> it, and if FreeBSD tries to kill processes that use too much, then that
> >> could be the problem. On Windows, it very clearly states that dmd ran
> >> out of memory, but if the OS just kills the process, then you might not
> >> get such a clear message.
> >> 
> >> I've been hoping that Don's CTFE fixes would reduce dmd's memory
> >> footprint enough to get rid of issue 5454, but since they're buggy
> >> enough that Phobos' unit tests don't currently build, I have no idea
> >> how close they've gotten to fixing the problem.
> > 
> > On FreeBSD it's getting a "Killed: 9" message while running dmd after
> > running for a looong time. Running under gdb shows it dying somewhere
> > deep in malloc().
> 
> By deleting unittests one by one, I got it to pass dmd. Now if fails with a
> "Killed: 9" message from ld, the linker. Checking the object file for
> datetime.o yields a 4.6 Mb file (and that's without debug info turned
> on!). Clearly, reducing the memory consumption of dmd will not fix this
> problem.
> 
> Compiling std.datetime with -release -O gives a 441,000 byte object file.

I'm afraid that I don't understand what the problem is then. Can the linker 
not handle a 4.6 Mb object file? Granted, that's not a small file, but I 
wouldn't have thought that that would do in the linker.

And, of course, that raises the question as to why the object file is so large 
when compiling with unit tests. Part of it likely comes from the fact that the 
unit tests actually use the stuff in std.datetime, so all of the templated 
types and functions get instantiated, and they wouldn't when just compiling 
Phobos, unless something else in Phobos is using them. And maybe there's 
something in the unit tests which instantiates a bunch of extra templates. I 
don't know. Or did you compile with -release and -O _and_ -unittest? That 
would change things considerably, since that would imply a difference betwen 
release and non-release instead of a difference with regards to whether unit 
tests are compiled in.

Regardless, I don't know why the linker wouldn't like a 4.6 Mb object file. 
And while fixing dmd's memory consumption won't fix the problem, it might make 
it so that dmd actually finishes compiling and moves on to the linker rather 
than forcing you to delete unit tests. And whatever the problem may be, 
clearly it has something to do with the differences between your machine and 
the auto tester, since the auto tester is fine. So, regardless of dmd, 
whatever the linker's problem is, there's something about your machine that 
makes it fail while it succeeds on the auto tester.

And if all you want to do is to not have std.datetime fail on your machine, 
you can remove or comment out the line

    version = testStdDateTime;

(line #145, I believe) on your machine, and none of the std.datetime unit 
tests will be compiled in. It's already not defined on Windows specifically 
because dmd definitely runs out of memory compiling std.datetime on Windows 
when compiling all of Phobos' unit tests: 
http://d.puremagic.com/issues/show_bug.cgi?id=5454 (it does fine, if you 
compile std.datetime separately though).

- Jonathan M Davis