|
作为一只码农，不仅有敲出惊人代码本领，更有一种与生俱来的天赋，就是在惊人的代码中创造神奇的臭虫。既然是臭虫，就没人喜欢了，但是既然是我们创造的，那我们是不是应该有义务将其逮住，然后就呵呵呵😄👌。。你懂的。。 臭虫的种类繁多，能不能像物种的分类分为界，门，纲，目，科，属，种呢，我是没这能耐，哪位大神可以分一下。呵呵。但是有一种臭虫是最令人讨厌的，在编码中当属内存问题。下面言归正传。。。 内存引起的问题可谓是一虫🐛出洞千虫🐛鸣啊，内存泄漏，内存越界，内存安全等等，引起的问题千奇百怪，而且难以查询。当然像valgrind内存检测工具很好，但是作为嵌入式开发，可就没有如此的幸运了，嵌入式通常的调试就是串口打印，或者各种LED灯来指示，还有就是调试大法——在线调试。如果各种调试方式都木有了，那就等死吧，因为上帝也救不了你了。。。 最近再开发一款产品，由于经验不足，在临近结尾时跳出了一只臭虫，真是阴魂不散，被搞得精疲力尽啊。好在之前写的代码还算比较规范，层次分明，明显的问题通过屏蔽不同的功能段来快速定位问题点，所以再写代码时就应该想到层次段落分明，这样在后面遇到问题时也好更快的查找，不至于牵一发而动全身。总之坚持原则“高内聚，低耦合”，刚学习编程时这个原则会灌输给你，但是不经历大的工程项目是很难体会其意。然而总会存在一些难以查找的问题，不过今天从老大那里学习了一招很非常优雅的调试方式，即使这种方式没有找到问题的最终原因，但是也排除了某些可能引起问题的原因。我使用此方法是在STM32的在线Debug中使用，在其他调试方式下未做测试，在此只是提供一种方法而已，分享一下。 再嵌入式开发中动态内存是比较常用，特别是对那些数据长度只有在运行过程中才能确定的数据，这个时候malloc()函数和free()函数就大大的派上了用场，千万要记住，这两个函数在非特殊情况下一定要成对出现，不然很可能会出现错误。此方法的目的是记录那些调用malloc的函数在使用malloc时分配了多少内存，可以一目了然的清楚哪个函数分配了多少内存。知道了哪函数调用了malloc()函数且该函数申请了多少内存。这样就可以确定是哪个函数在干坏事了。具体实现如下： #define ts_malloc(size) __ts_malloc(size, __FUNCTION__) #define ts_free(p) __ts_free(p) #pragma pack(push,1) // <! 字节对齐 struct mem_leak_t{ struct mem_leak_t *next; char func_name[16]; uint32_t size; }; #pragma pack(pop) struct mem_leak_t *mem_leak_queue = NULL; void *ts_malloc(size_t size, char *func_name){ // <! 实现此方法需要重新封装malloc函数 uint32_t len = size sizeof(struct mem_leak_t); struct mem_leak_t *p = (struct mem_leak_t *)malloc(len); if( p != NULL){ strncpy(p->func_name, func_name, sizeof(p->func_name) ); p->size = size; mount(&mem_leak_queue, p); return (p 1); }else{return NULL;} } void ts_free(void *__p){ if( __p == NULL){return;} struct mem_leak_t *p = (struct mem_leak_t *)__p; p -= 1; unmount(&mem_leak_queue, p); free(p); }
本文转自：简书 微信号：IdeaofSE |
|
|
