作为一只码农,不仅有敲出惊人代码本领,更有一种与生俱来的天赋,就是在惊人的代码中创造神奇的臭虫。既然是臭虫,就没人喜欢了,但是既然是我们创造的,那我们是不是应该有义务将其逮住,然后就呵呵呵😄👌。。你懂的。。
臭虫的种类繁多,能不能像物种的分类分为界,门,纲,目,科,属,种呢,我是没这能耐,哪位大神可以分一下。呵呵。但是有一种臭虫是最令人讨厌的,在编码中当属内存问题。下面言归正传。。。
内存引起的问题可谓是一虫🐛出洞千虫🐛鸣啊,内存泄漏,内存越界,内存安全等等,引起的问题千奇百怪,而且难以查询。当然像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);
}