Testing generated/freebsd/debug/32/unittest/std/date
std.date and std.dateparse have been scheduled for deprecation. Please use std.d
atetime instead.
Testing generated/freebsd/debug/32/unittest/std/datetime
gmake[2]: *** [generated/freebsd/debug/32/unittest/std/datetime] Killed: 9
gmake[1]: Leaving directory `/usr/home/walter/cbx/mars/phobos'
gmake[1]: *** [unittest] Error 2
gmake: *** [unittest] Error 2

> Testing generated/freebsd/debug/32/unittest/std/date
> std.date and std.dateparse have been scheduled for deprecation. Please use
> std.d atetime instead.
> Testing generated/freebsd/debug/32/unittest/std/datetime
> gmake[2]: *** [generated/freebsd/debug/32/unittest/std/datetime] Killed: 9
> gmake[1]: Leaving directory `/usr/home/walter/cbx/mars/phobos'
> gmake[1]: *** [unittest] Error 2
> gmake: *** [unittest] Error 2

Yuck. I haven't the slightest clue what to do about that. There's no meaningful error there whatsoever. Bleh.

I may have to take the time and set up a FreeBSD box (probably in VirtualBox) one of these days soon, which will likely be quite unpleasant (or at least quite time-consuming) given the fact that I've never done anything with any BSD (though I use Linux all the time, so that'll help considerably). Short of doing that, I haven't a clue how to go about fixing it.

And I'm not even sure that my going and doing that will help given that std.datetime passes on the autotester. There must be something critically different between your machine and the autotester.

Bleh. I hate these sort of problems. Give me a nice logic bug over this sort of stuff any day. But such is life.

- Jonathan M Davis

On 4/30/2011 4:52 PM, Jonathan M Davis wrote:
>> Testing generated/freebsd/debug/32/unittest/std/date
>> std.date and std.dateparse have been scheduled for deprecation. Please use
>> std.d atetime instead.
>> Testing generated/freebsd/debug/32/unittest/std/datetime
>> gmake[2]: *** [generated/freebsd/debug/32/unittest/std/datetime] Killed: 9
>> gmake[1]: Leaving directory `/usr/home/walter/cbx/mars/phobos'
>> gmake[1]: *** [unittest] Error 2
>> gmake: *** [unittest] Error 2
> 
> Yuck. I haven't the slightest clue what to do about that. There's no meaningful error there whatsoever. Bleh.
> 
> I may have to take the time and set up a FreeBSD box (probably in VirtualBox) one of these days soon, which will likely be quite unpleasant (or at least quite time-consuming) given the fact that I've never done anything with any BSD (though I use Linux all the time, so that'll help considerably). Short of doing that, I haven't a clue how to go about fixing it.
> 
> And I'm not even sure that my going and doing that will help given that std.datetime passes on the autotester. There must be something critically different between your machine and the autotester.
> 
> Bleh. I hate these sort of problems. Give me a nice logic bug over this sort of stuff any day. But such is life.
> 
> - Jonathan M Davis

Interesting.. since obviously this test isn't and hasn't been failing on the auto-tester.  Walter, what version of freebsd are you running?  The auto-tester is running 8.1.

I'm pretty sure it's 8.1.

Not sure if it's related, but at work we had a strange issue with some process being unexpectedly killed on Linux.? The root cause turned out to be the process using too much memory.? Apparently, if the system gets critically low on memory, the kernel selects the worst offender and kills it.

Of course, that's Linux, but I think BSD and linux have cross pollinating ideas sometimes.

But it might be a start to compare the amount of memory this system has with the auto-tester which does not fail.


-Steve




>________________________________
>From: Walter Bright <walter at digitalmars.com>
>To: Discuss the phobos library for D <phobos at puremagic.com>
>Sent: Friday, April 29, 2011 8:16 PM
>Subject: [phobos] FreeBSD 32 still fails unittests for std.datetime
>
>Testing generated/freebsd/debug/32/unittest/std/date
>std.date and std.dateparse have been scheduled for deprecation. Please use std.d
>atetime instead.
>Testing generated/freebsd/debug/32/unittest/std/datetime
>gmake[2]: *** [generated/freebsd/debug/32/unittest/std/datetime] Killed: 9
>gmake[1]: Leaving directory `/usr/home/walter/cbx/mars/phobos'
>gmake[1]: *** [unittest] Error 2
>gmake: *** [unittest] Error 2
>_______________________________________________
>phobos mailing list
>phobos at puremagic.com
>http://lists.puremagic.com/mailman/listinfo/phobos
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20110502/1aa47fa2/attachment.html>

> Not sure if it's related, but at work we had a strange issue with some process being unexpectedly killed on Linux.  The root cause turned out to be the process using too much memory.  Apparently, if the system gets critically low on memory, the kernel selects the worst offender and kills it.
> 
> Of course, that's Linux, but I think BSD and linux have cross pollinating ideas sometimes.
> 
> But it might be a start to compare the amount of memory this system has with the auto-tester which does not fail.

Well, it could be related to http://d.puremagic.com/issues/show_bug.cgi?id=5454

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.

- Jonathan M Davis

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().

On 05/02/2011 05:53 AM, Steve Schveighoffer wrote:
> Not sure if it's related, but at work we had a strange issue with some process being unexpectedly killed on Linux.  The root cause turned out to be the process using too much memory.  Apparently, if the system gets critically low on memory, the kernel selects the worst offender and kills it.
>
> Of course, that's Linux, but I think BSD and linux have cross pollinating ideas sometimes.
>
> But it might be a start to compare the amount of memory this system has with the auto-tester which does not fail.

It's called the OOM killer: http://linux-mm.org/OOM_Killer and I don't know if BSD has one (a quick google gives conflicting results).

> -Steve
>
>     ------------------------------------------------------------------------
>     *From:* Walter Bright <walter at digitalmars.com>
>     *To:* Discuss the phobos library for D <phobos at puremagic.com>
>     *Sent:* Friday, April 29, 2011 8:16 PM
>     *Subject:* [phobos] FreeBSD 32 still fails unittests for std.datetime
>
>     Testing generated/freebsd/debug/32/unittest/std/date
>     std.date and std.dateparse have been scheduled for deprecation.
>     Please use std.d
>     atetime instead.
>     Testing generated/freebsd/debug/32/unittest/std/datetime
>     gmake[2]: *** [generated/freebsd/debug/32/unittest/std/datetime]
>     Killed: 9
>     gmake[1]: Leaving directory `/usr/home/walter/cbx/mars/phobos'
>     gmake[1]: *** [unittest] Error 2
>     gmake: *** [unittest] Error 2
>     _______________________________________________
>     phobos mailing list
>     phobos at puremagic.com <mailto:phobos at puremagic.com>
>     http://lists.puremagic.com/mailman/listinfo/phobos
>
>
>
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20110502/c6e31be4/attachment.html>

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 see you're using "class Clock" as a namespace. Defining a class creates a bunch of static data, like the vtbl[] for it. Better to make it a struct. But that still generates TypeInfo.

Even better to just call the functions with a common prefix, which you already do, i.e. "curr". Then there's no overhead bloat.