i have simple code written in visual studio 2010 opencv 2.4.10 extracts features input file.
mat extractsift(mat img) { cv::ptr<cv::featuredetector> detector; cv::ptr<cv::feature2d> descriptorextractor; detector = cv::featuredetector::create("dense"); descriptorextractor = cv::descriptorextractor::create("sift"); detector->set("initxystep",grid_spacing); vector<cv::keypoint> keypoints; detector->detect(img,keypoints); mat o; //mat o(keypoints.size(),128,cv_8u); descriptorextractor->compute(img,keypoints,o); return o; } although code works fine in debug mode(albeit slow), gives error:
windows has triggered breakpoint in prototype.exe.
this may due corruption of heap, indicates bug in prototype.exe or of dlls has loaded.
this may due user pressing f12 while prototype.exe has focus.
the output window may have more diagnostic information.
upon further investigation, found output variable o cannot seen in release mode(hover over), can print values on simple console dump.
in disassembler:
848: //mat o(keypoints.size(),128,cv_8u); 849: descriptorextractor->compute(img,keypoints,o); 850: 851: return o; 013f6fcf 56 push esi 013f6fd0 8d 55 c0 lea edx,[keypoints] 013f6fd3 52 push edx 013f6fd4 8d 45 0c lea eax,[img] 013f6fd7 50 push eax 013f6fd8 8b cf mov ecx,edi 013f6fda c7 45 f0 01 00 00 00 mov dword ptr [ebp-10h],1 013f6fe1 e8 42 35 02 00 call cv::feature2d::compute (141a528h) 013f6fe6 8b 45 c0 mov eax,dword ptr [keypoints] 013f6fe9 3b c3 cmp eax,ebx 013f6feb 74 09 je extractsift4+306h (13f6ff6h) 013f6fed 50 push eax **013f6fee e8 ec 5c 02 00 call operator delete (141ccdfh)** 013f6ff3 83 c4 04 add esp,4 the error occurs in line asterisks. tried several project properties (/md, mt, incremental build,...) recompiled opencv, checked platform version(v100) no avail.
for heap corruptions of sort, microsoft application verifier (freeware) invaluable. need configure basics\heaps check, suggest disable other checks first time. after saving settings, need restart program. crash @ point of corruption.
for example: consider alloc 100 bytes on heap , try write 101 bytes. in debug builds, c++ crt add padding before , after block, prevent , detect small heap corruption. in release builds, there's no padding , heap gets corrupted, learn late, @ moment of other heap operation. application verifier, program crash debugger when writes 101-st byte. when happens, can see details in visual studio's output window.
(nb: keep application verifier basics\heaps enabled programs develop)
in specific case, it's possible see vector's destructor causes crash. mean no heap corruption occurred, program trying delete non-existing heap block. due linking opencv compiled different compiler or different debug/release settings. structure of vector class , allocated block paddings differ between compilers , debug/release.
update: know different crt case, here's extended explanation.
- vector allocated in opencv , freed in program.
- if have different versions of crt (compiler, debug/release)
- allocating , freeing logic can different
- your program crash.
- if have same version of crt
- crt (c runtime library) handles memory allocation through windows heap.
- every heap has own handle.
- crt (until vs2012 or smth that) create own heap allocations.
- if have 2 different crts, trying free block allocated other crt use wrong heap handle, either crash or leak memory
- i guess, had program use crt in static library, while opencv had crt in dll.
- having crt statically linked means having private crt embedded.
- hence, had 2 crts: 1 in program, 1 in dll used opencv.
- now changed program use crt in dll, both use same dll, loaded once per process, hence have on crt now.
Comments
Post a Comment