[SR-15133] Crash when deallocating a never-resumed DispatchSourceTimer

[mickeyl]

Previous ID	SR-15133
Radar	rdar://problem/82535083
Original Reporter	@mickeyl
Type	Bug

Environment

macOS 12 beta, Xcode 13 (13A233).

Additional Detail from JIRA

Votes	0
Component/s	libdispatch
Labels	Bug, DispatchSourceTimer
Assignee	None
Priority	Medium

md5: 61e077b082169a945b058843ee5c3245

Issue Description:

Please consider the following example program which I have uploaded to

https://github.com/mickeyl/swift-bugs/tree/main/SR15133

Running it from within Xcode crashes with the following backtrace:

(lldb) bt

• thread Linux port hdd cp1 #3, queue = 'com.apple.root.default-qos.cooperative', stop reason = EXC_BREAKPOINT (code=1, subcode=0x100624d9c)
  frame #0: 0x0000000100624d9c libdispatch.dylib`_dispatch_queue_xref_dispose.cold.2 + 36
  frame Typos #1: 0x00000001005ea2ec libdispatch.dylib`_dispatch_queue_xref_dispose + 64
  frame Update autotools buildsystem for libdispatch-500.1.5 and testsuite #2: 0x00000001005e17f8 libdispatch.dylib`-[OS_dispatch_source _xref_dispose] + 28
  frame Linux port hdd cp1 #3: 0x00000001000060f8 SR15133`StreamCommand.deinit(self=0x0000000105105820) at StreamCommandQueue.swift:0
  frame Fix Typos #4: 0x0000000100006120 SR15133`StreamCommand.__deallocating_deinit(self=0x0000000105105820) at StreamCommandQueue.swift:0
  frame libdispatch now builds on Linux and ping/pong test runs successfully. #5: 0x00000001a2f6b774 libswiftCore.dylib`_swift_release_dealloc + 56

• frame Add & use DISPATCH_NOESCAPE attribute macro #6: 0x00000001000081bc SR15133`StreamCommandQueue.handleErrorCondition(stream=0x0000000100712b90, event=.errorOccurred, self=0x0000000100712e90) at StreamCommandQueue.swift:182:9
  frame Add the download command of the library that libdispatch depends #7: 0x0000000100009040 SR15133`closure Linux port hdd cp1 #3 in StreamCommandQueue.stream(self=0x0000000100712e90, aStream=0x0000000100712b90, eventCode=.errorOccurred) at StreamCommandQueue.swift:202:44
  frame Linux port hdd timers2 #8: 0x000000010000ac48 SR15133`partial apply for closure Linux port hdd cp1 #3 in StreamCommandQueue.stream(_:handle🙂 at <compiler-generated>:0
  frame enable subdir-objects for automake #9: 0x0000000100005d5c SR15133`thunk for @escaping @callee_guaranteed @sendable @async () -> () at <compiler-generated>:0
  frame Clang and linux portability fixes #10: 0x000000010000ad9c SR15133`thunk for @escaping @callee_guaranteed @sendable @async () -> ()partial apply at <compiler-generated>:0
  frame Add some details on current build steps for Linux. #11: 0x000000010000bfac SR15133`thunk for @escaping @callee_guaranteed @sendable @async () -> (@out A) at <compiler-generated>:0
  frame Add AC_SEARCH_LIBS stanzas for kqueue and pthread_workqueue #12: 0x000000010000cc5c SR15133`partial apply for thunk for @escaping @callee_guaranteed @sendable @async () -> (@out A) at <compiler-generated>:0
  (lldb)

I suspect there is a memory management problem when the stored continuation in the `StreamCommand` gets deallocated due to `self.activeCommand = nil` while the continuation may continue to run in another task.

[mickeyl]

It also crashes when running on the command line with `swift run`, btw.

[typesanitizer]

@swift-ci create

[mickeyl]

Same in Xcode 13 release version.

[mickeyl]

On Linux w/ Swift version 5.6-dev (LLVM ca88d53176e346a, Swift a382f589a5ec230), this seems to work.

It still fails on macOS 12 with Swift development toolchain 2021-09-18.

[mickeyl]

After digging deeper, it seems that the actual crash happens when deallocating the `DispatchTimerSource`. Obviously `libdispatch` is to blame here and it has nothing to do with the continuation. I will adjust the metadata accordingly.

[Kyle-Ye]

I have encountered the bug in my codebase too.

And I can reproduce it stably with your great example code.

After some digging I can create a more simple reproductive code snippet.

// main.swift
import Foundation
import Dispatch

class Command {
    let timer: DispatchSourceTimer
    
    init() {
        self.timer = DispatchSource.makeTimerSource()
    }
}

func test() {
    var command: Command? = Command()
    command = nil
}

test()
dispatchMain()

Checking the libdispatch code

swift-corelibs-libdispatch/src/queue.c

Lines 2879 to 2893 in 542b7f3

	void
	_dispatch_queue_xref_dispose(dispatch_queue_t dq)
	{
	uint64_t dq_state = os_atomic_load2o(dq, dq_state, relaxed);
	if (unlikely(_dq_state_is_suspended(dq_state))) {
	long state = (long)dq_state;
	if (sizeof(long) < sizeof(uint64_t)) state = (long)(dq_state >> 32);
	if (unlikely(_dq_state_is_inactive(dq_state))) {
	// Arguments for and against this assert are within 6705399
	DISPATCH_CLIENT_CRASH(state, "Release of an inactive object");
	}
	DISPATCH_CLIENT_CRASH(dq_state, "Release of a suspended object");
	}
	os_atomic_or2o(dq, dq_atomic_flags, DQF_RELEASED, relaxed);
	}

The crash reason is that the object is in a inactive state.

It has nothing to do with timer.cancel, timer.setEventHandler nor timer.schedule.

It is because we create the object but dealloc it before calling timer.resume.

The solution is always calling activate/resume after you create the DispatchSourceTimer object.

class X {
    private var timer: DispatchSourceTimer!

    func y() {
        if timer == nil {
            timer = DispatchSource.makeTimerSource(queue: DispatchQueue.global(qos: .userInteractive))
            timer.resume() // Or timer.activate()
        }
    }
}

[Kyle-Ye]

@mickeyl Did what I said above convince you? I think it's better to mark this issue as closed to better reflect the status here. cc @MadCoder as I do not have the corresponding permission on this repo.