In my real time image tracking solution, whenever i am calling detectAndCompute i get an exception thrown.
The exception doesnt crash the program, and the tracking still works (on my machine) but due to the fact that it is constantly throwing the exception, I am seeing some major performance setbacks. Here is the exception:
Exception thrown at 0x00007FFF0FBEA839 in OpenCV2.exe: Microsoft C++ exception: ipp::IwException at memory location 0x0000004CB72FC5C8.
I tried printing the exception to get details with a try-catch clause but it didnt give me any info. Here is the line that throws this exception:
algo->detectAndCompute(frame, mask, keypoints2, descriptors2, false);
This is harmless, see for example https://github.com/opencv/opencv/issues/9718.
If you run your code outside of the debugger you will not see the exception printout.
Related
I'm writing a simple renderer using the d3d11 library in Visual Studio 2019 and it builds and runs fine. However when I try running the Graphics Debugger it immediately throws a read access violation for address 0x0000000000000000 ( which is clearly incorrect ).
The exception is thrown from the DXCaptureReplay dll on the line
DeviceContext.PSSetShader(InShaderToBind.Shader.PS, NULL, 1);
Where InShaderToBind.Shader.PS is a pointer to ID3D11PixelShader
It got the most weird when I out of a lack of ideas tried
int X = 0;
ID3D11ClassInstance* FakedClassInstance = reinterpret_cast<ID3D11ClassInstance*>(&X);
DeviceContext.PSSetShader(InShaderToBind.Shader.PS, &FakedClassInstance, 1);
As this will make the exception not throw until I try to capture a frame ( Which I guess makes sense as that pointer will only be valid for the scope where X is still valid )
The MSDN documentation states that NULL should be a perfectly valid argument to pass to PSSetShader ( as noted here: https://learn.microsoft.com/en-us/windows/win32/api/d3d11/nf-d3d11-id3d11devicecontext-pssetshader )
Any ideas for what might be going wrong?
( If I comment out PSSetShader the exception is not thrown and I can take captures )
If you enable the Direct3D Debug Device, you would see in your debug output window:
D3D11 CORRUPTION: ID3D11DeviceContext::PSSetShader: Second parameter (ppClassInstances) corrupt or unexpectedly NULL. [ MISCELLANEOUS CORRUPTION #14: CORRUPTED_PARAMETER2]
NULL (or better yet nullptr) is fine for ppClassInstances only if NumClassInstances is 0. Try:
DeviceContext.PSSetShader(InShaderToBind.Shader.PS, NULL, 0);
Generally you should make sure your program runs without emitting ERROR or CORRUPTION messages from the debug layer before attempting to use PIX or the VSGS tool.
See Microsoft Docs and this blog post.
I've been following this tutorial https://vulkan-tutorial.com/ to try and make a minecraft clone to learn how vulkan works. However, trying to create an ImageView results in "Access violation reading location 0x00000000000000F8" as can be seen here:
And here you can see that the vkCreateImageView function returns VK_SUCCESS
Initially I thought that the validation layer might be causing the exception, but removing the validation error leads to a "vector subscript out of range" error once the FrameBuffer creation tries to access the created ImageViews.
I have tried several things including: Having the VkImageView as a function variable and allocating it manually but they all result in the same Access Violation at 0x..F8. Compiling it in x86 just results in the Access Violation address changing to 0x000000A8.
I'm using the Vulkan SDK 1.0.65.1.
The Access Violation was being caused by MSI Afterburner / RivaTuner, stopping them makes the validation layers work properly again.
Source: https://vulkan-tutorial.com/FAQ
When debugging a C++ program in VS 2013, I get a crash (technically a "breakpoint") in an exception handler (catch block) after an exception is thrown. The following is from the Output window after it happens:
First-chance exception at 0x75E54878 in Program.exe: Microsoft C++ exception: _com_error at memory location 0x00C6EE24.
First-chance exception at 0x75E54878 in Program.exe: Microsoft C++ exception: ComException at memory location 0x00C6EF04.
First-chance exception at 0x75E54878 in Program.exe: Microsoft C++ exception: [rethrow] at memory location 0x00000000.
HEAP[Program.exe]: HEAP: Free Heap block 00FAB5A8 modified at 00FAB5D4 after it was freed
Program.exe has triggered a breakpoint.
I tweaked the code to find the cause and got it to the point that it does something as simple as displaying a message box. Something like:
try
{
...
}
catch (const Exception&)
{
::MessageBox(NULL, L"Error", L"Error", 0); // <-- Crash happens here,
// BEFORE the message box is displayed
}
The message from the Output window suggests that I'm trying to write to freed/invalid memory, but as you can see from this code snippet, that's not the case - I'm not even using variables at the time the crash happens.
Another strange thing is that, after the crash, the Call Stack window shows frames that were already unwound due to the exception, as if the call stack got "rebuilt".
Any ideas what's wrong?
I'm currently suffering from some strange exceptions that are most probably due to me doing something incorrectly while interacting with opencv:
First-chance exception at 0x7580b9bc in xxx.exe: Microsoft C++ exception: cv::Exception at memory location 0x00c1c624..
I've already enabled the Thrown field in the Debug -> Exceptions menu, however I really can't figure out where in my code the exception is thrown.
How can I debug this?
EDIT
the stack frame reads like this (my app won't even show up in the list!):
KernelBase.dll!7580b8bc()
[Frames below may be incorrect or missing ]
KernelBase.dll!7580b8bc()
opencv_core242d.dll!54eb60cc()
You could wrap your entire main in a try catch block which prints out the exception details. If the open CV API can throw exceptions, you will need to think about handling them anyway as part of your design:
try
{
// ... Contents of your main
}
catch ( cv::Exception & e )
{
cerr << e.msg << endl; // output exception message
}
OpenCV has this handy function called cv::setBreakOnError
If you put the following into your main before any opencv calls:
cv::setBreakOnError(true);
then your program will crash, because OpenCV will do an invalid operation (dereferencing a null pointer) just before it would throw cv::Exception normally. If you run your code in a debugger, it will stop at this illegal operation, and you can see the whole call stack with all of your codes and variables at the time of the error.
I´ve got this problem by using OpenCV with WebCam. The problem in my case is that the program is trying to read an image when the Cam hasn't been initialized.
my error code:
// open camera
capture.open(0);
while (1){
//store image to matrix // here is the bug
capture.read(cameraFeed);
The solution
// open camera
capture.open(0);
while (1){
//this line makes the program wait for an image
while (!capture.read(cameraFeed));
//store image to matrix
capture.read(cameraFeed);
(sorry about my english)
Thanks
I have following message while I am in debug mode in Visual studio 2010 Unhandled exception at 0x76c5f9e2 in test.exe: 0xC0000008: An invalid handle was specified.When I run this in regular mode I don't get this error.
The debugger stops in close.c at this line
CloseHandle( (HANDLE)_get_osfhandle(fh) ) )
Does anyone have any sugestion how such error could be avoided?
Don't handle this exception, but avoid the situation were you pass an invalid handle!
Edit:
In debug mode, the code gives you a hint that something is wrong. So you should fix that error instead of handle the exception afterwords!
I just had the same problem.
I checked for stack corruption, corruption of the handle etc. Eventually I discovered that I shouldn't have been calling CloseHandle()!
This was a handle returned by FindFirstFile(), the correct disposal function is FindClose(), not CloseHandle().