bugGnash - The GNU Flash player - Bugs: bug #21289, Timer: assertion failure when...

 
 

bug #21289: Timer: assertion failure when running Gnash for a long time (or resetting system timer)

Submitted by:  Udo Giacomozzi <udog>
Submitted on:  Mon 08 Oct 2007 09:50:46 AM UTC  
 
Category: coreSeverity: 3 - Normal
Release: NoneStatus: None
Privacy: PublicAssigned to: Udo Giacomozzi <udog>
Open/Closed: Closed

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

Fri 10 Dec 2010 06:40:43 AM UTC, comment #12:

No activity, closed.

Benjamin Wolsey <bwy>
Project Member
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...

Sandro Santilli <strk>
Project Member
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.

Udo Giacomozzi <udog>
Project MemberIn charge of this item.
Thu 08 Nov 2007 09:06:15 PM UTC, comment #9:

I've tested this for over 90 minutes, and it's fine.

Benjamin Wolsey <bwy>
Project Member
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.

Sandro Santilli <strk>
Project Member
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.

Udo Giacomozzi <udog>
Project MemberIn charge of this item.
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.

Sandro Santilli <strk>
Project Member
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.

Udo Giacomozzi <udog>
Project MemberIn charge of this item.
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...

Udo Giacomozzi <udog>
Project MemberIn charge of this item.
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)

Sandro Santilli <strk>
Project Member
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.

Udo Giacomozzi <udog>
Project MemberIn charge of this item.
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.

Sandro Santilli <strk>
Project Member
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.

Udo Giacomozzi <udog>
Project MemberIn charge of this item.

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by bwy (Posted a comment)
  • -unavailable- added by strk (Posted a comment)
  • -unavailable- added by udog (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 9 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Fri 10 Dec 2010 06:40:42 AM UTCbwyOpen/ClosedOpen=>Closed
    Wed 16 Jan 2008 09:05:44 AM UTCstrkCategoryNone=>core
      Assigned toNone=>udog
      SummaryTimer: assertion failure when running Gnash for a long time=>Timer: assertion failure when running Gnash for a long time (or resetting system timer)
    Sat 05 Jan 2008 01:08:02 PM UTCudogStatusFixed=>None
      Open/ClosedClosed=>Open
    Thu 08 Nov 2007 09:06:15 PM UTCbwyStatusReady For Test=>Fixed
      Open/ClosedOpen=>Closed
    Mon 08 Oct 2007 04:06:36 PM UTCudogStatusNone=>Ready For Test

    Back to the top


    Powered by Savane 3.1-cleanup1