tpp.c:87: __pthread_tpp_change_priority: Assertion `previous_prio == -1 || (previous_prio >= fifo_min_prio && previous_prio <= fifo_max_prio)' failed.
在嵌入式设备中出现 tpp.c:87 的断言失败并导致宕机，通常与线程优先级管理或实时调度策略（如 SCHED_FIFO）的配置错误有关。以下是可能的原因及分析：
1. 线程优先级越界
-
问题：
断言previous_prio == -1 || (previous_prio >= fifo_min_prio && previous_prio <= fifo_max_prio)失败，表明线程的优先级值previous_prio超出了 FIFO 调度策略允许的范围（fifo_min_prio到fifo_max_prio）。 -
可能原因：
-
代码中直接硬编码了优先级值，但未适配当前系统的调度策略范围（如
SCHED_FIFO的优先级范围可能与SCHED_OTHER不同）。 -
动态计算优先级时逻辑错误，导致值越界（如负数或超过最大值）。
-
-
验证方法：
通过sched_get_priority_min()和sched_get_priority_max()获取当前策略（如SCHED_FIFO）的合法优先级范围，检查代码中的优先级设置是否符合要求。
2. 调度策略不一致
-
问题：
线程的调度策略（如SCHED_FIFO、SCHED_RR、SCHED_OTHER）与优先级值的兼容性不匹配。例如：-
对非实时线程（如
SCHED_OTHER）错误地设置了实时优先级（如SCHED_FIFO的范围）。 -
线程的调度策略被意外修改，但优先级未同步更新。
-
-
可能原因：
-
多线程环境中，某段代码错误地修改了线程的调度策略（如从
SCHED_OTHER切换到SCHED_FIFO），但未正确重新设置优先级。 -
不同模块或库对同一线程的优先级或调度策略进行了冲突的修改。
-
-
验证方法：
使用pthread_getschedparam()检查线程的实际调度策略和优先级，确认与代码预期一致。
3. 内核或库的实时性兼容问题
-
问题：
嵌入式设备可能运行实时内核补丁（如 PREEMPT-RT）或特定版本的 C 库（如 glibc、musl），而代码中假设了不兼容的优先级行为。 -
可能原因：
-
内核或线程库的版本与代码中硬编码的优先级范围不匹配。
-
实时性配置（如
CONFIG_SCHED_DEBUG）未正确启用，导致调度策略检查失败。
-
-
验证方法：
检查内核配置和 C 库版本，确认其对SCHED_FIFO优先级范围的定义。例如，在 Linux 中，SCHED_FIFO的优先级范围通常是1（最低）到99（最高）。
4. 资源竞争或内存损坏
-
问题：
多线程竞争条件下，线程控制块（TCB）或优先级参数被意外篡改（如野指针、栈溢出等）。 -
可能原因：
-
内存越界操作破坏了线程的优先级字段。
-
多线程未正确同步，导致优先级参数被并发修改。
-
-
验证方法：
使用内存调试工具（如 AddressSanitizer）或硬件 Watchpoint 检测内存错误。
5. 硬件或驱动异常
-
问题：
硬件中断或驱动程序的错误行为导致内核调度器状态异常（如错误地修改了线程优先级）。 -
可能原因：
-
驱动程序在中断上下文中错误调用调度相关函数（如
sched_setscheduler()）。 -
硬件故障（如内存损坏）导致内核数据结构（如
task_struct）被破坏。
-
-
验证方法：
检查内核日志（dmesg）中是否有硬件错误或驱动异常记录。
嵌入式C++应用层开发遇见此问题，先排查是否是4. 资源竞争或内存损坏引起的。
检查堆栈看起来锁的__data成员不太正常，应该是被哪里踩到了。
浙公网安备 33010602011771号