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