CvImage中的陷阱和BUG
目录 |
CvImage类的定义
class CV_EXPORTS CvImage
{
public:
CvImage() : image(0), refcount(0) {}
CvImage( CvSize size, int depth, int channels )
{
image = cvCreateImage( size, depth, channels );
refcount = image ? new int(1) : 0;
}
CvImage( IplImage* img ) : image(img)
{
refcount = image ? new int(1) : 0;
}
~CvImage()
{
if( refcount && !(--*refcount) )
{
cvReleaseImage( &image );
delete refcount;
}
}
void attach( IplImage* img, bool use_refcount=true )
{
if( refcount )
{
if( --*refcount == 0 )
cvReleaseImage( &image );
delete refcount;
}
image = img;
refcount = use_refcount && image ? new int(1) : 0;
}
void detach()
{
if( refcount )
{
if( --*refcount == 0 )
cvReleaseImage( &image );
delete refcount;
refcount = 0;
}
image = 0;
}
CvImage& operator = (const CvImage& img)
{
if( img.refcount )
++*img.refcount;
if( refcount && !(--*refcount) )
cvReleaseImage( &image );
image=img.image;
refcount=img.refcount;
return *this;
}
protected:
IplImage* image; // 实际影象
int* refcount; // 引用计数
};
CvImage类的相关代码在以下位置:
OpenCV2\core\include\core.hpp
OpenCV2\core\src\imgproc.cpp
这里给出的只是部分函数。
为了提高效率,CvImage采用的是引用计数。不过目前的CvImage实现中,引用计数机制存在bug。
关于引用计数
引用计数应该也可以叫写时复制技术。就是在复制一个数据时,先只是简单地复制数据的 指针(地址),只有在数据被修改的时候才真的进行数据的复制操作。写时复制技术对用户 是透明的,也就是说用户可以当作数据是真的复制了。
一般数据(或者是文件,类等)都会对应创建/销毁操作。因此,采用写时复制技术的数据 一般还对应一个计数,记录该数据被别人引用的次数。数据在第一次被创建的时候被设置为1, 以后每次被重复创建则增加1,如果是被销毁则减少1。再销毁数据减少引用计数的时候,如果 记录变为0则真的执行删除数据操作,否则的话只执行逻辑删除。
这里需要注意的一点是,每个引用计数和它对应的数据是绑定的。因此,任何一个引用计数都 不应该独立于数据存在。
CvImage中的引用计数机制
class CV_EXPORTS CvImage
{
IplImage* image;
int* refcount;
};
image指向影像数据的地址,refcount指向影像数据对应的引用计数的地址。需要强调的一点是, refcount指向的引用计数并不属于哪个类,而是属于image指向影像数据!任何将影像数据 和其对应的引用计数分离的操作都是错误的。
CvImage(IplImage* img)陷阱
假设有下面一个段代码:
IplImage *pIplImg = cvLoadImage("load.tiff");
{
CvImage cvImg(pIplImg);
}
cvSaveImage("save.tiff", pIplImg);
虽然逻辑上好像没有错误,但再执行到cvSaveImage语句的时候却会产生异常!跟踪调试后发现, 原来pIplImg对应的数据在cvImg析构的时候被释放了!
仔细分析后会发现,CvImage将pIplImg对应的数据和它本身的refcount绑定到一起了。pIplImg 对应的数据虽然不属于CvImage,但是它却依据refcount对其进行管理,直到(*refcount)变为0 的时候私自释放了pIplImg影像。
对于这个问题,我不建议使用引用计数,因此可以将代码修改为:
CvImage( IplImage* img, bool use_refcount=false) : image(img)
{
refcount = use_refcount && image ? new int(1) : 0;
}
在默认的时候不使用引用计数机制,用户自己维护img内存空间。
attach问题
void attach( IplImage* img, bool use_refcount=true )
{
if( refcount )
{
if( --*refcount == 0 )
cvReleaseImage( &image );
delete refcount;
}
image = img;
refcount = use_refcount && image ? new int(1) : 0;
}
attach是将一个IplImage影像绑定到CvImage。其中的一个陷阱和前面的CvImage类似:
IplImage *pIplImg = cvLoadImage("load.tiff");
{
CvImage cvImg;
cvImg.attach(pIplImg);
}
cvSaveImage("save.tiff", pIplImg); // 异常
处理是方法是把参数use_refcount的默认值改为false。
除了和CvImage类型的陷阱外,attach本身还有一个bug!前面我们分析过,CvImage类中 refcount指向的空间和image指向的空间是绑在一起的。因此,if( --*refcount == 0 ) 语句中将cvReleaseImage( &image )和delete refcount分离的操作肯定是错误的!!
假设有以下代码:
IplImage *pIplImg = cvLoadImage("load.tiff");
{
CvImage cvImg;
cvImg.create(cvSize(600,400), 8, 1); // 创建一个600*400的单字节单通道影像
CvImage cvImgX(cvImg); // 由cvImg拷贝构造cvImgX
cvImgX.attach(pIplImg);
}
cvSaveImage("save.tiff", pIplImg);
代码将在执行完cvImgX.attach(pIplImg)语句后发生异常!
分析代码可以发现,cvImg.create先创建了一个影像,同时影像还对应一个引用计数。由于cvImgX 是有cvImg拷贝构造得到,因此cvImgX也保存了和cvImg一样的image和refcount。在接着执行的 attach中,cvImgX将refcount指向的空间释放(delete refcount)。注意,cvImgX和cvImg的refcount 对应同一个空间!!那么在,cvImg退出花括号执行析构函数的时候,delete refcount语句就非法了!
修改bug后的attach代码:
void attach( IplImage* img, bool use_refcount=false ) // use_refcount默认值没有修改
{
if( refcount )
{
if( --*refcount == 0 )
{
// 同时释放
cvReleaseImage( &image );
delete refcount;
}
}
image = img;
refcount = use_refcount && image ? new int(1) : 0;
}
由于CvImage中的许多函数都基于attach实现,因此没有修改use_refcount的默认值。detach中的问题 和attach相似,代码修改如下:
void detach()
{
if( refcount )
{
if( --*refcount == 0 )
{
// 同时释放
cvReleaseImage( &image );
delete refcount;
}
refcount = 0;
}
image = 0;
}
重载操作符“=”时的内存泄漏
CvImage& operator = (const CvImage& img)
{
if( img.refcount )
++*img.refcount;
if( refcount && !(--*refcount) )
cvReleaseImage( &image );
image=img.image;
refcount=img.refcount;
return *this;
}
假设有以下类似代码:
CvImage cvImg1, cvImg2;
cvImg1.create(cvSize(600,400), 8, 1);
cvImg2.create(cvSize(800,500), 8, 1);
cvImg1 = cvImg2;
虽然看着很清晰,但是该代码却存在内存泄漏!分析如下:
cvImg1先创建一个(600,400)大小的影像,默认还对应一个引用计数(refcount指向的空间)。cvImg2 也采用同样的方式创建一个类似的影像。注意:cvImg1和cvImg1中refcount指向的空间是不同的!!
下面执行“=”操作时,cvImg1的image空间被释放(cvReleaseImage( &image )),但是cvImg1的 refcount指向的空间却没有释放!然后,cvImg1的refcount指向了cvImg2的refcount。这样,cvImg1 的refcount指向内存就丢失了!
修改后的代码:
CvImage& operator = (const CvImage& img)
{
if( img.refcount )
++*img.refcount;
if( refcount && !(--*refcount) )
{
cvReleaseImage( &image );
// 释放refcount
delete refcount;
}
image=img.image;
refcount=img.refcount;
return *this;
}
小节
虽然讲了这么多关于CvImage的陷阱和bug,单主要目的还是为了更好地使用CvImage。这里给出一个 建议:
在将IplImage数据和CvImage进行绑定,或者是基于IplImage数据构造CvImage对象的时候, 要清楚是否需要使用CvImage的引用计数技术(有哪些好处/坏处)。
特别是attach默认是采用引用计数的(没改的理由前面已经说明)。
附:修复的CvImage
class CV_EXPORTS CvImage
{
public:
CvImage() : image(0), refcount(0) {}
CvImage( CvSize size, int depth, int channels )
{
image = cvCreateImage( size, depth, channels );
refcount = image ? new int(1) : 0;
}
// 修改
CvImage( IplImage* img, bool use_refcount=false) : image(img)
{
refcount = use_refcount && image ? new int(1) : 0;
}
~CvImage()
{
if( refcount && !(--*refcount) )
{
cvReleaseImage( &image );
delete refcount;
}
}
// 修改
void attach( IplImage* img, bool use_refcount=false ) // use_refcount默认值没有修改
{
if( refcount )
{
if( --*refcount == 0 )
{
// 同时释放
cvReleaseImage( &image );
delete refcount;
}
}
image = img;
refcount = use_refcount && image ? new int(1) : 0;
}
// 修改
void detach()
{
if( refcount )
{
if( --*refcount == 0 )
{
// 同时释放
cvReleaseImage( &image );
delete refcount;
}
refcount = 0;
}
image = 0;
}
// 修改
CvImage& operator = (const CvImage& img)
{
if( img.refcount )
++*img.refcount;
if( refcount && !(--*refcount) )
{
cvReleaseImage( &image );
// 释放refcount
delete refcount;
}
image=img.image;
refcount=img.refcount;
return *this;
}
protected:
IplImage* image; // 实际影象
int* refcount; // 引用计数
};