Code one go, but run the time will appear _CrtIsValidHeapPointer exception, followed in the morning of the bug, finally fix
Tracking to _CrtIsValidHeapPointer, note the G 8h "@dbgheap. c file in _CrtIsValidHeapPointer Note:
/*
* If This asserts fails, a bad pointer have been passed in. It May
* Totally bogus, or it may be been allocated from another heap.
* The pointer must come from the ' local ' heap.
*/
_asserte (_CrtIsValidHeapPointer (puserdata));
Probably because DLLs have a runtime heap instance that is separate from the application heap (also known as the local heap) if the runtime library is statically linked. The local heap cannot be accessed outside the DLL at this point, so there is an exception that appears above. This is also described in MSDN:
The _CrtIsValidHeapPointer function is used to ensure, a specific memory address is within the local heap. The local heap refers to the heap created and managed by a particular instance of the C Run-time library. If a Dynamic-link library (DLL) contains a static link to the Run-time library, it had its own instance of the Run-time he AP, and therefore its own heap, independent of the application ' s local heap. When _DEBUG was not defined, calls to _CrtIsValidHeapPointer was removed during preprocessing.
program crashes when a vector member function object is being refactored, this error occurs when the vector is being refactored, largely because the space allocated by the vector cannot be found when the destructor is broken.
One line to see the code discovery, the object inside the Points2, status and other vector variables are in the Calcopticalflowpyrlk (IMG1, Img2, Points1, points2, status, similarity, Window_size, level, Term_criteria, lambda, 0); The OpenCV DLL is allocated in the function, so when the object is refactored, there is an unexpected crash because the local heap cannot be accessed.
Workaround:
Before calling OpenCV's function, allocate the space yourself
Vector destructor Anomaly OpenCV Assert _CrtIsValidHeapPointer