Why cv::meanStdDev function fails with exception on debug - c++

I'm developing an opencv app for the ios platform. I have opencv compiled by my self for debug and release schemes, but when I try to run the cv::meanStdDev function with Debug scheme, the application fails with an exception ( with Release it works fine ).
The test function is very simple:
float list[] = {1.2,1.2,1.3,0.3,6.5,2.2,0.9,0.8,0.9};
cv::Mat test(1,9,CV_32F, list);
cv::Scalar mean1, stddev1;
cv::meanStdDev(test, mean1, stddev1);
printf("[%f, %f]", mean1.val[0], stddev1.val[0]);
This function works properly on Release scheme, but on Debug, it throws an exception like this:
OpenCV Error: Assertion failed (dims == 2 && ((sizes[0] == sz.height && sizes[1] == sz.width) || (allowTransposed && sizes[0] == sz.width && sizes[1] == sz.height))) in create, file /Users/jgoenetxea/libraries/OpenCV-2.4.0/trunk/opencv/modules/core/src/matrix.cpp, line 1375
terminate called throwing an exception
This line is a 'create' function of the matrix class.
In this point, the kind() function gives different values in Debug and Release schemes for the same matrix. When Debug scheme is selected, because of the result of this kind() function, the execution checks some data with a CV_Assert function invocation, and then fails.
Any ideas? Someone know what can I check?

Is this your entire program?
If no, there is a possibility of heap corruption, which is very common on OpenCV due wrong access to Mat elements.
Ex:
Mat<uchar> mat(2,2);
mat.at<float>(1,1)=0.1;
If there is such code before the program segment you wrote, there may be a chance that your heap is corrupted, then you must fix it.
On release mode you may be corrupting another area that does not interfere in this part of code, but in debug it looks like it does.
But if this is your entire code, i can't help too much... it looks right to me.

Related

Protobuf SerializeAsString causing heap debug assertion in x64

Sorry this will not be easily reproductible but maybe someone can help me along the way anyway!
I have a C++ MFC-based project (VS2019) that uses Google protobuf for communication with another C#-based application. When compiled under Win32, everything was working great. But we had to migrate to x64 and now Google protobuf functions SerializeToString and SerializeAsString causes a heap debug assertion when the generated string goes out of scope. The proto files are autogenereated from contract classes in the C# app, and I have the same problem with all of them.
Code snippet that generates the error:
auto test = API::myScope::MyTestDto(); //does not matter which protobuf class is being used
test.set_my_data(5);
{
std::string newString = test.SerializeAsString();
//Or use SerializeToString for same error:
//std::string newString;
//test.SerializeToString(&newString);
ASSERT(newString.length() > 0); //everything is fine here
} // Causes assertion when newString goes out of scope.
The heap debug assertion that is being thrown:
File: minkernel\crts\ucrt\src\appcrt\heap\debug_heap.cpp
Line: 996
Expression: __acrt_first_block == header*
Here is the part of debug_heap that is throwing the assertion:
// Optionally reclaim memory:
if ((_crtDbgFlag & _CRTDBG_DELAY_FREE_MEM_DF) == 0)
{
// Unlink this allocation from the global linked list:
if (header->_block_header_next)
{
header->_block_header_next->_block_header_prev = header->_block_header_prev;
}
else
{
_ASSERTE(__acrt_last_block == header);
__acrt_last_block = header->_block_header_prev;
}
if (header->_block_header_prev)
{
header->_block_header_prev->_block_header_next = header->_block_header_next;
}
else
{
_ASSERTE(__acrt_first_block == header); //THIS LINE THROWING ASSERTION FAULT
__acrt_first_block = header->_block_header_next;
}
memset(header, dead_land_fill, sizeof(_CrtMemBlockHeader) + header->_data_size + no_mans_land_size);
_free_base(header);
}
Some more remarks:
The string seems to look okay... until it leaves scope and causes the crash.
I have tried recompiling the whole protobuf library from latest version, and I have tried regenerating all the autogenerated c++ protobuf code, but still the same error.
The app is multithreaded, but there is really nothing else going on at the same time that should be able to compete about the memory...
Has anyone expereinced this kind of error with the protobuf SerializeAsString function?
Or do you have any other debugging pointers that you could give me?
Since this is part of a huge project, I am actually afraid that there might be some other memory corruption error in the software that is causing this whole mess. But I cannot understand what could cause this sort of problem.
#Iinspectable was pointing me in the correct direction. The problem was that the libprotobuf was compiled as DLL, and the DLL versioning was causing heap errors. I had been compiling libprotobuf as DLL since that was used before in this project, but the protobuf readme file now says that compiling libprotobuf as static LIB is to be preferred, to avoid potential heap errors caused by DLL compilation.
So I threw out the DLL and made a static LIB instead, problem solved!

Assertion Failed in MapBase.h file

