前言
目前正在做TS码流解析的任务,在测试的过程中,发现有的码流运行正常,有的码流运行会出错,那么很大概率上是由于自己写的程序不够完善导致的,此程序一定存在BUG。发现BUG后,习惯性的使用DEBUG进行调试,但是奇怪的是DEBUG运行却是正常的,这让我很纳闷,貌似不能通过DEBUG找出问题的地方,因为它运行正常。这种情况下,要么你就看代码,看出问题所在,要么就通过打印信息,找出问题出在了那里。
后果
输入-1,运行出错
使用GDB,进入后敲r,然后回车,同样也是输入-1
结果程序正常结束了,郁闷中…
前因
1.使用printf来打印信息,看看问题出在了哪里
这里的步骤比较繁琐,在代码前插入一个printf语句,并且输出自己能够看得懂的信息,比如说,我就会使用printf(“1\n”),printf(“2\n”)…类似的语句,然后运行程序,一步一步定位到哪里的信息没有输出,然后多加点log信息。这里我就不过多赘述了,定位好出问题的地方后,就可以使用GDB调试工具去查看。
2.使用GDB查看问题出现的原因
定位到以下位置
我们试图去释放申请的地址,但是这个地址却是异常的,这个地址我们不能访问到,也就是地址越界了。这时候我们可能会想,这个结构的地址不是已经申请到了吗,为啥会有一个异常的地址,回去查看这个地址的申请过程,看看问题在哪。我们测试到,这链表第一个节点释放的时候异常,查看头结点在哪里得到了一个异常值。
从上图可知,通过定位发现,在执行parse_eit_section这个函数后,头结点的内容就存在了异常值,继续查看解析函数做了什么,以下代码是eit表的解析函数
static EIT_INFO *parse_eit_section(SECTION *eit_actual_section, EIT_INFO *eit_info_link_head)
{
EIT_INFO *new_eit_info_node = NULL;
unsigned int eit_descriptors_end_position