Memory Heap Corruption using cv::SURF (Bug #325)
Description
This is actually with openCV version 2.1 (not one of the options below), though it was there in 2.0 also. When using the C++ interface, the SURF class, the operator() function is used to actually find feature points inside an image. The bug appears when using this function in debug mode (I have compiled openCV libraries in debug mode, together with my code). This is with Microsoft Visual Studio 2008. The function operator() runs fine and returns. However, when the calling function goes to return, it crashes. Visual studio says "This may be due to a corruption of the heap"
The problem is caused by the .resize() command called on line 895. Because this is allocating memory while inside the dll, but the release of memory occurs outside of the DLL, there is a memory heap corruption. This is a known problem with passing STL library items across DLL function calls and allocation/de-allocating across these boundaries. See "http://support.microsoft.com/kb/172396".
I really don't know how to fix it, except to not use the C++ interface and go with the older C interface as shown in find_obj.cpp. It seems a shame to have an interface that can't actually be used, however. :) Because I am trying to use the flann class, I have also had to copy significant portions of cvsurf.cpp into my code to get it to work. I am attaching the function that calls the SURF library that causes the error. Note that "BROKEN" must be defined to get the error.
Associated revisions
Merge pull request #325 from bitwangyaoyao:2.4_fixcanny
History
Updated by Maria Dimashova over 14 years ago
- Status deleted (
Open)
Updated by Vadim Pisarevsky over 14 years ago
any library that operates on STL vectors or other STL containers will crash when MSVC-built application in Debug configuration calls Release version of DLL. Thus this is not a problem of OpenCV. Just rebuild OpenCV in debug mode (the DLLs will have "d" suffix in their names) and link the application in Debug configuration against those Debug DLLs.
- Status set to Done
- (deleted custom field) set to wontfix
Updated by Anatoly Baksheev over 14 years ago
The reporter said: "I have compiled openCV libraries in debug mode, together with my code"
Vadim, your 'wontfix' reason does correct.
- Status changed from Done to Cancelled
- (deleted custom field) deleted (
wontfix)
Updated by Anatoly Baksheev over 14 years ago
- is not ***
:)
Updated by Vadim Pisarevsky over 14 years ago
that's right. sorry. another possible reason (actually, very similar to the mentioned above) is that the application is probably using static runtime, whereas OpenCV uses dynamic (/MDd) runtime.
if the application is linked against debug version of OpenCV and the dynamic runtime is used, then everything should work. At least it works on my machine (with VS2010 express edition).
Anatoly, does the crash happen on your machine?
Updated by Anatoly Baksheev over 14 years ago
Yes, the crash happens. I have not run the attached sample, but I have met the same issue in my code. I think the problem is serious and affect a lot of code. Here is my repro-case:
File 'gpu.hpp'
struct BP { BP; vector<Mat> vec; }
File 'bp.cpp'
BP::BP : vec(5) {}
File 'main.cpp'
void main()
{
{
BP bp;
} // access violation (BP's desctructor)
cout << "last hope" << endl;
}
Here are full explanation and some suggestions how to solve it.
http://support.microsoft.com/kb/172396
http://support.microsoft.com/kb/168958/
Updated by Anatoly Baksheev over 14 years ago
I just managed to compile OpenCV (after my experiments). Hmm.. With dynamic runtime all work corrctly, but in the support pages they advice to export vector instantiation, because runtime did this only for standart types.
Updated by Anatoly Baksheev over 14 years ago
So I am closing the bug. Vadim, thank you for pointing reason. You are as always megaexpert, able to solve everything in a minute.
- Status changed from Cancelled to Done
- (deleted custom field) set to wontfix