Ask Your Question

UMat/Mat lifetime warning

asked 2017-03-15 05:44:08 -0500

iko79 gravatar image

Hi, I'm currently trying to port my OpenCV 3.1 code to make use of OpenCL by replacing Mat objects with UMat and make adjustments accordingly. Now I saw the following warning:

! OPENCV warning: getUMat()/getMat() call chain possible problem.
!                 Base object is dead, while nested/derived object is still alive or processed.
!                 Please check lifetime of UMat/Mat objects!

What does this actually mean? I had a look into the source code of umatrix.cpp and saw that in the destructor the warning is shown when u->refcount is zero and u->urefcount is greater zero, but also when both are zero.

I'm not at all familiar with the in-depth implementation of OpenCV let alone the ocl part of it, so I have some trouble understanding what I'm doing wrong, so I would highly appreciate any related hints, thanks!

edit retag flag offensive close merge delete


can you show the piece of code causing the problem ?

berak gravatar imageberak ( 2017-03-15 06:07:19 -0500 )edit

I'll try to find it and extract it somehow, the codebase is pretty huge, so I am afraid this will be difficult. I was hoping that there are some general guidelines for using the ocl implementation of OpenCV, which could hint me to a possible problem... Is there something like a how-to/troubleshooting/common mistakes for porting to ocl?

iko79 gravatar imageiko79 ( 2017-03-15 06:51:46 -0500 )edit

1 answer

Sort by ยป oldest newest most voted

answered 2018-07-23 03:25:51 -0500

steffen.ehrle gravatar image

I am also running into this issue a lot. Apparently I can tell, that the error occurs mostly when the original created Mat/UMat object is released before the other ones (got by calling getMat/getUMat). I.e.:

cv::UMat umat;  
cv::Mat mat(200, 400, CV_8U);
umat = mat.getUMat(cv::ACCESS_RW, cv::UMatUsageFlags::USAGE_DEFAULT);
// Not calling umat.release() would leave both until end of scope where the original 
// object (mat) could be destroyed first.

From my understanding this should be handled by urefcount and refcount? Seems to be a bug in handling the ownership of the UMatData. Nevertheless you should be safe if keeping the 'base' (the mat object that created the data) alive and make sure it is deleted last.

edit flag offensive delete link more

Question Tools

1 follower


Asked: 2017-03-15 05:44:08 -0500

Seen: 1,069 times

Last updated: Mar 15 '17