I am trying to use the Eigen code (http://eigen.tuxfamily.org/index.php?title=Main_Page) in Visual Studio 2013 on Windows 8-64 bit platform, but I am getting the error related to "Assertion Failed" in MapBase.h file.
...........
eigen_assert(EIGEN_IMPLIES(internal::traits<Derived>::Flags&AlignedBit,(size_t(m_data) % 16) == 0) && "data is not aligned");
..............
Please let me know how can I resolve this issue.
As the assert tells you, the data m_data isn't aligned to a correct 32/64bit boundary. The project is configured to check the alignment of pointers.
Check the call stack, probably you used a wrong pointer (i.e. -1) for such an object, or you have a heap corruption, or you overwrote memory.

How to investigate and fix libpjsua2.so crash

SIGSEGV SEGV_MAPERR at 0x00000008
0 libpjsua2.so 0x56585a88 pj::Call::getInfo() const
1 libpjsua2.so 0x56546b44 std::allocator<pj::CallMediaInfo>::allocator()
I'm using pjsip for one of my hobby project(complies with GPL). Above you can see the stacktrace received from crashlytics. I'm using Java wrapper for pjsip.
There are a lot of users(50 %) affected by this error, however I'm not able to reproduce it on my local devices.
Not sure but I suspect that following java call lead to error. Which call C++ via JNI
public void notifyCallState(MyCall call) {
if (currentCall == null || call.getId() != currentCall.getId())
return;
CallInfo ci;
try {
ci = call.getInfo();
} catch (Exception e) {
ci = null;
}
Message m = Message.obtain(handler, MSG_TYPE.CALL_STATE, ci);
m.sendToTarget();
if (ci != null && ci.getState() == pjsip_inv_state.PJSIP_INV_STATE_DISCONNECTED) {
currentCall = null;
}
}
Code snippet is taken from examples which come from psjua download. Link to http repo. My code is the same. Any help highly appreciated
From the stacktrace is looks like call is null, and getId method is at 0x8 offset.
If that's really the case, the fix is to make sure notifyCallState isn't called with null argument, or to check it inside the method, i.e.:
if (call == null || currentCall == null || call.getId() != currentCall.getId())
return;
Your program is most likely hitting some sort of memory corruption and most likely heap memory. Following observations points towards that.
I'm not able to reproduce it on my local devices. This is common symptoms of memory corruption.
stack-trace includes std::allocator which indicates that program has been terminated while using(creating/deleting/accessing) the heap memory.
Recommendation
We should try to review the code logic and whether this program uses Interop service in correct way.I do not have much idea regarding this however it looks like your program logic does have JAVA/C++ interaction. If we are lucky we might get something obvious here and we are done.
If the stack-trace are after effect of something else, then we are in trouble we might have to take approach suggested in below posts.
Windows Platform
https://stackoverflow.com/a/22074401/2724703
Linux Platform
https://stackoverflow.com/a/22658693/2724703
Android Platform
https://stackoverflow.com/a/22663360/2724703
You may want to refer the above posts to get the idea about how to approach on such problems. As per my understanding, android platform does not have dynamic tools so you might have to use some versions(debug/additional logging) of your library.
I do hope that, above information might be useful and would have given some guidelines to approach your problem.

Boost serialization assertion fail

I use boost's binary serialization and it worked well until now. I have std::list of pointers to serialize for output (oarchive) but serialization fails inside object's serialize() function with MSVC's dialog:
R6010 -abort() has been called
and such string is printed into console window:
Assertion failed: 0 == static_cast<int>(t) || 1 == static_cast<int>(t), file c:\program files\boost\boost_1_44\boost\archive\basic_binary_oprimitive.hpp, line 91
what does it mean?
Project is pretty big, sources are distributed so I cannot post it's code here, but I tried to simulate this error within simple project - there it works fine what is strange.
P.S. I use boost 1.44 with MSVC2010EE on Windows XP. When I click "retry" on "Debug Error!" window debugger shows arrow on the code line next to serialization archive << myList; line - I mean it seems like error occurred at some destructor or something.
When I make changes inside objects serialize() function - they will be applied just when I rebuild whole project (clean before compiling) - but if I just compile it (where IDE shows that all sources which include changed header are recompiled) - no changes will happen at runtime since last version (I tried with printf()) - that's strange.
Could I occasionally set some critical definitions or something?
The line in question says:
// trap usage of invalid uninitialized boolean which would
// otherwise crash on load.
It looks like at some point you are trying to serialize a bool that hasn't been initialized. Without further code we can't help you find which one.

cvHaarDetectObjects(): "Stack aound the variable 'seq_thread' was corrupted."

I have been looking in to writing my own implementation of Haar Cascaded face detection for some time now, and have begun with diving in to the OpenCV 2.0 implementation.
Right out of the box, running in debug mode, Visual Studio breaks on cvhaar.cpp:1518, informing me:
Run-Time Check Failure #2 - Stack aound the variable seq_thread was corrupted.
It seems odd to me that OpenCV ships with a simple array out-of-bounds problem. Running the release works without any problems, but I suspect that it is merely not performing the check and the array is exceeding the bounds.
Why am I receiving this error message? Is it a bug in OpenCV?
A little debugging revealed the culprit, I believe. I "fixed" it, but this all still seems odd to me.
An array of size CV_MAX_THREADS is created on cvhaar.cpp:868:
CvSeq* seq_thread[CV_MAX_THREADS] = {0};
On line 918 it proceeds to specify max_threads:
max_threads = cvGetNumThreads();
In various places, seq_thread is looped using the following for statement:
for( i = 0; i < max_threads; i++ ) {
CvSeq* s = seq_thread[i];
// ...
}
However, cxmisc.h:108 declares CV_MAX_THREADS:
#define CV_MAX_THREADS 1
Hence, the declaration of seq_thread must never be allowed to exceed size 1, yet cvGetNumThreads() returns 2 (I assume this reflects the number of cores in my machine).
I resolved the problem by adding the following simple little statement:
if (max_threads > CV_MAX_THREADS) max_threads = CV_MAX_THREADS;
Does any of this make sense?