FROM : Gary L. Wade
DATE : Wed Mar 19 23:12:28 2008
If all you're doing is changing the units returned, then all you're doing is extending the time frame to a longer period of time before you run into the same problem. Without looking at your code, there's little extra help we can provide, but I'd say you need to work on what to do with wraparound with a known-wraparound value or change your timing calculation completely.
If all you want to do is just test things as they are, if you know the place where wraparound happens, have you thought about writing your own version of UpTime (e.g., FakeUpTime) and returning a value based on the real UpTime with an appropriate value added so your wraparound time is just a short time away? I'd initialize your addition value so that it starts off with 60 seconds left before wraparound so you don't have to wait very long.
>
>On 19 Mar 2008, at 11:46, David Dunham wrote:
>
>>> Have you checked your code to make sure you're not converting an
>>> uptime (TickCount, Microseconds, etc.) calculation into
>>> milliseconds while using a signed 32-bit value?
>>
>> Well yes, I'm sure the bug is something like that. But I didn't
>> spot anything obvious the last time I had a 25-day machine (which
>> unfortunately got rebooted before I solved the bug). I'd like to be
>> able to debug and see where the value gets flipped negative.
>
>
>It's not actually negative -- I think AbsoluteToDuration maxes out
>after ~25 days. (It doesn't wrap, the way its Windows equivalent does
>after 50.) I'm using AbsoluteToNanoseconds now.
>
>So now I'd still like a way to force UpTime() (it's in
>DriverServices.h) to return a value of 50 days, to test my fix, and
>have QA verify it.
>
>BTW, none of these functions are documented in Xcode. And I updated
>Developer Documentation yesterday...
>
>David Dunham
>Voice/Fax: 206 783 7404 http://www.pensee.com/dunham/
>Imagination is more important than knowledge. -- Albert Einstein
>
>_______________________________________________
>MacOSX-dev mailing list
><email_removed>
>http://www.omnigroup.com/mailman/listinfo/macosx-dev
DATE : Wed Mar 19 23:12:28 2008
If all you're doing is changing the units returned, then all you're doing is extending the time frame to a longer period of time before you run into the same problem. Without looking at your code, there's little extra help we can provide, but I'd say you need to work on what to do with wraparound with a known-wraparound value or change your timing calculation completely.
If all you want to do is just test things as they are, if you know the place where wraparound happens, have you thought about writing your own version of UpTime (e.g., FakeUpTime) and returning a value based on the real UpTime with an appropriate value added so your wraparound time is just a short time away? I'd initialize your addition value so that it starts off with 60 seconds left before wraparound so you don't have to wait very long.
>
>On 19 Mar 2008, at 11:46, David Dunham wrote:
>
>>> Have you checked your code to make sure you're not converting an
>>> uptime (TickCount, Microseconds, etc.) calculation into
>>> milliseconds while using a signed 32-bit value?
>>
>> Well yes, I'm sure the bug is something like that. But I didn't
>> spot anything obvious the last time I had a 25-day machine (which
>> unfortunately got rebooted before I solved the bug). I'd like to be
>> able to debug and see where the value gets flipped negative.
>
>
>It's not actually negative -- I think AbsoluteToDuration maxes out
>after ~25 days. (It doesn't wrap, the way its Windows equivalent does
>after 50.) I'm using AbsoluteToNanoseconds now.
>
>So now I'd still like a way to force UpTime() (it's in
>DriverServices.h) to return a value of 50 days, to test my fix, and
>have QA verify it.
>
>BTW, none of these functions are documented in Xcode. And I updated
>Developer Documentation yesterday...
>
>David Dunham
>Voice/Fax: 206 783 7404 http://www.pensee.com/dunham/
>Imagination is more important than knowledge. -- Albert Einstein
>
>_______________________________________________
>MacOSX-dev mailing list
><email_removed>
>http://www.omnigroup.com/mailman/listinfo/macosx-dev
| Related mails | Author | Date |
|---|---|---|
| David Dunham | Mar 19, 04:32 | |
| Travis Risner | Mar 19, 08:24 | |
| Gary L. Wade | Mar 19, 19:16 | |
| David Dunham | Mar 19, 19:46 | |
| David Dunham | Mar 19, 22:26 | |
| Kaelin Colclasure | Mar 19, 23:09 | |
| Gary L. Wade | Mar 19, 23:12 |






Cocoa mail archive

