I am trying to compile the facedetect.cpp in the OpenCV\Samples\C folder, in Visual Studio 2010. The project compiles and begins just fine, shows a preview of my camera, and then seems to crash at cascade.detectMultiScale() as soon as it detects a face. I concluded that OpenCV thinks I am too ugly.
Unhandled exception at 0x100342bf in HeadTrackerExample.exe: 0xC0000005: Access violation writing location 0x00000000.
Unfortunately the debug info doesn't let me probe deeper. I am linking against cv210.lib;cxcore210.lib;highgui210.lib; the debug versions won't work:
LDR: LdrpWalkImportDescriptor() failed to probe D:\OpenCV2.1\bin\cv210d.dll for its manifest, ntstatus 0xc0150002
I'm going to try to trick the classifier with a printout of Anne Hathaway but I am open to other suggestions.
https://code.ros.org/trac/opencv/browser/trunk/opencv/samples/c/facedetect.cpp
I guess I'm better looking than you because it's working here (under OS X). Are you sure you're successfully loading the xml files? Are you using the default xml files (haarcascade_frontalface_alt.xml and haarcascade_eye_tree_eyeglasses.xml)?
It sure looks like you have a null pointer. Try setting a breakpoint at the call to cascade.detectMultiScale() and examine the values of cascade, smallImg, smallImg.data, and faces.
Edit: populating the faces vector
Here's the detectMultiScale code:
void HaarClassifierCascade::detectMultiScale( const Mat& image,
Vector<Rect>& objects, double scaleFactor,
int minNeighbors, int flags,
Size minSize )
{
MemStorage storage(cvCreateMemStorage(0));
CvMat _image = image;
CvSeq* _objects = cvHaarDetectObjects( &_image, cascade, storage, scaleFactor,
minNeighbors, flags, minSize );
Seq<Rect>(_objects).copyTo(objects);
}
It's not touching the faces vector until the last line after all the detection is done. If you are adventurous, you could throw some printf statements in here to see if cvHaarDetectObjects is completing and if it is returning a null pointer.
I spent the day trying to fix this. Who knows why it was crashing? I couldn't link to the debug DLLs so we'll never know. I downloaded the OpenCV-2.1.0-win32-vs2008.exe distribution. And I am using Visual Studio 2010. Therefore, the exe was crashing with
LDR: LdrpWalkImportDescriptor() failed to probe D:\OpenCV2.1\bin\cv210d.dll for its manifest, ntstatus 0xc0150002
Debugger:: An unhandled non-continuable exception was thrown during process load
The program '[5172] HeadTrackerExample.exe: Native' has exited with code -1072365566 (0xc0150002).
This is the "0xc0150002 error". According to Dependency Walker, the OpenCV debug DLLs are trying to find msvcr90d.dll and msvct90d.dll, the Visual Studio 2008 debug runtime DLLs. Well, I obtained these and it still didn't work, so then this gets into esoteric Windows sidebyside and manifest stuff.
I switched to the OpenCV-2.3.1-win-superpack.exe distribution and it is now working.
Related
I have taken over a Xamarin.Forms (C#) application from an external source for fixing.
Problem is, that the application does sometimes fail with a runtime error:
System.NullReferenceException: Object reference not set to an instance of an object
The message appears in the output console and in a separate message window in Visual Studio. Unfortunately neither gives any more information about the failed object, a source code line number or a classname, there is just the bare message. Furthermore the "Call Stack" window in Visual Studio is always empty --> I have no easy way to find out where the failure occurs in foreign source code, because virtually no documentation of the program flow exists.
Full source code is available, and I have re-built the application with "Debug" configuration.
Right now the only option I can think of is to scatter breakpoints and Debug.Writelines all over the source code to get an idea where the problem occurs.
Is this really my only option, or did I miss some setting somewhere, so I can retrieve more info, so I can somehow go straight to the code where the failure occurs?
Thx!
Has anyone else ever seen this happen? I've had Visual Studio crash over and over again when typing in an object initializer: https://msdn.microsoft.com/en-us/library/bb384062.aspx
I suspect it's some kind of Intellisense bug, since it seems to occur only when the space or period key is pressed. I'm really curious what's triggering the sudden and reproducible crash and if there's any patches or workaround to prevent it from occurring.
The image shows where the cursor is when typing within the first set of brackets. This code appears in a method, which implements an interface member for the class.
This appears to have been caused by the "HideShow Comments" extension. I'm still not sure why it occurs, but disabling the plugin stops the crash from occurring and re-enabling the extension causes the crash to occur again. This must be a problem with Visual Studio itself, since it's the only common denominator in all these extension-related crashes.
I attached a debugger and caught the following error:
An unhandled exception of type 'System.NullReferenceException'
occurred in HideShow.Implementation. Additional information: Object
reference not set to an instance of an object.
I've assembled my new PC yesterday, and I've decided to give Windows 8 a try. However, today, during the debugging of moderate Qt application, debugger yielded "Invalid Binding Handle" error message on a pretty simple line (it was line that is auto-generated by Qt's moc.exe:
// QWebView *view (...)
view->setUrl(QUrl(QString::fromUtf8("about:blank")));
// Failing in setUrl call, not in QUrl constructor, or in fromUtf8 function.
However, running this application without debugger works just fine, both in Release and Debug versions.
I've got some clues on the internet to enable Terminal Services, but it seems that there is no such service in Windows 8.
Does anybody have any clue what should I check?
Edit
Moving the widget into other application yielded no error, so apparently, widget (which is pretty small - just QWebView and QProgressBar) is fine. But, when I show this widget in my main function:
QApplication app(argc, argv);
MyWidget w;
w.show();
return app.exec();
it is still failing with the same error. Examining call stack (which is not very helpful when error appear) and stepping into function calls, I've tracked error down to retval = HeapFree(_crtheap, 0, pBlock); in function _free_base, in file free.c And it seems that function is called from dbgdel.cpp, function _free_dbg( pUserData, pHead->nBlockUse ); and it is called from unlock() function.
Attaching the debugger to already active process is still yielding the same error.
I am linking a lot of 3rd party libraries here, so I will try without them, as I'm run out of ideas...
Edit 2:
If I pass this exception to the program, it seems to be running fine.
Edit 3
Commenting setUrl line raises the same exception somewhere in QWebKit, where strdup function is called...
Well, this was easy, but it took me two months to solve (while ignoring the error in the meantime).
This was not an unhandled exception - this was handled exception, and stepping into assembly code and watching the stack frame told me that this exception was handled.
Then I remembered that I've set debugger to break when all C++ and Win32 exceptions are raised. Resetting the debugger settings removed the issue.
I wanted to set breakpoint in the dll code so I introduced the statement "_asm int 3;". IE is supposed to open a dialog box saying that an unexpected exception has occured, and whether to close or debug. But it simply cuts down the window. The dll is a _Debug version not _Release version.
Another thing I noticed is that using the "debugger;" statement in the javascript code also causes the same behaviour - window dies without notice.
Why is this happening?
JIT debugging might be disabled. In your Visual Studio options, under Debugging > Just-In-Time, check the Native and Script options.
As an aside, you should probably call DebugBreak() instead of issuing _asm int 3. It's clearer that way.
I am creating a shell extension in C++ (ATL 9) using Visual Studio 2008. The Shell Extension creates a global MSXML2::IXMLDOMDocumentPtr object m_XmlDoc in the module class. This m_XmlDoc is then used in the extension by all classes to read xml document.
The problem that I am facing is with Internet explorer. When the Shell Extension is active and I open/close internet explorer, I get a debug dialog and IE crashes. The error message says "Unhandled exception at 0x6aac30f1 in iexplore.exe: 0xC0000005: Access violation reading location 0x03050970."
When I click "break" on the message window, It takes me to the "Release" method of COM Smart Pointer and the error seems to be on
m_pInterface->Release();
This call was made from Module's destructor and also the value of m_pInterface is not NULL. I think maybe internet explorer is using the XML DOM and the call to Release creates some problem in it.
MSXML2::IXMLDOMDocumentPtr m_XmlDoc;
In _AtlModule.Init() method
::CoInitialize(NULL);
m_XmlDoc.CreateInstance(MSXML2::CLSID_DOMDocument40);
dllMain code:
extern "C" BOOL WINAPI DllMain(HINSTANCE hInstance, DWORD dwReason, LPVOID lpReserved)
{
::CoInitialize(NULL);
if (dwReason == DLL_PROCESS_ATTACH)
{
_AtlModule.Init();
CreateImageLists();
::DisableThreadLibraryCalls(hInstance);
}
hInstance;
return _AtlModule.DllMain(dwReason, lpReserved);
}
the use of DisableThreadLibraryCalls is discouraged, you seen it?
There are at least two problems with your code as posted:
You're calling CoInitialize in DllMain.
You're creating a COM object in DllMain.
It wouldn't surprise me if you're doing something in CreateImageLists() which you also shouldn't be doing in DllMain.
Also, the reason that your crash was "fixed" by not using the smart pointer is because now you're not actually releasing the object anymore. Your code is broken, and not releasing the reference isn't a valid way to fix anything.
I would suggest that you read, and then re-read, the documentation for DllMain paying particular attention to the things you should never do within your implementation of the function. As you'll see right up front:
Warning There are serious limits on what you can do in a DLL entry point. To provide more complex initialization, create an initialization routine for the DLL. You can require applications to call the initialization routine before calling any other routines in the DLL.
I suspect once you read it, and fix your code to create the COM object at a valid time, and release it at a valid time, your shell extension will stop crashing.
The problem was because of the COM Smart Pointer used for XmlDomDocument. I changed it to a normal pointer and it is working fine even in Vista.
This problem has a different behaviour in XP and Vista. In XP, I was getting an unhandled exception when I closed Internet Explorer. In Vista, I was not able to browse the virtual drive.