If we call an invalidate whereas we've not called a schedule method, a crash emerges

[kos9kus]

I init a new timer and before timer will schedule in some time within an execution, I call invalidate method prior to schedule, and see an error into following scope.

if (!OSAtomicTestAndSetBarrier(7, &_timerFlags.timerIsInvalidated))
    {
        dispatch_source_t timer = self.timer;
        dispatch_async(self.privateSerialQueue, ^{
            dispatch_source_cancel(timer);
            ms_release_gcd_object(timer);  // The error occurred !!! 
        });
    }

I think we need to check a reference counter of *_self.timer *_or remove ms_release_gcd_object(object) dispatch_release(object) when we work in ARC.

this is a note from Spec:
IMPORTANT
If your app is built with a deployment target of OS X v10.8 and later or iOS v6.0 and later, dispatch queues are typically managed by ARC, so you do not need to retain or release the dispatch queues.

[JaviSoto]

That's what ms_release_gcd_object does: it doesn't call release if it doesn't have to, so that part of the code is correct.

Could you share a piece of code that reproduces the crash (a failing test case would be idea), and a full stack trace of the crash?

Thanks!

[kos9kus]

This is a simple test case

MSWeakTimer* heartBeatTimer = [ [MSWeakTimer alloc] initWithTimeInterval:pingPongTimeOut target:self selector:@selector(sendPing) userInfo:nil repeats:NO dispatchQueue:dispatch_get_main_queue() ];
[heartBeatTimer invalidate];

[system waitForTimeInterval:3];

[kos9kus]

Did you get that ?
I repeat that, my case is I initialize a timer then inside my class there are exist 2 callbacks, success and error, If i get error callback, there will be invalidating timer, if i get success callback there will be scheduling timer. An error occurs when we try to invalidate a timer that wasn't scheduled.
Please give me some feedback or tips! Perhaps I should do some check whether timer was scheduled or not.