Fri 10 Dec 2010 06:40:43 AM UTC, comment #12:
No activity, closed.
|
Sat 05 Jan 2008 02:24:15 PM UTC, comment #11:
Remember that we're using a VirtualClock by now,
the SystemClock derivate in particular.
You may tweak SystemClock class to take time drifts
into account by recomputing starting time and maintain
an offset...
|
Sat 05 Jan 2008 01:08:02 PM UTC, comment #10:
I open this bug again because I still have this problem. However, I think I know the reason.
The VM timer in the end still calls get_profile_ticks() from tu_timer.cpp which depends on system time. The system time is not suitable for timing purposes since it can be changed/corrected at any time. Just think of ntpdate skipping some seconds.
The problem described in this bug comes up when the system time is set to some time in the past (relative to the previous system time). This makes also the timer jump backward.
In my specific case it's a daemon that resyncs time every 6 minutes and it can happen that it sets a time in the past.
The only safe way for a timer under Linux is /proc/uptime. The problem is that it it's just 1/100th second accurate and that it's relatively CPU expensive to read and parse that file.
|
Thu 08 Nov 2007 09:06:15 PM UTC, comment #9:
I've tested this for over 90 minutes, and it's fine.
|
Tue 09 Oct 2007 05:58:50 AM UTC, comment #8:
setInterval uses VM::getTime internally. So for whoever is going to test, a setInterval call should do.
|
Mon 08 Oct 2007 09:07:29 PM UTC, comment #7:
I think so. My movie did not use getTimer() at all. My movie contained only one small AS code using setInterval() which in the handler function updated a text variable.
|
Mon 08 Oct 2007 05:19:29 PM UTC, comment #6:
really any movie ? also an empty one ?
could you provide the closest to empty if empty is not enough ?
AS code only is fine.
|
Mon 08 Oct 2007 04:06:36 PM UTC, comment #5:
Ready for test. Just keep Gnash running any kind of movie (no animation necessary). If it doesn't crash after 70 minutes, it's fine.
|
Mon 08 Oct 2007 04:01:47 PM UTC, comment #4:
Do you mean what resolution getTimer() in ActionScript should have? Milliseconds (1000 = one second).
My patch seems to work. I'll commit it now...
|
Mon 08 Oct 2007 02:45:02 PM UTC, comment #3:
Ok, I see. For the timers themselves it shouldn't be a problem.
More concerned about VM time, which I belive is exposed to ActionScript. Do you know what resolution should VM time have ?
Would be ActionGetTimer (0x34)
|
Mon 08 Oct 2007 02:40:11 PM UTC, comment #2:
Yes, but getTime() ends in a call to get_profile_ticks() which calculates:
uint64_t result = tv.tv_sec * 1000000;
tv_sec is of type "time_t" which is system-dependent and probably 32 bits on my system. I've patched the file and currently test if it works (which takes at least an hour).
Anyway, here's the info you wanted:
now=53
_start=4294967265
lt-gtk-gnash: timers.cpp:100: bool gnash::Timer::expired(): Assertion `now >= _start' failed.
You see, near the 32 bit limit.
|
Mon 08 Oct 2007 09:55:49 AM UTC, comment #1:
uint64_t bounds account for 18446744073709551616 milliseconds
which should give 5124095576030 hours.
A time glitch could be possible though.
And we're using gettimeofday, so wall clock (daylight saving
time might trigger gnash abortion).
I suggest you change the assertion to print the actual values.
|
Mon 08 Oct 2007 09:50:46 AM UTC, original submission:
When running a simple Flash movie with Gnash for a long time (an hour or so) Gnash exits with an assertion failure:
lt-gtk-gnash: timers.cpp:94: bool gnash::Timer::expired(): Assertion `now >= _start' failed.
Tried with current HEAD.
I'll try to find out the exact duration.
|