debug bug experience

调试的错误就是编程给你最好的东西，因为在每个错误上面都标志着前进的一步。

 

2014/7/25  rar_0

调试程序时，最好的还是先执行一下，这样比直接检查代码要高效。

对自己的代码，最好要有足够的信心，没有信心的地方要验证一下，以防在后面写着还惦记着前面的。

1，传的结构体指针，但是访问的时候没有按照结构体的方式访问
sha1_block(SHA_CTX * c, unsigned int * W){
 c.data = 0; //wrong
 c->data = 0; //right
}

2.被一个问题烦扰，对最后的解决方案又不自信，导致有点儿不专心，弄其他代码的时候就出错了

3.改一个变量类型，相关的都要改，避免漏改。
需要把问题中的变量都向量化的，但是一个函数的参数类型忘记改成向量化形式，向量化的变量也可以按指针访问，所以不会报错
对这个代码做了好几次，有点儿自信了，所以就没好好检查，结果就错了
sha1_block(SHA_CTX * c, unsigned int * W)//wrong
sha1_block(SHA_CTX * c, u32_v * W)//right

 

2015/1/23 rar_1
1.即使调试到是某一句代码的问题时，也不一定就是那一句，也可能是之前或之后的，尝试删除前前后后试试（记：盯着看clGetPlatformIDs(...)的半天）。

2.放弃之前再尝试一次。

3遇到自己觉得可能会出问题的地方，应该确认一下是否会有问题，想当然觉得没关系，或者懒得管，这个可能存在的问题说不定就成为程序中的bug。

//当count非常小的时候(如count = 2)，所有线程都不执行了
if(pwd_count + globalID > count)
    return;

 

2015/1/24 sharpness_0

今天打开CSDN就看到这句话，满满的正能量：调试的错误就是编程给你最好的东西，因为在每个错误上面都标志着前进的一步。

2015/1/30

今天听了邢波的讲座，讲的专业知识，啥也没听懂，但是有两个感悟：

搞学术这个事情，还是国外的环境好，国内的都略显功利。

感觉做学术就是得较真，并且要执着。

最近一段时间调bug，明显感到自己在做一下不需要动脑子的事情，觉得，还是要自己去学一些东西的，要学会主动思考。

还有，有bug，就好好看看自己的代码，不要觉得是系统什么的有问题了。

还有，对自己的流程要有信心，觉得可能是哪里出错了，应该就是那里。

2015/2/2

在kernel代码里，不能将一个global变量的指针

__global char * a;

赋值给一个非global变量，如：

char * b;

2015/8/31

记录两个之前调的bug，都不是我调出来的，但是都有些感悟。

1.

问题： , 执行kernel时，报错，out of sources

原因：在kernel的参数列表中，本来应该定义为global的参数变量定义误写为constant，导致constant使用过量，资源不足。 

体会：调bug时应该思路清晰，out of sources，资源使用过量，应该冷静思考都有哪些资源（register，local，global，constant，private），逐一判断排除，最后就能清晰的处理核解决这个问题。

2.

问题：OepnCL性能调优，8卡却一直是4倍加速比，而且总是会使其中两个卡的问题，和RAR的情况一样，对于RAR是将THREADS_PER_WKGROUP改为64就ok了，但是这个改过后brute没有问题了，dic却还是有问题。

原因：data数组的大小是性能瓶颈。在dic的kernel代码里，data数组（local）被开辟为固定大小的，按照每个WORKGROUP里有256个线程开的，将THREADS_PER_WKGROUP改为64后这个data数组还是这么大，所以性能就没有改善。

体会：当时其实是看到这个问题了的，但是就觉得是人家的kernel代码，自己没有必要再去看，再改的，也觉得怕给改坏了，有失正确性。其实就是懒，但是要是好好看看人家的代码，试着给改改，问题就早解决了。

体会就是遇到觉得有问题的地方，一定要追根究底，把他给解决好。

2015/9/21

cuda

在kernel代码中对device内存变量访问越界，报错是显示在malloc时出错。

2015/10/27

纠结了我很久的一个问题，哎，终于搞明白了。

问题：warp affine LINEAR TRAN模式下，非向量化不出错，向量化会出错。这里的向量化就是一个线程处理多个数据。这个向量化我用for循环来实现的。

原因：因为，在TRAN模式下，有个return语句，当遇到越界访问是会return，向量化代码中我仍旧使用return语句，就造成了如果一个线程处理0,1,2,3,4,5,5,6，7号数据，如果，2号数据的是越界访问，那么就直接访问，后面的内容也将不能计算到。因而出现错误结果。

这提醒我：1. kernel程序中注意return等控制语句的使用；2. 并行化向量化思想要严谨。要考虑每个数据的执行，即做向量化，就要把逻辑理清，脑海中将并行过程，向量化过程依据其代码跑一遍。

2015/11/3

昨天晚上算上今天中午到现在，也是花了三个小时还弄的这个bug。

这个代码主要是自己对自己的实现不是很自信，以为实现思路本身就有问题。

bug详情：

代码写错了：

w = （w == 0）? (1 / w) : 0;

应该要写成

w = （w == 0）? 0 ：(1 / w);

分析这次bug，是觉得自己现在写代码不够专注了，思路也不是很清晰，可能是杂事儿太多了。之前有短时间几次都是代码写完一次过。哎，要找回状态啊。运动运动！！！

挑bug的时候，首先不要纳闷说：为啥错了，怎么会错了，难道是思路的问题？我现在的状态，一般要先检查自己的代码实现上的问题，代码一次过的几率还是相当小的。

以后写新的代码，需要注意的就是思路先清晰明确，然后再认真的开始编写代码，代码编写钱要想清楚，不要贸然开始。这次其实开始的就挺贸然的。