目录 (Table of Contents) [TOCM] 段错误修改方法总述 关于BackTrace 相关函数说明 char backtrace_symbols (void const buffer, int size) include 关于GDB MARKDOWN太难用，这个博客没有草稿太难用 段错误修改方法总述 正常调试段错误的方法是发生段错误时触发调用backtrace来显示调用栈，来确定问题代码位置或函数。 海思的HI3518C（或系列平台）支持glib与uClib两种文件系统，uClib的初衷是通过对一些接口的优化来减小glib的大小，这样导致有些函数并没有实现，比如back_trace和backtrace_symbols函数。运行时库中没有这两个调试库，麻烦来了，程序捕捉到段错误信号后也最多只是知道程序发生段错误了，但没办法知道哪儿出现段错误了。 解决上述问题的方法是用gdb做调试，调试时用gdbserver在arm板子里把目标程序跑起来，在编译环境下连接该程序，当程序发生异常时，gdb会中断到发生异常的地方，从而定位问题。 关于BackTrace backtrace相关函数用于程序异常时时定位错误行或错误发生时的函数调用栈，linux程序都是运行于shell之上，所以支持backtrace相关函数的程序异常退出时，可以在控制台看到调用栈的信息。Windows平台的MFC程序中没有这种说法，一般Windows程序出现这种错误，可以用VS或Windbg附到相关进程中查看中断位置，Windows相关的方法这里不做展示。 相关函数说明 int backtrace(void **buffer,int size) 参数： size: 指明buffer最大接收的函数栈大小 buffer：接收栈指向指针的指针，在backtrace中分配空间，用完需要释放 该函数用于获取当前线程的调用堆栈,获取的信息将会被存放在buffer中,它是一个指针列表。参数 size 用来指定buffer中可以保存多少个void 元素。函数返回值是实际获取的指针个数,最大不超过size大小在buffer中的指针实际是从堆栈中获取的返回地址,每一个堆栈框架有一个返回地址。注意:某些编译器的优化选项对获取正确的调用堆栈有干扰,另外内联函数没有堆栈框架;删除框架指针也会导致无法正确解析堆栈内容 char * backtrace_symbols (void const *buffer, int size) backtrace_symbols将从backtrace函数获取的信息转化为一个字符串数组. 参数buffer应该是从backtrace函数获取的指针数组,size是该数组中的元素个数(backtrace的返回值) 函数返回值是一个指向字符串数组的指针,它的大小同buffer相同.每个字符串包含了一个相对于buffer中对应元素的可打印信息.它包括函数名，函数的偏移地址,和实际的返回地址 编译时需要加上-rdynamic，把函数符号信息加到程序或so文件中。 示例代码 include #include #include #include #include #include #include #include void A(int a) { B(2); } void B(int b) { C(3); } void C(int c) { char *p = (char *)c; *p = 'A'; } void DebugSecment(int sn , siginfo_t *si , void *ptr) { if(NULL != ptr) { printf("\n\nunhandled page fault (%d) at: 0x%08x\n", si->si_signo,si->si_addr); struct ucontext_ce123 *ucontext = (struct ucontext_ce123 *)ptr; int pc = ucontext->uc_mcontext.arm_pc; void *pc_array[1]; pc_array[0] = pc; char **pc_name = backtrace_symbols(pc_array, 1); printf("%d: %s\n", 0, *pc_name); void *array[30]; int size, i; char **strings; size = backtrace_(array, 30); strings = backtrace_symbols(array, size); for(i=0;i

2017-11-30

0 0 4926

如果仅仅因为没有人工材料替代软骨的话——需要替代品的承受力和真的一样多，从而导致膝关节损伤或其它关节发生损伤很难完全恢复。不久的将来，这可能不再是一个问题：科学家已经开发出一种类似于天然软骨的芳基（Kevlar-based）水凝胶。在休息的时候它将一团芳纶（Kevlar ）纳米纤维与聚乙烯醇混合在一起，以吸收水分（就像真正的软骨在空闲时所做的那样），变得非常有韧性，但在压力下释放相应的水分——比如说，在健身房进行锻炼时。 你甚至不需要太多的它来复制人体的坚固性和整体功能。含92%水分的材料和真的软骨一样坚韧，而70%的混合物与橡胶相似。以前的模拟软骨不适合植入的原因是不能容纳足够的水分来将营养物质输送到细胞。 这种材料变得有用还有很长的路要走。研究人员希望对该物质进行专利认证，并找到公司产品化。提醒你一下，这个事的重要性已经很清楚了。如果它在病人身上像在实验室实验中一样有效，它可能会导致软骨植入物和他们所替代的真正的软骨一样好。到时候，即使是严重的膝伤也可能不会使你的跑步生涯结束。

背景： 　　　公司要在 OMAP3530平台上做产品，现在处于技术调查阶段。需求点之一是修改现有的3寸LCD屏为7寸屏。 问题： 　　　我们使用 的是瑞泰提供的开发板，开发文档中有关于屏使用的介绍。按照文档中提供的内核编译选项，找到对应的LCD屏驱动文件后，进行参数设定，没有效果，（最明显 的一个参数是时钟频率，修改后，应当花屏，事实上是还正常显示）。 解决过程： 1、把参数都改乱测试，没有效果，怀疑修改错文 件。 2、取消模块向DSS系统的注册动作，屏幕变黑，说明所修改文件还是起作用的。 3、找瑞泰技术支持询问，没有得到有用的 答案，放弃使用询问技术支持的权利。 4、OMAP相关技术群里寻找有这方面经验的人，提供参考意见，有经验的人都说改那文件的参数就起作用 的，见鬼了。 5、联机调内核，跟踪代码试试。结果联机调很麻烦，配了半天环境没配成，放弃此方案。 6、使用最古老的打LOG 方式，在相关地方都打上调试信息的输出，配合SourceInsigh查看代码的调用流程，最终找到了问题所在。 问题原因： 　 　内核启动时，给omapfb模块传入了显示设置的参数470×272MR-16@60，显示子系统(DSS)解析此参数，并对所显示结构体中的 panel->timings成品进行赋值，而此成员的值便是瑞泰文档中所提到的驱动文件中设定的，因此无论在该文件如何修改参数，系统都能正常显 示。 修改方案： 　　修改解析参数并给display->panel->timings赋值的地方，取消赋值操 作。 方案验证： 　　修注释掉该调用后，系统直接崩溃。 新问题调查： 　　定位出问题的代码行后， 发现我们的参数在设置时，超出了合法范围，改小该值，并使用示波器测试时钟频率和相应信号与在驱动文件中设定的值相同。问题最终解决，总共使用时间七个工 作日。