我有一个在ARM uC上运行的VxWorks应用程序 .
首先让我总结一下这个应用程序;
应用程序包含第三方堆栈和网关应用程序 . 我们已经实现了一个操作系统抽象层来支持OS依赖 .
底层堆栈有自己的内存管理和控制工具，它将内存块保存在双向链表中 .
例如 ;我们不直接执行malloc / new，free / delege . 而是我们调用OSA层的例程，它从OS获取内存并将其放入列表然后将此内存返回给应用程序 . （例程：XXAlloc，XXFree，XXReAlloc）
当释放内存时，我们再次使用XXFree .
事实上，这个块是一个结构
-magic数字指示内存块的开始和结束 - 用户在实际中请求分配-size由于对齐问题的前一个和下一个指针 - 指向返回给应用程序的内存块 . 链接寄存器，显示应用程序xxAlloc的调用位置 .
使用此块结构堆栈可以检查块是否已损坏 .
我们还有一个从Linux移植的pthread库，我们用它来创建/终止线程（目前有22个线程）-synchronization对象（事件，互斥...）
taskSpawn调用了一个主要任务，后来这个任务创建了其他线程 .
这是对应用程序及其VxWorks接口的描述 .
问题是 ：
其中一项任务突然被VxWorks摧毁，没有提供有关错误的信息 . 我也有一个jtag调试器，它命中了VxWorks taskDestoy（）例程但是调用堆栈不提供PC或r14的任何信息 .
我怀疑代码中的特定例程，其中完成了巨大的xxAlloc但是问题非常偶然，并且没有任何线索我可以将它映射到源代码 .
我认为操作系统检测到异常，并以静默方式执行其处理 .
任何帮助都会很棒
问候
3 回答
它解决了 .
我做了一个孤立的测试 . 使用malloc和memset以0x55分配20MB并停止我的应用程序的线程 .
我写了另一个线程，检查我的20MB是否写入了除0x55以外的任何数据 .
还有什么!!一些其他线程属于CPU中的其他组件（其他人开发它们）写下我分配的空间 .
谢谢你的帮助
如果您的任务退出，则调用taskDestroy（） . 如果您怀疑巨大的xxAlloc，请在内存耗尽时验证分配代码是否未调用exit（） . 我以前在第三方OSAL中被这种行为所困扰 .
听起来像是在集成后进行调试;这可能是一个很糟糕的工作 . 我建议把问题分成小块 .
Process
1）通过检测代码和/或使用VxWorks工具（取决于哪个版本），您可以获得更多洞察力 . 这使您可以更好地了解所发生的情况 . 请务必将所有内容记录到文件中，以便从任务结束点开始及时移回 . 仪表是值得的投资，因为它在更多场合会很方便 . VxWorks中有趣的钩子：Taskhooklib
2）内存分配/释放是非常基本的功能 . 这将是我在一个定义明确的多线程环境中进行全面（单元）测试的第一个候选者 . 如果你这样做并且没有发现任何错误，我首先会开始看看为什么tas已经结束了 .
other possible causes
当工作完成时，任务也将结束 . 所以它可能是由不那么无限循环引起的返回 . 特别是如果它总是相同的任务，这将是我的猜测 .
并且某些版本的VxWorks必须考虑MMU支持 .