Segfault when using SysTime
spam_D at asylum.id.au
Fri Nov 4 02:07:56 PDT 2011
Jonathan M Davis wrote:
> On Friday, November 04, 2011 18:53:28 knommad wrote:
>> (I'm not sure whether I should be posting these here...apologies if this
>> is inappropriate).
>> Test case: (test.d)
>> import std.datetime;
>> import std.stdio;
>> void main()
>> // SysTime is a struct that should be default initialised
>> SysTime unInitialisedTime;
>> // Will segfault on this next line...
>> writeln("Time is: ", unInitialisedTime );
>> writeln("ending now...");
>> Compiled with dmd 2.056: dmd -wi -oftest test.d.
>> Segmentation Fault.
>> I did attempt to delve into the intricacies of the std.datetime library,
>> but understanding the techniques used is currently beyond my skill level.
>> Obviously, something is not being initialised properly?
> Similar to how float.init is not a valid value (float.NAN), SysTime.init
> is not a valid value. Aside from arguments over whether a struct's init
> value should be a value intended to be used or not, SysTime has a member
> which is a class - TimeZone - and since CTFE can't handle classes - let
> alone one which is initialized at compile time and then used at runtime -
> SysTime.init _cannot_ have a valid TimeZone and therofere SysTime.init
> cannot be valid (unless we were to introduce the extra overhead of
> constantly checking that the TimeZone isn't null and setting it to
> LocalTime if it is, which is unacceptable IMHO). And since, SysTime.init
> isn't valid, you _must_ initialize a SysTime if you want to avoid
> If you want to know more about std.datetime, I suggest that you read this
> - Jonathan M Davis
Thanks for the answer (nicely written article btw).
I actually found this issue via a problematic path. I'm writing a (multi-
threaded) application in D (within the company I work for), and have
structures that have SysTime elements within them. I hadn't always been
ensuring that this member was initialised properly (not always important for
the task), but when I wanted to toString() the members - I had a silent
The silent death was not a segfault, and gdb considered the application to
have exited normally. This was not easy to nail down ! (a nice segfault
would have been helpful at that point....:)
I guess I'm also expecting (hoping ?) that stray pointer-like behaviours in
D to be few and far between (as opposed to the float.NAN issue). I'm happy
to accept that I may be naive here, however.
Keep up the good work !
When the student is ready, the teacher will appear
-- Buddhist Proverb
More information about the Digitalmars-d