Hi everybody. I hope you are enjoying a wonderful and happy Christmas.
Yesterday something weird happened with my cog vm. This assert was failing:
"newUtcMicrosecondClock >= utcMicrosecondClock 127"
a lot of times...
I checked and this is line 127 of sqUnixHeartbeat.c. I am in a MacOS vm, but it seems that file is used anyway.
Now...I have no idea why this assert was failing, nor its severity. What does it mean? there is something wrong? where can I take a look?
It seems it is not easy to reproduce :(
Thanks in advance,
Mariano
On 25 December 2010 16:56, Mariano Martinez Peck marianopeck@gmail.com wrote:
Hi everybody. I hope you are enjoying a wonderful and happy Christmas.
Yesterday something weird happened with my cog vm. This assert was failing:
"newUtcMicrosecondClock >= utcMicrosecondClock 127"
a lot of times...
I checked and this is line 127 of sqUnixHeartbeat.c. I am in a MacOS vm, but it seems that file is used anyway.
Now...I have no idea why this assert was failing, nor its severity. What does it mean? there is something wrong? where can I take a look?
if microseconds clock counter is 32-bit, then it wraps over time to time. VM should be aware that this may happen and should take appropriate measures (like adjusting the wait timeouts etc).
It seems it is not easy to reproduce :(
yeah, you should wait another ~ 2^32 / 1000000 seconds
Thanks in advance,
Mariano
On Sat, Dec 25, 2010 at 12:20 PM, Igor Stasenko siguctua@gmail.com wrote:
On 25 December 2010 16:56, Mariano Martinez Peck marianopeck@gmail.com wrote:
Hi everybody. I hope you are enjoying a wonderful and happy Christmas.
Yesterday something weird happened with my cog vm. This assert was
failing:
"newUtcMicrosecondClock >= utcMicrosecondClock 127"
a lot of times...
I checked and this is line 127 of sqUnixHeartbeat.c. I am in a MacOS vm,
but it seems that file is used anyway.
Now...I have no idea why this assert was failing, nor its severity. What
does it mean? there is something wrong? where can I take a look?
if microseconds clock counter is 32-bit, then it wraps over time to time. VM should be aware that this may happen and should take appropriate measures (like adjusting the wait timeouts etc).
The microsecond clock is 64-bit to avoid precisely the possibility of the clock wrapping within anything other than wildly optimistic predictions of the possible life of Smalltalk.
It seems it is not easy to reproduce :(
yeah, you should wait another ~ 2^32 / 1000000 seconds
By all means but you won't see it wrap.
Thanks in advance,
Mariano
-- Best regards, Igor Stasenko AKA sig.
On 26 December 2010 01:12, Eliot Miranda eliot.miranda@gmail.com wrote:
On Sat, Dec 25, 2010 at 12:20 PM, Igor Stasenko siguctua@gmail.com wrote:
On 25 December 2010 16:56, Mariano Martinez Peck marianopeck@gmail.com wrote:
Hi everybody. I hope you are enjoying a wonderful and happy Christmas.
Yesterday something weird happened with my cog vm. This assert was failing:
"newUtcMicrosecondClock >= utcMicrosecondClock 127"
a lot of times...
I checked and this is line 127 of sqUnixHeartbeat.c. I am in a MacOS vm, but it seems that file is used anyway.
Now...I have no idea why this assert was failing, nor its severity. What does it mean? there is something wrong? where can I take a look?
if microseconds clock counter is 32-bit, then it wraps over time to time. VM should be aware that this may happen and should take appropriate measures (like adjusting the wait timeouts etc).
The microsecond clock is 64-bit to avoid precisely the possibility of the clock wrapping within anything other than wildly optimistic predictions of the possible life of Smalltalk.
How about Eistein's special relativity? :) A 64-bit clock wrap could happen within Smalltalk life time, if you get enough speed.
It seems it is not easy to reproduce :(
yeah, you should wait another ~ 2^32 / 1000000 seconds
By all means but you won't see it wrap.
it depends to what value is a counter were reset at a boot time. You know, some nasty guys could set it to #FF FF FF FF FF FF 00 00 to intentionally spoil your optimistic expectations. :) I would do that in my system. So developers will learn how to write a 64-bit-overflow proof code :)
But if seriously yeah.. it is hard to imagine what may cause 64-bit counter to wrap. :)
vm-dev@lists.squeakfoundation.org
-
Eliot Miranda -
Igor Stasenko -
Mariano Martinez Peck