something leaks, probably cv::resize CV_INTER_AREA (Bug #2747)

Added by Stanislaw Halik about 12 years ago. Updated almost 12 years ago.

Status:Cancelled Start date:2013-01-30
Priority:Low Due date:
Assignee:Stanislaw Halik % Done:

0%
Category:objdetect
Target version:-
Affected version:branch 'master' (2.4.9) Operating System:
Difficulty: HW Platform:
Pull request:

Description

Code leaks memory unless .deallocate() on tmp is called.

https://github.com/sthalik/headtracker/blob/master/capture.cpp#L21

bool ht_get_image(headtracker_t& ctx) {
    Mat large;
if (!ctx.camera.read(large))
        return false;
if (large.cols > 320) {
        Mat tmp;
        Size newSize(320, 320 * large.rows / large.cols);
resize(large, tmp, newSize, 0, 0, CV_INTER_AREA);
tmp.copyTo(ctx.color);
        tmp.deallocate();
    }
    else {
    large.copyTo(ctx.color);
    }
    cvtColor(ctx.color, ctx.grayscale, CV_BGR2GRAY);
    ctx.grayscale.copyTo(ctx.tmp);
    equalizeHist(ctx.grayscale, ctx.grayscale);
    return true;
}

vg.log.bz2 - valgrind log (37.2 kB) Stanislaw Halik, 2013-01-30 05:08 pm

Associated revisions

Revision 55bff448
Added by Roman Donchenko almost 11 years ago

Merge pull request #2747 from jet47:gpu-resize-stream-fix

History

#1
Updated by Stanislaw Halik about 12 years ago

Attaching full log.

More-or-less relevant parts of valgrind log:

4740 Conditional jump or move depends on uninitialised value(s)
4740 at 0x50F75D9: void cv::resizeAreaFast_<unsigned char, int, cv::ResizeAreaFastVec<unsigned char, cv::ResizeAreaFastVec_SIMD_8u> >(cv::Mat const&, cv::Mat&, int const*, int const*, int, int) [clone .181765] (mat.hpp:366)
4740 by 0x52114C3: cv::resize(cv::_InputArray const&, cv::_OutputArray const&, cv::Size_<int>, double, double, int) (imgwarp.cpp:1986)
4740 by 0x51CFC7E: ht_get_image(ht_context&) (capture.cpp:18)
4740 by 0x5329BB6: ht_cycle (headtracker.cpp:105)
4740 by 0x406C94: main (headtracker-demo.cpp:58)
4740
4740 Conditional jump or move depends on uninitialised value(s)
4740 at 0x4FCA221: cv::Mat::~Mat() [clone .local.3410] (mat.hpp:366)
4740 by 0x520F99A: cv::resize(cv::_InputArray const&, cv::_OutputArray const&, cv::Size_<int>, double, double, int) (imgwarp.cpp:1945)
4740 by 0x51CFC7E: ht_get_image(ht_context&) (capture.cpp:18)
4740 by 0x5329BB6: ht_cycle (headtracker.cpp:105)
4740 by 0x406C94: main (headtracker-demo.cpp:58)
4740
4740 Conditional jump or move depends on uninitialised value(s)
4740 at 0x4FCA221: cv::Mat::~Mat() [clone .local.3410] (mat.hpp:366)
4740 by 0x51CFCC7: ht_get_image(ht_context&) (capture.cpp:20)
4740 by 0x5329BB6: ht_cycle (headtracker.cpp:105)
4740 by 0x406C94: main (headtracker-demo.cpp:58) 4740 21,429,804 bytes in 93 blocks are definitely lost in loss record 1,655 of 1,655
4740 at 0x4C2C71B: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
4740 by 0x4FD8FF3: cv::fastMalloc(unsigned long) (alloc.cpp:64)
4740 by 0x505A450: cv::Mat::create(int, int const*, int) (matrix.cpp:214)
4740 by 0x5192B5D: cv::_OutputArray::create(cv::Size_<int>, int, int, bool, int) const (mat.hpp:353)
4740 by 0x520EABE: cv::resize(cv::_InputArray const&, cv::_OutputArray const&, cv::Size_<int>, double, double, int) (imgwarp.cpp:1929)
4740 by 0x51CFC7E: ht_get_image(ht_context&) (capture.cpp:18)
4740 by 0x5329BB6: ht_cycle (headtracker.cpp:105)
4740 by 0x406C94: main (headtracker-demo.cpp:58)

#2
Updated by Vadim Pisarevsky about 12 years ago

sorry, the sample does not help. Memory leaks is such a thing that it's often possible to blame "the other" side. Try to make a standalone sample that has memory leaks. Did you try opencv/samples/c/facedetect.cpp? Does it leak memory? To the best of our knowledge - no. resize with cv::INTER_AREA interpolation should not leak memory either, it uses very safe high-level API to operate on temporary buffers - you will not find a single new/delete/malloc/free in its implementation.

So, we can only proceed with the bug if you prove using a standalone sample that it's there.

  • Priority changed from Normal to Low
  • Category set to objdetect
  • Assignee set to Stanislaw Halik

#3
Updated by Stanislaw Halik about 12 years ago

Sad to say that straightforward repro not possible. Note, however, that it happens only in 249, in 243 .deallocate() call produces a use-after-free instead.

Would a bisect be okay instead?

#4
Updated by Stanislaw Halik about 12 years ago

@Vadim:

Unless you consider such commits necessary:

https://github.com/sthalik/headtracker/commit/3b43f1412a55ec6dc1510f646ae6ce419d22dd12

the bug isn't on my side.

I have no desire to pursue bugs in your refcouting code. You can close the issue if you wish.

#5
Updated by Stanislaw Halik about 12 years ago

If the bug is indeed on my side (used API in wrong way), I'm sorry for wasting time of everyone involved.

#6
Updated by Andrey Kamaev almost 12 years ago

  • Status changed from Open to Cancelled

Also available in: Atom PDF