FROM : Shawn Erickson
DATE : Fri Nov 19 18:39:40 2004
On Nov 19, 2004, at 9:19 AM, Gwynne wrote:
> I'm experiencing a confusing crash when using NSTimer's -fire method
> to force a timer to fire before its fire date. This happens when using
> a timer with a very large interval (close order of 5 years), which I
> do in order to avoid having to separate two extremely similar code
> paths from each other. I started out with a non-repeating timer, but
> it would somehow get invalidated immediately and therefore -fire
> didn't work. I switched to a repeating timer (which didn't matter,
> since the timer's selector invalidates and removes the timer anyway),
> and ended up with a crash inside objc_msgSend() called from [NSCFTimer
> fire]. I traced it down at the assembly level, and it seems that the
> instance of NSTimer is getting mangled so when it calls -timeInterval
> on itself, there's an invalid object there. I could only get the crash
> to occur without assembly-level debugging, but there's nothing in my
> secondary threads that goes anywhere NEAR that timer. I ran with
> libguardmalloc, and nothing's tromping any memory. When I switched to
> calling the timer's target/selector directly, the crash vanished and
> exhaustive testing with both single-processor and multi-processor has
> revealed no issues whatsoever. Is there any known issue with large
> timer intervals and [NSTimer fire]?
To totally ignoring your core question. :-)
Why are using using a timer that way? I don't follow how a timer of 5
years is useful...
Guessing at what you are attempting to do... consider using an
NSConditionLock or some such thing if you are trying to gate something
from running, etc.
-Shawn
DATE : Fri Nov 19 18:39:40 2004
On Nov 19, 2004, at 9:19 AM, Gwynne wrote:
> I'm experiencing a confusing crash when using NSTimer's -fire method
> to force a timer to fire before its fire date. This happens when using
> a timer with a very large interval (close order of 5 years), which I
> do in order to avoid having to separate two extremely similar code
> paths from each other. I started out with a non-repeating timer, but
> it would somehow get invalidated immediately and therefore -fire
> didn't work. I switched to a repeating timer (which didn't matter,
> since the timer's selector invalidates and removes the timer anyway),
> and ended up with a crash inside objc_msgSend() called from [NSCFTimer
> fire]. I traced it down at the assembly level, and it seems that the
> instance of NSTimer is getting mangled so when it calls -timeInterval
> on itself, there's an invalid object there. I could only get the crash
> to occur without assembly-level debugging, but there's nothing in my
> secondary threads that goes anywhere NEAR that timer. I ran with
> libguardmalloc, and nothing's tromping any memory. When I switched to
> calling the timer's target/selector directly, the crash vanished and
> exhaustive testing with both single-processor and multi-processor has
> revealed no issues whatsoever. Is there any known issue with large
> timer intervals and [NSTimer fire]?
To totally ignoring your core question. :-)
Why are using using a timer that way? I don't follow how a timer of 5
years is useful...
Guessing at what you are attempting to do... consider using an
NSConditionLock or some such thing if you are trying to gate something
from running, etc.
-Shawn
| Related mails | Author | Date |
|---|---|---|
| Gwynne | Nov 19, 18:19 | |
| Shawn Erickson | Nov 19, 18:39 | |
| Gwynne | Nov 19, 18:55 | |
| Shawn Erickson | Nov 19, 19:13 | |
| Gwynne | Nov 19, 19:39 | |
| John C. Randolph | Nov 20, 00:04 |






Cocoa mail archive

