Smalltalk › Instantiations

Server Task crashing during mesz changing ...

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

15 messages Options

Marten Feldtmann-2

Server Task crashing during mesz changing ...

I have a server task and this task is typically crashing two times a year - during the changes of daylight saving time. The last crash was last weekend - I had no time to look for the problem. Just as an information for other long running tasks:

DateAndTime(Object)>>#error:
receiver = Could not print receiver
arg1 = 'bad date'
DateAndTime>>#computeTimeZoneOffset:
receiver = Could not print receiver
arg1 = 3573601200.682
temp1 = 7200
temp2 = 1396141200.682
temp3 = 6.82000160217285e-1
temp4 = 1396141200
temp5 = true
DateAndTime>>#fromMilliseconds:timeZoneRuleSet:
receiver = Could not print receiver
arg1 = 3573601200682
arg2 = Europe/Berlin LMT
temp1 = nil
DateAndTime>>#fromMilliseconds:
receiver = Could not print receiver
arg1 = 3573601200682
DateAndTime class>>#now
receiver = DateAndTime
temp1 = (03/30/2014 03:00:00 AM)

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.

Louis LaBrunda

Re: Server Task crashing during mesz changing ...

Hi Marten,

You say it crashes, is there a walkback?

For my NT services, time changes sometimes results in close to 100% CPU usage. I have looked into this in depth without luck. I have also looked at the Delay class code just in case a time change might cause something there but it looks good. In fact there are tests to see if the millisecond clock jumps with a time change (which it doesn't) but the code should handle it if it did.

Lou

On Tuesday, April 1, 2014 9:15:15 AM UTC-4, Marten Feldtmann wrote:

I have a server task and this task is typically crashing two times a year - during the changes of daylight saving time. The last crash was last weekend - I had no time to look for the problem. Just as an information for other long running tasks:

DateAndTime(Object)>>#error:
receiver = Could not print receiver
arg1 = 'bad date'
DateAndTime>>#computeTimeZoneOffset:
receiver = Could not print receiver
arg1 = 3573601200.682
temp1 = 7200
temp2 = 1396141200.682
temp3 = 6.82000160217285e-1
temp4 = 1396141200
temp5 = true
DateAndTime>>#fromMilliseconds:timeZoneRuleSet:
receiver = Could not print receiver
arg1 = 3573601200682
arg2 = Europe/Berlin LMT
temp1 = nil
DateAndTime>>#fromMilliseconds:
receiver = Could not print receiver
arg1 = 3573601200682
DateAndTime class>>#now
receiver = DateAndTime
temp1 = (03/30/2014 03:00:00 AM)

dmacq

Re: Server Task crashing during mesz changing ...

In reply to this post by Marten Feldtmann-2

Hi Marten,

I created case 54140 and will look into this.

Thanks,

Donald

On Tuesday, April 1, 2014 9:15:15 AM UTC-4, Marten Feldtmann wrote:

I have a server task and this task is typically crashing two times a year - during the changes of daylight saving time. The last crash was last weekend - I had no time to look for the problem. Just as an information for other long running tasks:

DateAndTime(Object)>>#error:
receiver = Could not print receiver
arg1 = 'bad date'
DateAndTime>>#computeTimeZoneOffset:
receiver = Could not print receiver
arg1 = 3573601200.682
temp1 = 7200
temp2 = 1396141200.682
temp3 = 6.82000160217285e-1
temp4 = 1396141200
temp5 = true
DateAndTime>>#fromMilliseconds:timeZoneRuleSet:
receiver = Could not print receiver
arg1 = 3573601200682
arg2 = Europe/Berlin LMT
temp1 = nil
DateAndTime>>#fromMilliseconds:
receiver = Could not print receiver
arg1 = 3573601200682
DateAndTime class>>#now
receiver = DateAndTime
temp1 = (03/30/2014 03:00:00 AM)

jtuchel

Server Task crashing during mesz changing ...

In reply to this post by Marten Feldtmann-2

Hi,

Thi may be off-topic, but our Kontolino-server ran through the dst switch last sunday without any problems. This is on Linux, however.

Joachim

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.

jtuchel

Server Task crashing during mesz changing ...

Okay, our server did not ask for a time at exactly 3am, as yours obviously did ;-)

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.

Marten Feldtmann-2

Re: Server Task crashing during mesz changing ...

In reply to this post by Marten Feldtmann-2

Well - everyone can execute the statement, which crashes:

DateAndTime fromMilliseconds: 3573601200682

