Недавно я протестировал свой kext на 10.14, и какое-то время он работал нормально.Но после некоторого случайного времени (может занять несколько минут), он вызывает следующую панику:
thread_invoke: preemption_level -1, possible cause: unlocking an
unlocked mutex or spinlock"
Это я запускал свой код несколько раз и заметил, что паника может быть вызвана любым моим пользователем.Космический демон при вызове psynch_cvwait sys или непосредственно из расширения ядра при запуске переключения контекста после вызова msleep функции.
Вот трассировка от ядра:
frame #4: 0xffffff800afe24a3 kernel`panic(str=<unavailable>) at debug.c:620 [opt]
frame #5: 0xffffff800affef06 kernel`thread_invoke(self=0xffffff801b7a4030, thread=0xffffff801afe4540, reason=0) at sched_prim.c:2261 [opt]
frame #6: 0xffffff800affdaff kernel`thread_block_reason(continuation=<unavailable>, parameter=<unavailable>, reason=<unavailable>) at sched_prim.c:3088 [opt]
frame #7: 0xffffff800b4fcfe1 kernel`_sleep [inlined] thread_block(continuation=<unavailable>) at sched_prim.c:3104 [opt]
frame #8: 0xffffff800b4fcfd6 kernel`_sleep(chan=<unavailable>, pri=0, wmsg=<unavailable>, abstime=1299691844730, continuation=0x0000000000000000, mtx=0x0000000000000000) at kern_synch.c:251 [opt]
frame #9: 0xffffff800b4fd352 kernel`msleep(chan=0x01000004001ddd89, mtx=0x0000000000000000, pri=0, wmsg="", ts=<unavailable>) at kern_synch.c:346 [opt]
И следующая трассировка стека, запущенная из вызова sys демона пользовательского пространства:
frame #4: 0xffffff800afe24a3 kernel`panic(str=<unavailable>) at debug.c:620 [opt]
frame #5: 0xffffff800affef06 kernel`thread_invoke(self=0xffffff80176f5a50, thread=0xffffff8019a5de60, reason=0) at sched_prim.c:2261 [opt]
frame #6: 0xffffff800affdaff kernel`thread_block_reason(continuation=<unavailable>, parameter=<unavailable>, reason=<unavailable>) at sched_prim.c:3088 [opt]
frame #7: 0xffffff7f8cbf5080
frame #8: 0xffffff7f8cbf6dcf
frame #9: 0xffffff800b499c3c kernel`psynch_cvwait(p=<unavailable>, uap=<unavailable>, retval=<unavailable>) at pthread_shims.c:397 [opt]
, где отсутствуеткадры принадлежат расширению com.apple.kec.pthread(1.0)[C69B97C1-505D-3629-9D64-7B7BC6D780A8]@0xffffff7f8cbf3000->0xffffff7f8cbfafff
Сначала я подумал, что это может быть вызвано случайным повреждением памяти, но похоже, что после всех моих репродукций никакая другая сущность, кроме двух, которые я только что упомянул, не вызвала панику.
Если я посмотрю на сообщение о панике, оно связано со значением, которое можно найти в регистре% gs на процессор, где сохраняется уровень приоритетности.Тем не менее, в lldb у меня нет доступа к этому регистру, и я сомневаюсь, что он сопоставлен с моей памятью драйвера.
Итак, я оставил комментарии к частям моего драйвера и проверил, сохраняется ли проблема ..Возможно, у кого-то из вас есть больше идей о том, как решить эту проблему?
спасибо