Сбой AKMIDISampler при остановке секвенсора - PullRequest
0 голосов
/ 26 сентября 2018

В приложении происходит прерывистый сбой при остановке секвенсора.Мое приложение использует пользовательский MusicSequencer на основе AudioToolbox, с AKMIDISampler, подключенным в качестве его midiEndpoint.Я отследил падение до того, что AKMIDISampler func handle(event: AKMIDIEvent) получил пустое событие (т.е. event.internalData.count == 0).Поскольку сэмплер является «жестко запрограммированным», так сказать, в качестве конечной точки, я действительно не уверен, как я могу отладить это, так как я не могу видеть, что последовательность пытается отправить (или почему она, очевидно, отправляетпустое событие).

Я смог запустить его, взломав собственную сборку AK, в которой я проверял работоспособность event.internalData.count.Однако, отдельная проблема в моем проекте (https://stackoverflow.com/a/49950129/4321521) вынудила меня использовать AudioKit из CocoaPods, который удаляет мое исправление (или, скорее, взлом) ...

Я зарегистрировал все свои функциикоторые добавляют события в последовательность, и ни одно из них, похоже, не отправляет пустые данные.

Одно из возможных объяснений, о которых я задаюсь вопросом: недавно я заметил, что включение AddressSanitizer указывает на переполнение стекового буфера при созданиипользовательские события. Я признаю, что полностью озадачен тем, как мы собираемся создавать события переменной длины в Swift. Кажется, я не могу «легально» создавать какие-либо события с event.length > 4, несмотря на то, чтоструктура имеет свойство * 1013. * Например, этот бит кода:

let eventDataBytes = ByteBackpacker.pack(event) // convert to [UInt8]
var midiData = MusicEventUserData()
midiData.length = UInt32(MemoryLayout<Event>.size)
withUnsafeMutablePointer(to: &midiData.data, { pointer in
    for i in 0 ..< eventDataBytes.count {
        print("Can write byte \(i)...")
        pointer[i] = eventDataBytes[i]
    }
})

выдает мне ошибку переполнения стекового буфера при i == 4. Так как мое событие имеет свойство Float64 durationэто, очевидно, не работает ...

Так что я полагаю, что неизбежно, что в моей последовательности есть данные мусора, от добавления этих переполненных пользовательских событий. Я просто не вижу, как это приведет кd к event.internalData.count == 0, или почему моя проверка работоспособности на event.internalData "исправила бы" это (т.е. запустилась без проблем).

Обратный след:

* thread #10, stop reason = EXC_BREAKPOINT (code=1, subcode=0x100bc677c)
    frame #0: 0x0000000100bc677c Spliqs`partial apply for closure #1 in     AKMIDISampler.enableMIDI(_:name:) [inlined] generic specialization <Swift.UInt8> of Swift.Array._getElement(Swift.Int, wasNativeTypeChecked: Swift.Bool, matchingSubscriptCheck: Swift._DependenceToken) -> A at AKMIDISampler.swift:0 [opt]
frame #1: 0x0000000100bc677c Spliqs`partial apply for closure #1 in AKMIDISampler.enableMIDI(_:name:) [inlined] generic specialization <Swift.UInt8> of Swift.Array.subscript.getter : (Swift.Int) -> A at AKMIDISampler.swift:0 [opt]
frame #2: 0x0000000100bc677c Spliqs`partial apply for closure #1 in AKMIDISampler.enableMIDI(_:name:) [inlined] AudioKit.AKMIDISampler.(event=AudioKit.AKMIDIEvent @ 0x00007f94f2693800)(event: AudioKit.AKMIDIEvent) throws -> () at AKMIDISampler.swift:60 [opt]
* frame #3: 0x0000000100bc677c Spliqs`partial apply for closure #1 in AKMIDISampler.enableMIDI(_:name:) at AKMIDISampler.swift:48 [opt]
frame #4: 0x0000000100bc677c Spliqs`partial apply for closure #1 in AKMIDISampler.enableMIDI(_:name:) at AKMIDISampler.swift:0 [opt]
frame #5: 0x0000000100bc4bb8 Spliqs`thunk for @escaping @callee_guaranteed (@unowned UnsafePointer<MIDIPacketList>, @unowned UnsafeMutableRawPointer?) -> () at AKMIDISampler.swift:0 [opt]
frame #6: 0x0000000194f6d7ac CoreMIDI`LocalMIDIReceiverList::HandleMIDIIn(unsigned int, unsigned int, void*, MIDIPacketList const*) + 156
frame #7: 0x0000000194f6d608 CoreMIDI`MIDIProcess::RunMIDIInThread() + 124
frame #8: 0x0000000194f81640 CoreMIDI`XThread::RunHelper(void*) + 20
frame #9: 0x0000000194f85698 CoreMIDI`CAPThread::Entry(CAPThread*) + 88
frame #10: 0x0000000184c25220 libsystem_pthread.dylib`_pthread_body + 272
frame #11: 0x0000000184c25110 libsystem_pthread.dylib`_pthread_start + 292
frame #12: 0x0000000184c23b10 libsystem_pthread.dylib`thread_start +
...