And Joachim - the server was Linux based and it crashes also under Windows.

Marten

Louis LaBrunda

Re: Server Task crashing during mesz changing ...

Hi Marten,

That doesn't crash on V8.6 but it does on 8.0.3. So maybe there is a fix.

Apparently the DateAndTime class method fromMilliseconds: is missing.

fromMilliseconds: integerMilliseconds

"Answer a DateAndTime since the Squeak epoch: 1 January 1901"

^self basicNew fromMilliseconds: integerMilliseconds

Lou

On Tuesday, April 1, 2014 12:45:47 PM UTC-4, Marten Feldtmann wrote:

Well - everyone can execute the statement, which crashes:

DateAndTime fromMilliseconds: 3573601200682

And Joachim - the server was Linux based and it crashes also under Windows.

Marten

dmacq

Re: Server Task crashing during mesz changing ...

In reply to this post by Marten Feldtmann-2

Hi Marten,

I am having trouble reproducing this. Do you have any more of the stack dump you could send me? It would help if I knew what your long running process was doing. Also what version of Vast are you running?

Thanks,

Donald

On Tuesday, April 1, 2014 9:15:15 AM UTC-4, Marten Feldtmann wrote:

I have a server task and this task is typically crashing two times a year - during the changes of daylight saving time. The last crash was last weekend - I had no time to look for the problem. Just as an information for other long running tasks:

DateAndTime(Object)>>#error:
receiver = Could not print receiver
arg1 = 'bad date'
DateAndTime>>#computeTimeZoneOffset:
receiver = Could not print receiver
arg1 = 3573601200.682
temp1 = 7200
temp2 = 1396141200.682
temp3 = 6.82000160217285e-1
temp4 = 1396141200
temp5 = true
DateAndTime>>#fromMilliseconds:timeZoneRuleSet:
receiver = Could not print receiver
arg1 = 3573601200682
arg2 = Europe/Berlin LMT
temp1 = nil
DateAndTime>>#fromMilliseconds:
receiver = Could not print receiver
arg1 = 3573601200682
DateAndTime class>>#now
receiver = DateAndTime
temp1 = (03/30/2014 03:00:00 AM)

Marten Feldtmann-2

Re: Server Task crashing during mesz changing ...

The process is a long continuing server, doing every 60 seconds some stuff. The system used under Linux was 8.5.2 based.

It also happens under 8.6 - therefore I stay with 8.6, so that someone might be able to reproduce it (within our timezone).

You can reproduce the error by executing "DateAndTime fromMilliseconds: 3573601200682" (here on my Windows machine).

The exception is thrown within DateAndTime>>computeTimeZoneOffset: anIntegerNumberOfSeconds (with a parameter value of 3573601200.682).

Within this method dstTransitionsExist is set to true and it crashes here ( timeZone isDst is true) and it ends while evaluating

secondsSinceTransition < 3600 ifTrue: [self error: 'bad date']

    dstTransitionsExist
        ifTrue: [
            transitionTime :=
                timeZone timeZoneRule notNil
                    ifTrue: [timeZone timeZoneRule transitionTime]
                    ifFalse: [0].
            secondsSinceTransition := localPosixSeconds - transitionTime.

            timeZone isDst
                ifTrue: [
                    secondsSinceTransition >= 0 "update the changed offset only if we have crossed a DST transition"
                        ifTrue: [
                            timeZoneOffset := timeZone offsetSeconds.
                            secondsSinceTransition < 3600 ifTrue: [self error: 'bad date']]]
                ifFalse: [
                    secondsSinceTransition > 0 ifTrue: [timeZoneOffset := timeZone offsetSeconds]]].

secondsSinceTransition evaluates to 6.82000160217285e-1 .

Actually I do not know, what secondsSinceTransition < 3600 ifTrue: is supposed to do ....

jtuchel

Re: Server Task crashing during mesz changing ...

Hi Marten,

I just tried in my development image with VAST 8.6 and I can confirm the crash. Stack trace is attached.

Just for readers' information: Marten and I are on the same time zone and we had a switch to DST last sunday.

Joachim

stack.txt (9K) Download Attachment

jtuchel

Re: Server Task crashing during mesz changing ...

Marten,

I think secondsSinceTransition is there to tell the number of seconds that have passed since the DST transition. But I don't understand why the fact that the transition happened less than 3600 seconds before means a 'bad date'. The failing method looks a bit odd to me, but I must admit I never studied the details of timezones, not to mention any algorithms associated to that.

