2014/1/13 Andres Valloud <avalloud@smalltalk.comcastbiz.net>
My friend, you need to believe :)...
Ok, so with Cuis the image hangs (unresponsive to input) when the clock goes forward. With Pharo 2.0 (just checked), the image hangs when the clock goes backwards. To verify, simply create a new process that periodically writes something to the Transcript, such as
p := [ [ (Delay forSeconds: 1) wait. Transcript cr; show: Time now seconds printString ] repeat ] newProcess. p resume
then go to the system settings panel, time section, uncheck the automatic time keeping, bump the clock up by one minute, save (note the skew in the Transcript output), then re-enable automatic time keeping, make sure the settings are saved... and now the image is unresponsive. Alt+. does nothing etc. Wait one minute. After that time, you will get a debugger and things will start happening again.
If you can't immediately reproduce it, I really suspect that if you play with the time for a bit you will get some weird behavior too.
On 1/13/14 1:18 , Esteban Lorenzano wrote:
Hi Andres,
Pharo (Cuis) does not exit⦠I suppose you are talking about the vm from Pharo, used with a Cuis image⦠can you confirm that same problem exists in pharo-vm with pharo-image?
Esteban
On 13 Jan 2014, at 09:37, Andres Valloud <avalloud@smalltalk. comcastbiz.net> wrote:
Try the following on OS X...
1. Launch Pharo (Cuis).
2. Go to the System Settings time panel.
3. Disable automatic time updates.
4. Bump the clock forward by 1 minute.
5. Check whether Pharo is still responsive (in the case of Cuis, it's frozen).
6. Wait one minute.
7. Check whether Pharo is still responsive (in the case of Cuis, it's responsive again).
As a variation, disable automatic time updates, then bump the clock backwards by 1 minute. Things still work. Then re-enable automatic time updates. When the clock goes forward, the prediction is that Pharo (Cuis) will be frozen for 1 minute.
If this repeats for you, then also look at /var/log/system.log and see how many entries are there for NTP. If you see that NTP periodically adjusts the clock forward, then you can also expect that Pharo (Cuis) will periodically be frozen for as much time as NTP (and, on OS X 10.9, pacemaker) bumps the clock forward.
I can reproduce this behavior on OS X 10.9 with a modern Cog VM and Cuis images.
On 1/13/14 0:22 , Sven Van Caekenberghe wrote:
Hi Andres,
Could you describe in some detail how to make something clearly fail related to this issue ?
There have been mysterious time(r) related problems in the past, it would be good to follow up on something concrete and repeatable.
Thx,
Sven
On 12 Jan 2014, at 04:41, Andres Valloud <avalloud@smalltalk. comcastbiz.net> wrote:
Somewhat related only, but FYI something I've noticed with Cog VMs is
that if you bump the computer clock forward by e.g. 30 seconds then Cuis remains frozen for 30 seconds. Under the assumption that Cuis and Pharo are close enough, and considering that alt+. does not bring up a debugger while the image remains frozen, I can't help asking whether the VM is setting up OS alarms at a certain wall clock hour instead of setting up timers that expire after N time has elapsed (irrespective of the wall clock). If the VM is setting up alarms at wall clock hours, then I'd strongly suggest changing that behavior because of NTP, time zone adjustments, etc.
BTW, I found this because apparently Mavericks isn't keeping time that great and NTP frequently changes the clock by ~2 seconds.
On 1/11/14 19:29 , Martin McClure wrote:
I'm beginning to suspect that delays are not expiring at the OS level
.
.
Yes, chaging the system time is a known issue for pharos linux-vm: 11324 <https://pharo.fogbugz.com/default.asp?11324> Image freeze when changing system time