说说这阵子遇到的烦人bug

从上周开始的行人检测项目, 到现在已经遇到过不少的bug, 有两个还暂时还没有解决. 有提示的bug都比较好弄, 要命的是没提示的, 断点看数值变化又看不出来, 我现在弄这几个弄了都有四五天了

我自己debug的步骤是 

看提示(确定函数使用错没错)- 看显示(cout, imshow之类的)- 加断点看输入输出(看数据变化)- 看源码 - 硬试(更换输入, 重写代码之类的),  我是半路出家的不太清楚正规步骤是什么

说说比较糟心的三个

环境:  ubuntu 14.04 64位 , c++11 , opencv 3.1.0

          ubuntu 16.04 32位 , c++11 , opencv 3.1.x

1. 对vector push_back一定量数目float类型的数据后,  也就是将hog的3780维描述子push到一个vector里去, 提示达到max_size(具体什么提示忘记了). 

一开始还怀疑自己的用法错了, 总是有错误, 最后我是直接拷贝内存到vector里才解决这个问题的. 打印看一个vector的max_size有一大串数字(这个数字应该是size_t(-1)/sizeof(tp), tp对应template变量) , 就算是3780*10也没达到那个数字

2. 报错函数: HOGDescriptor::compute()

    错误信息:  除了segment fault 没有任何提示

因为它是过了第一个大循环之后再调用compute出错的(ps: 因为是多尺度, 嵌套了4层循环, 读图,尺度变换,滑窗)

所以一开始我还想是不是输入的图像不对? 因为是自己写的detectMultiScale, 所以就一直在查哪里写错了, 后来又看了源码, opencl部分我暂时还没有办法看, 其他部分怎么看也看不出问题.

后来慢慢试, 发现当我的循环次数多了的时候, 它才会报错, 所以还是怀疑hog里面的并行与opencl加速实现出了问题

解决办法: 减少循环次数, 暂时没找到其他解决方法

-----------------------------------------------------------------------------------------------

gdb debugger:

偶然在知乎上看到gdb的使用, 我还是第一次用, 信息明显比qt多了些, 能看到调用栈, 能看到new了这么多线程

但是按他的方法捣鼓了一会还是没有办法得到更详细的错误信息, 和我当初用qt一样是加断点看参数..

只能看源代码去逐一排查调用栈上面的函数, 而我对opencl具体实现一无所知, 所以这个问题对于我来说还是无解

换回opencv2可能会有帮助, 但是我暂时没有这个打算

                                                                                                                            2016. 9 .11        3:43

-------------------------------------------------------------------------------------------------------------------------

3.报错函数: HOGDescriptor::detectMultiScale()

   错误信息: 输出结果错误

这个输出结果错误的很诡异. 一开始没太注意到这个错误, 后来发现, 多尺度检测到的区域, 是每张图片的正中央

没错, 就是正中央, 不管什么图片. 
刚开始我还在想, 是不是训练错了?怎么会这么巧?将结果显示出来后才发现到这么一个规律.

打印了每一个找到的区域, 截一段大家感受下, 按照 label - img.size() - Rect 顺序打印的

1
[1141 x 762]
[91 x 181 from (525, 289)]
1
[1058 x 787]
[91 x 181 from (482, 302)]
1
[1161 x 960]
[93 x 186 from (534, 387)]
1
[1083 x 704]
[89 x 179 from (496, 262)]
1
[933 x 668]
[88 x 177 from (422, 245)]
1
[543 x 366]
[80 x 159 from (231, 103)]
1
[1176 x 960]
[93 x 186 from (541, 386)]
1
[1088 x 960]
[93 x 185 from (497, 388)]
1
[1201 x 960]
[93 x 186 from (551, 387)]
1
[1198 x 921]
[93 x 185 from (552, 368)]
1
[893 x 708]
[89 x 178 from (402, 264)]
1
[1055 x 879]

之前我用它找hard example时还好好的, 同样看了源码, 同样看不懂opencl加速的部分

是不是训练svm训练错了? 我从头又训练了几个, 一个一个的去试, 都是一个结果, 心理犯嘀咕, 拿别人训练好的, 还是同样的结果. 注意我这里用的测试集测试, 训练集没有出现过这些图片

在程序中断点调试, 对比了我提供的decision function 与 getDefaultPeopleDetector中的数据, 内容是差不多的.

仔细想想, 几百张的图片检测到的区域全是正中央, 未免太过巧合. 因为滑窗每个区域都遍历过了, 若是分类器训练错误, 最多可能所有图片都检测不到行人. 能检测到又是正中央,又同时是几百张同一个结果, 如果detectMultiScale程序没有问题的话, 这种事情几乎是不可能事件, 每个样本是独立的.

所以这里高度怀疑detectMultiScale函数, 我猜测是对速度进行优化的部分出了问题, 比如并行计算和opencl优化部分

解决办法: 暂无