Segfault when using SysTime

[knommad]

Jonathan M Davis wrote:

> On Friday, November 04, 2011 18:53:28 knommad wrote:
>> Hi,
>> 
>> (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.
>> 
>> Result:
>> 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
> segfaults.
> 
> If you want to know more about std.datetime, I suggest that you read this
> article:
> 
> http://d-programming-language.org/intro-to-datetime.html
> 
> - Jonathan M Davis

Hi,
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 
death. 

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 !

regards,
ted

-- 
                   When the student is ready, the teacher will appear
                                                  -- Buddhist Proverb