Possible memory leak in cvtColor with TBB support [closed]

asked 2015-07-13 15:49:42 -0600

gfolego gravatar image

updated 2015-07-20 09:00:51 -0600

Dear all,

I'm running some tests with cvtColor and valgrind reports a memory leak.

Some information about the environment:

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 14.04.2 LTS
Release:    14.04
Codename:   trusty

$ uname --all
Linux <hidden> 3.16.0-34-generic #47~14.04.1-Ubuntu SMP Fri Apr 10 17:49:16 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

$ pkg-config --modversion opencv
2.4.8

$ g++ --version
g++ (Ubuntu 4.8.4-2ubuntu1~14.04) 4.8.4
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ valgrind --version
valgrind-3.10.0.SVN

This is a short standalone sample:

$ cat test.cpp 
#include <iostream>
#include <opencv2/core/core.hpp>
#include <opencv2/imgproc/imgproc.hpp>

int main()
{
    std::cout << cv::getBuildInformation() << std::endl;

    cv::Mat src = cv::Mat::zeros(5, 5, CV_8UC3);
    cv::Mat dst;

    cv::cvtColor( src, dst, CV_BGR2GRAY );
}


$ g++ -Wall -Wextra -Werror -Weffc++ -ansi -pedantic -O2 test.cpp -o test  $(pkg-config --cflags --libs opencv) 
<nothing printed on screen>

And the output from valgrind:

$ valgrind --leak-check=full ./test 
==15342== Memcheck, a memory error detector
==15342== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==15342== Using Valgrind-3.10.0.SVN and LibVEX; rerun with -h for copyright info
==15342== Command: ./test
==15342== 

General configuration for OpenCV 2.4.8 =====================================
  Version control:               unknown

  Platform:
    Host:                        Linux 3.2.0-58-generic x86_64
    CMake:                       2.8.12.2
    CMake generator:             Unix Makefiles
    CMake build tool:            /usr/bin/make
    Configuration:               Release

  C/C++:
    Built as dynamic libs?:      YES
    C++ Compiler:                /usr/bin/x86_64-linux-gnu-g++  (ver 4.8.2)
    C++ flags (Release):         -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2    -fsigned-char -W -Wall -Werror=return-type -Werror=address -Werror=sequence-point -Wformat -Werror=format-security -Wmissing-declarations -Wundef -Winit-self -Wpointer-arith -Wshadow -Wsign-promo -Wno-narrowing -Wno-delete-non-virtual-dtor -fdiagnostics-show-option -Wno-long-long -pthread -fomit-frame-pointer -msse -msse2 -ffunction-sections -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security  -DNDEBUG
    C++ flags (Debug):           -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2    -fsigned-char -W -Wall -Werror=return-type -Werror=address -Werror=sequence-point -Wformat -Werror=format-security -Wmissing-declarations -Wundef -Winit-self -Wpointer-arith -Wshadow -Wsign-promo -Wno-narrowing -Wno-delete-non-virtual-dtor -fdiagnostics-show-option -Wno-long-long -pthread -fomit-frame-pointer -msse -msse2 -ffunction-sections -g  -O0 -DDEBUG -D_DEBUG
    C Compiler:                  /usr/bin/x86_64-linux-gnu-gcc
    C flags (Release):           -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2    -fsigned-char -W -Wall -Werror=return-type -Werror=address -Werror=sequence-point -Wformat -Werror=format-security -Wmissing-declarations -Wmissing-prototypes -Wstrict-prototypes -Wundef -Winit-self -Wpointer-arith -Wshadow -Wno-narrowing -fdiagnostics-show-option -Wno-long-long -pthread -fomit-frame-pointer -msse -msse2 -ffunction-sections -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security  -DNDEBUG
    C flags (Debug):             -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2    -fsigned-char -W -Wall -Werror=return-type -Werror=address -Werror=sequence-point -Wformat -Werror=format-security -Wmissing-declarations -Wmissing-prototypes -Wstrict-prototypes -Wundef -Winit-self -Wpointer-arith -Wshadow -Wno-narrowing -fdiagnostics-show-option -Wno-long-long -pthread -fomit-frame-pointer -msse -msse2 -ffunction-sections -g  -O0 -DDEBUG -D_DEBUG
    Linker flags (Release):      -Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,now -Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,now
    Linker ...
(more)
edit retag flag offensive reopen merge delete

Closed for the following reason question is not relevant or outdated by sturkmen
close date 2020-10-25 07:22:18.681660

Comments

I have a weak experience with valgrind but I think"possibly lost" is not lost. You can see an example p56 of valgrind manual

LBerger gravatar imageLBerger ( 2015-07-14 03:33:17 -0600 )edit

Thanks for the reference. From what I've read, we can only suppose it is possible to ignore these warnings. Check this and this threads. By the way, even though it is not actually lost (in the sense it is not possible to recover the memory), the blocks are not released, so there is still memory in use at the end of execution.

gfolego gravatar imagegfolego ( 2015-07-14 10:56:07 -0600 )edit

I've opened a new issue about these findings: http://code.opencv.org/issues/4489

gfolego gravatar imagegfolego ( 2015-07-20 09:20:54 -0600 )edit