Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » U++ Library support » U++ Callbacks and Timers » SetTimeCallback failure on arch=armv5l POSIX_PLATFORM
SetTimeCallback failure on arch=armv5l POSIX_PLATFORM [message #16546] Tue, 24 June 2008 17:10 Go to next message
jlfranks is currently offline  jlfranks
Messages: 57
Registered: May 2007
Location: Houston, TX, USA
Member
We have discovered a flaw with SetTimeCallback on an armv5l architecture with the Linux 2007.1 distribution compiled w/ GNU 4.2 eabi.

We are not sure if it is a Upp problem or not because it works fine on i686 Linux.

The Upp Clock program is our simplified test example.

We set the target system clock raw ticks to (decimal) 1213999990 and watch it count up to 1213999999 and then roll to 1214000000, the Clock program timer callback stops being called.

We've also tested 1214999990 and see the same behavior when it rolls over from 1214999999 to 1215000000, the clock appears to stop, and the timer callback is not called.

We ran 'top' and it shows that there is basically no CPU usage by the Clock program -- so, it is not going cpu-bound.

If we restart the Clock program just past the roll-over, everything works great (until the next roll-over).

We are perplexed in that we don't really know where to look for the problem. Is there a mechanism in Upp that could cause this?

Where else should we look for the problem. Is X involved somehow?

Any suggestion on how to proceed would be greatly appreciated.

NOTE: we have used Upp extensivly on the arv5l architecture and have just discovered the problem. Everything else in Upp works as it should.

--jlf

Report message to a moderator

Resolved: SetTimeCallback failure on arch=armv5l POSIX_PLATFORM [message #16556 is a reply to message #16546] Wed, 25 June 2008 17:44 Go to previous messageGo to next message
jlfranks is currently offline  jlfranks
Messages: 57
Registered: May 2007
Location: Houston, TX, USA
Member
We were able to identify the problem to line 88 of CtrlTime.cpp
and applied a correction as follows:

void Ctrl::TimerProc(dword time)
{
sTimerLock.Enter();
TimeEvent *list = tevents();
if(sTClick > time)
for(TimeEvent *e = list->GetNext(); e != list; e = e->GetNext())
// if(e->time > 0x80000000)
if(e->time >= 1000000000) // --jlf fixes freeze on 06/20/2008 22:13:20
e->time = 0;
sTClick = time;
sTimerLock.Leave();
Ctrl::CheckMouseCtrl();
Ctrl::SyncCaret();
sTimerLock.Enter();

while(list->GetNext() != list && list->GetNext()->time < time) {
TimeEvent *e = list->GetNext();
e->Unlink();
if(e->delay < 0)
sTimeCallback(time - e->delay, e->delay, e->cb, e->id);
sTimerLock.Leave();
e->cb();
sTimerLock.Enter();
delete e;
}
sTimerLock.Leave();
}

Report message to a moderator

Re: Resolved: SetTimeCallback failure on arch=armv5l POSIX_PLATFORM [message #16557 is a reply to message #16556] Wed, 25 June 2008 23:42 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
I do not think this is correct fix. This is supposed to with situation when time "wraps around" the dword.

The idea here is that most recent entries are in the second half of dword range when it wraps. Anyway, at the moment time already passed them. So they are reset to 0.

Well, anyway, I guess I just do not see the trouble. What do you achieve changing 0x80000000 to 1000000000 ?

Mirek

Report message to a moderator

Re: SetTimeCallback failure on arch=armv5l POSIX_PLATFORM [message #16558 is a reply to message #16546] Thu, 26 June 2008 09:16 Go to previous messageGo to next message
mr_ped is currently offline  mr_ped
Messages: 825
Registered: November 2005
Location: Czech Republic - Praha
Experienced Contributor
Mirek: I would expect ">= 0x80000000", not sharp ">", if it is supposed to handle wrap of dword.

Edit: wait a second, too early in morning for me Sad. This does not make sense too... ">" vs ">=" would make sense only if there were also some signed/unsigned problem elsewhere.

1000000000 = 0x3B9ACA00
so it means it thinks about "wrap" sooner, but I don't get the rest of the code, so I have no overall idea.

[Updated on: Thu, 26 June 2008 09:18]

Report message to a moderator

Re: SetTimeCallback failure on arch=armv5l POSIX_PLATFORM [message #16559 is a reply to message #16558] Thu, 26 June 2008 10:41 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
mr_ped wrote on Thu, 26 June 2008 03:16

Mirek: I would expect ">= 0x80000000", not sharp ">", if it is supposed to handle wrap of dword.

Edit: wait a second, too early in morning for me Sad. This does not make sense too... ">" vs ">=" would make sense only if there were also some signed/unsigned problem elsewhere.

1000000000 = 0x3B9ACA00
so it means it thinks about "wrap" sooner, but I don't get the rest of the code, so I have no overall idea.


Yes, I was thinking about signed/unsinged too... But IMO it should be OK.

Mirek

Report message to a moderator

Re: SetTimeCallback failure on arch=armv5l POSIX_PLATFORM [message #16564 is a reply to message #16559] Thu, 26 June 2008 16:25 Go to previous messageGo to next message
jlfranks is currently offline  jlfranks
Messages: 57
Registered: May 2007
Location: Houston, TX, USA
Member

We put cout statements in the code during debug and found
that overflow did not occur because of the following code
in Util.cpp

The reset to a correct value must occur earlier than the
range of the int because of the modulo math in GetTickCount().


#ifdef PLATFORM_POSIX
int GetTickCount() {
struct timeval tv[1];
struct timezone tz[1];
memset(tz, 0, sizeof(tz));
gettimeofday(tv, tz);
return tv->tv_sec % 1000000 * 1000 + tv->tv_usec / 1000;
}
#endif


--jlf

Report message to a moderator

Re: SetTimeCallback failure on arch=armv5l POSIX_PLATFORM [message #16565 is a reply to message #16564] Thu, 26 June 2008 18:16 Go to previous message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
jlfranks wrote on Thu, 26 June 2008 10:25


We put cout statements in the code during debug and found
that overflow did not occur because of the following code
in Util.cpp

The reset to a correct value must occur earlier than the
range of the int because of the modulo math in GetTickCount().


#ifdef PLATFORM_POSIX
int GetTickCount() {
struct timeval tv[1];
struct timezone tz[1];
memset(tz, 0, sizeof(tz));
gettimeofday(tv, tz);
return tv->tv_sec % 1000000 * 1000 + tv->tv_usec / 1000;
}
#endif


--jlf


Excellent, thanks! That is it...

Anyway, I guess it is rather worth fixing this function and make it return dword. I believe this should do the trick:

dword GetTickCount() {
	struct timeval tv[1];
	struct timezone tz[1];
	memset(tz, 0, sizeof(tz));
	gettimeofday(tv, tz);
	return (dword)tv->tv_sec * 1000 + tv->tv_usec / 1000;
}


Can you confirm?

Mirek

Report message to a moderator

Previous Topic: Is there an easy way to leverage callback into multi-cast delegate?
Next Topic: SetTimeCallback without Graphics
Goto Forum:
  

[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Thu Apr 18 05:02:30 CEST 2024

Total time taken to generate the page: 0.01541 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.5.
Copyright ©2001-2013 FUDforum Bulletin Board Software