初学linux平台上的C编程时间不长,这次正好有一个业务项目需要用到队列,研究和对比了一下市面上的相关产品,总体而言不是太复杂就是性能达不到要
求,所以最后还是决定自己写一个。这次用C完完全全由自己实现只是第二次,以前都是下个开源软件改一下,一般来说linux下的软件只要是C开发的,性能
都可以接受。但是为了……,还是自己决定写一下。在整个开发过程中,碰到的血泪教训太多了,这里先记录一下,第一:警示自己,以后不要再犯了;第二:给有
用的人分享一下,别人跳过的坑尽量避免自己再跳(好像我经常会跳??嘻嘻)!

   
1.内存泄漏;这是一个老问题了,这次开发的mq使用到了tc服务器接口,本着小心的态度,我几乎每个malloc的对象都会尽快释放,并且写到
malloc的时候就紧张,一定要在这个函数中查看一下,是否把malloc的对象都free了。但是tc还是把我害死了,因为用到了从tc中取值的
get函数,结果这个函数返回的值需要有开发人员自己free掉的,结果……,后来导致内存错乱才发现了错误。引起这个问题的原因是没有仔细看tc的文
档,咳,杯具。

   2.指针参数:这个问题也可以归结为内存泄漏。对于malloc的变量,free之后一定要置为NULL,这样我们就可以通过判断这个自增是否为NULL来编程。所以为了简单和不至于忘记最后的一个置NULL操作,我把这个过程写成了函数:

     void mem_free(void *ptr)

     {

          if(NULL != ptr)

         {

               free(ptr);

               ptr = NULL;

        }

     }

不仔细看没发现问题吧,把ptr的指针free掉,然后NULL操作,但是问题来了,当我为char *buff
执行mem_free(buff)函数后,发现第二次运行mem_free(buff)发现NULL !=
ptr竟然为true,郁闷了吧?这个问题搞了我半天时间,后来查看相关书籍才发现,当第一次mem_free的时候,free确实把内存给清除了,但是
坏就坏在ptr =
NULL;上,注意这个时候ptr只是一个指向buff指针的副本,也就是这个时候运行时态的指针可以理解成这样
ptr->buff->heap,free是因为没有改变ptr的指向,只是free掉了值,所以heap中的值被清除了,但是ptr =
NULL,其实是切断了ptr ?> buff的这根链,那么,buff
->heap这个链没有断开,所以其实buff还是指向这heap这个内存,虽然heap中已经不存在任何有用的数据了。但是我们的本意是要断开
buff ?> heap这个链,所以这个函数应该写成传递二级指针:

     void mem_free(void **ptr)

     {

          if(NULL != *ptr)

         {

               free(*ptr);

               *ptr = NULL;

        }

     }

这个问题可以总结为:改变指针指向的内容不需要传递指针地址,改变指针的指向,一定要传递指针的地址。

  
3.字符串(或者是字符数组,一下称字符串)结束符。对于字符串结束符很多人都没有搞明白,包括之前的我。每个字符串都会在最后加上一个’’结束符,
以示这个字符串结束了,如果人为手工没补齐,那么自动补齐。我的经验就是不管什么时候(声明char *buff = “i am
chinese.”这种时候除外),特别是执行了strcpy或者memcpy后,如果你copy的是字符串,那么一定要手工上去补齐一下,当然,如果你
memcpy的是二进制内存,那句不需要补齐了。

    4.内存补齐。这个问题困惑了我2天。比如有一个结构体:

     typedef  struct header_type

     {

         char protocol;

         int state;

         int64_t bodylen;

     } header_t;

    那么 sizeof(header_t)和sizeof(char) +
sizeof(int)+sizeof(int64_t)这两者的值一样吗?答案是不一样的。不要说自己看错了,我确定是不一样的,至少在我机器上是不一
样的。前者在我机器上的值为16,后者加起来为13.原因就是内存补齐。对于c而言,在申请的内存的时候会启用内存补齐,补齐规则有的定死了,有的可以调
整,具体需要看cpu和编译器。在我的机器上是2^n规则,1,2,4,8,16…….所以长度为13的补齐后就是16了。那么如果在同一机器上,这点可
以忽略,但是如果你要通过网络传递这个结构体,那你就不能忽略这个了。原因有二:如果你直接传递这个结构体的变量,那么需要考虑网络字节序和内存大小端,
这个太麻烦,放弃,第二:不考虑原因一的变通方法是全部使用char
*传递。那么如果你使用sizeof(header_t)申请内存,这个时候客户端接收到buff传递的值是16位的,最后的3位其实是无用的,但是客户
端并不知道,所以会引起内存混乱。解决办法就是申请char
*buff内存的时候,长度要是真正的内存大小,不要把内存对齐的空隙加入进去。但是你使用malloc给headet_t的对象申请内存时要使用
sizeof(header_t),因为不使用sizeof的话就会出现内存溢出。

 
5.recv的时候不管是不是non-block模式,都需要判断是否超时。我就碰到这个问题,设置了timeout后,没有判断超时,客户端接收到服务
器返回的结果非常的不稳定,一会儿好的(在超时时间内返回),一会儿又都是乱码。后来发现原来recv返回-1了,并且errno置为11了。解决了这个
问题后就不会出现接收不到数据的情况了。

   6.字节长度:因为问题5的出现,导致了我怀疑服务器端的数据传输问题,所以就增加了打印header_t的buff的想法,但是这个buff是一个二进制,直接打印二进制不行,只能转换到16进制,然后打印。所以加入了以下代码;

   char header_buff[14];

    bin2hex(buff,13,header_buff);

    log(header_buff);

  
结果程序每次运行到这里的时候就会引发系统abort的信号。开始找不到原来。后来经人指点,发现header_buff申请的空间错了。
header_t的二进制长度为13,但是每个字节16进制表示需要2个字节,所以13个二进制字节需要26个字节(有点绕口),再加上一个字符串的结束
符,所以应该申请的是27个字符。

http://www.cnblogs.com/Seapeak/archive/2010/09/03/1816800.html

分类:

admin

少将,关注Web全栈开发、项目管理,持续不断的学习、努力成为一个更棒的开发,做最好的自己,让世界因你不同。

发表评论

电子邮件地址不会被公开。 必填项已用*标注