Is this some US specific thing because they switch DST at midnight? Here we went from 2 AM to 3AM, so the date still is the same, DST switching here never affects the date.

Joachim

Am Mittwoch, 2. April 2014 08:26:51 UTC+2 schrieb Joachim Tuchel:

Hi Marten,

I just tried in my development image with VAST 8.6 and I can confirm the crash. Stack trace is attached.
Just for readers' information: Marten and I are on the same time zone and we had a switch to DST last sunday.

Joachim

Marten Feldtmann-2

Re: Server Task crashing during mesz changing ...

By the way - I suppose, that the stuff worked under 8.5.2 because the whole DST-switching was broken in that edition. MY Linux edition 8.5.2 broke, because I corrected that problem by using ICU timezone support.

The plain version 8.5.2 under Windows does not show this error.

My guess here is: dst is done at 2 o'clock. The content of the instanceVariable "transitionTime" can now be seen in two different ways: before the dst I would think, that 2 o'clock would be a good value. After dst-transition I would think that 3 o'clock is a good value. Whatever you would like to calculate (seconds before transition or seconds since transition).

It seems, that transitionTime returns the value for 3 o'clock. If the author of this code assumes, that transitionTime returns the value for 2 o'clock its clear, why secondsSinceTransition must be at least 3600: real-time clock delivers 3 o'clock and the transition is assumed to happen at 2 o'clock: therefore at least 3600 must have been elapsed.

Another question I have not solved: what happens in autumn ?

Am Mittwoch, 2. April 2014 08:37:39 UTC+2 schrieb Joachim Tuchel:

Marten,

I think secondsSinceTransition is there to tell the number of seconds that have passed since the DST transition. But I don't understand why the fact that the transition happened less than 3600 seconds before means a 'bad date'. The failing method looks a bit odd to me, but I must admit I never studied the details of timezones, not to mention any algorithms associated to that.
Is this some US specific thing because they switch DST at midnight? Here we went from 2 AM to 3AM, so the date still is the same, DST switching here never affects the date.

Joachim

Am Mittwoch, 2. April 2014 08:26:51 UTC+2 schrieb Joachim Tuchel:
Hi Marten,

I just tried in my development image with VAST 8.6 and I can confirm the crash. Stack trace is attached.
Just for readers' information: Marten and I are on the same time zone and we had a switch to DST last sunday.

Joachim

Louis LaBrunda

Re: Server Task crashing during mesz changing ...

In reply to this post by jtuchel

Hi Guys,

Here in the US the time change is also at 2 AM.

Lou

On Wednesday, April 2, 2014 2:37:39 AM UTC-4, Joachim Tuchel wrote:

Marten,

I think secondsSinceTransition is there to tell the number of seconds that have passed since the DST transition. But I don't understand why the fact that the transition happened less than 3600 seconds before means a 'bad date'. The failing method looks a bit odd to me, but I must admit I never studied the details of timezones, not to mention any algorithms associated to that.
Is this some US specific thing because they switch DST at midnight? Here we went from 2 AM to 3AM, so the date still is the same, DST switching here never affects the date.

Joachim

Am Mittwoch, 2. April 2014 08:26:51 UTC+2 schrieb Joachim Tuchel:
Hi Marten,

I just tried in my development image with VAST 8.6 and I can confirm the crash. Stack trace is attached.
Just for readers' information: Marten and I are on the same time zone and we had a switch to DST last sunday.

Joachim

dmacq

Re: Server Task crashing during mesz changing ...

In reply to this post by dmacq

Hi Marten,

This code snippet blows up:

EsTimeZoneDatabase singleton defaultLocation: 'Europe/Berlin'.
DateAndTime year: 2014 month: 3 day: 30 hour: 3 minute: 0 second: 6.

It should not because it is a valid time.

Joachim, what time zone is your server running?

Donald

jtuchel

Re: Server Task crashing during mesz changing ...

Donald,

it runs in Europe/Berlin

The test with Marten's example was done on a Win7 x64 VM that also runs in Europe/Berlin

Joachim

Am Mittwoch, 2. April 2014 16:45:18 UTC+2 schrieb Donald MacQueen:

Hi Marten,

This code snippet blows up:

EsTimeZoneDatabase singleton defaultLocation: 'Europe/Berlin'.
DateAndTime year: 2014 month: 3 day: 30 hour: 3 minute: 0 second: 6.

It should not because it is a valid time.

Joachim, what time zone is your server running?

Donald