I'm currently doing some tests using Cairo to replace some existing GDI/GDI+
code in Visual C++ 2010 and it seems to be working fine, but I'm getting
an error message each time I close down my application :
"First-chance exception at 0x68e629dc in CairoTest.exe: 0xC0000005:
Access violation reading location 0xabababa7"
This error only happens if I've called cairo_paint(cr) while the
application is running - if I comment this line out, it disappears. The
only Cairo code in my application so far is :
CChildView::CChildView()
{
testsurface = cairo_image_surface_create_from_png("BlackShinyBackground.png");
}
CChildView::~CChildView()
{
cairo_surface_destroy(testsurface);
}
void CChildView::OnPaint()
{
CPaintDC dc(this);
cairo_surface_t *surface = cairo_win32_surface_create(dc.m_hDC);
cairo_t *cr = cairo_create (surface);
cairo_set_source_surface(cr, testsurface, 0, 0);
cairo_paint(cr);
cairo_destroy (cr);
cairo_surface_destroy (surface);
}
Can anybody point me in the direction of what I'm doing wrong?
Like I said, the code appearsto be working fine, but I don't like just ploughing on regardless when I can see errors.
A first chance exception doesn't necessarily mean much -- they're a routine part of Windows' memory management. Basically, any time you access something that's in virtual memory (e.g., on the paging file) a first chance exception is created. The OS handles it by paging in the required data into physical memory, then your code can continue executing.
If/when you see a second-chance exception, it means the OS didn't handle the exception, so unless you have a handler for it in your code, chances are pretty good that is signals a real problem.
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 have a problem I just can't find information for. The following code is causing the issue (I have left out a lot of code for brevity, but as I will explain, this code seems to work fine):
mHDC = GetDC(mHWnd);
int format = ChoosePixelFormat(mHDC, &pixelFormat);
SetPixelFormat(mHDC, format, &pixelFormat);
mHGLRC = wglCreateContext(mHDC);
wglMakeCurrent(mHDC, mHGLRC);
mHWnd is obtained through CreateWindow()
const HINSTANCE hInstance(static_cast<HINSTANCE>(::GetModuleHandle(NULL)));
mHWnd = CreateWindow(wndClass.lpszClassName, L"Test Application", style, CW_USEDEFAULT, CW_USEDEFAULT, clientRect.right, clientRect.bottom, NULL, NULL, hInstance, NULL);
ChoosePixelFormat() is causing an invalid handle first-chance exception in the debugger when I am using the Application Verifier with only Handles and Cuzz enabled. These two together cause the exception to trigger. Without both of these enabled (even if I just do one or the other), the exception isn't thrown and everything works okay. When I run the application without attaching to the debugger, the application crashes instead.
Even though the exception is raised, once I hit wglMakeCurrent() (by continuing debugging after and ignoring the exception), all the variables seem to end up with valid values anyway:
mHWnd == 0x1a1064e
mHDC == 0x440119c0
format == 7
mHGLRC == 0x10000
The stack trace looks like this:
ntdll.dll!00000000772012f7()
vfbasics.dll!000007feedaa81b4()
KernelBase.dll!000007fefd1610dc()
vfbasics.dll!000007feedaa7ce9()
vfcuzz.dll!000007fee5075179()
nvoglv64.dll!000000006979b732()
vfbasics.dll!000007feedaac1d5()
kernel32.dll!0000000076fa652d()
ntdll.dll!00000000771dc521()
And the active thread is a vfcuzz.dll thread, which is obviously allowing Cuzz to do it's business. vfbasics.dll in the stack trace is where the handle checker is, and as I said, only the handle checker is enabled.
For completion sake, here is the actual exception message:
First-chance exception at 0x00000000772012F7 (ntdll.dll) in Tests.exe: 0xC0000008: An invalid handle was specified.
I am assuming it isn't a bug in the Application Verifier that is causing it to throw an exception that shouldn't exist and crashing the program. I am just confused as to why it is throwing the exception when clearly I am getting valid values back from the function calls. I don't really want to ignore it until I understand what is going on.
It doesn't look like a problem with your code. The only handle ChoosePixelFormat takes is an HDC and the one you're giving it is presumably valid (although in the code you're showing there's no checking that GetDC succeeded, I assume you just left that out for brevity).
A first-chance exception isn't necessarily a problem. It simply means an exception occurred, and this is the first chance to handle it. My guess is the exception is most likely happening within the ChoosePixelFormat function itself (or within a function that ChoosePixelFormat calls) and being handled there - it's only because you are debugging that you actually find out about it. In every day usage the exception would be handled quietly and you'd never even know it had happened.
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've been tracking down a really insidious bug at work. The event that seems to cause the very strange behavior I've been tracking down appears to be an exception being thrown while processing a timer callback. The exception is NOT handled by any of my code, therefore I would expect the debugger to be notified of the unhandled exception and alert me with a nice obnoxous pop-up. No, instead the "first chance" exception message traces out to the debugger and everything silently moves on.
I've written up the following program that demonstrates this issue:
#include "stdafx.h"
#include <Windows.h>
class FooExcept
{
};
VOID CALLBACK Timer(HWND hwnd,
UINT uMsg,
UINT_PTR idEvent,
DWORD dwTime)
{
printf("Here\n");
throw FooExcept();
printf("Also Here\n");
}
int _tmain(int argc, _TCHAR* argv[])
{
SetTimer(0, 0, 1000, Timer);
int bRet;
HWND hWnd;
MSG msg;
// Standard Win32 message pump
while( (bRet = GetMessage( &msg, NULL, 0, 0 )) != 0)
{
if (bRet == -1)
{
// handle the error and possibly exit
}
else
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
}
return 0;
}
The output of this program to the Visual Studio Output window is this repeated:
First-chance exception at 0x76dbb9bc in TimerTest.exe: Microsoft C++ exception: FooExcept at memory location 0x0034f743..
Of course my project is MUCH more complicated and is printing out a lot of TRACE information to the debugger. Its easy for first-chance exception to get lost in the output.
HOWEVER
That's not my concern. This is clearly an exception Im not handling. Is Windows surreptitiously deciding to handle this for me? Why? If not, why isn't it giving me a blatant pop-up alerting me of the unhandled exception? Such a pop-up could have saved me days of debugging.
This behavior seems consistent between XP/VS 2008 and Win7/VS 2010.
This has been been fixed, to some degree (see below), in Windows 7 SP1.
In article http://support.microsoft.com/kb/976038 you will find mention of a bugfix and explanation how to use it to disable this behaviour. You have to either:
set process options in the registry or
call function SetProcessUserModeExceptionPolicy exported by kernel32.dll
I have verified in Updates in Win7 and WS08R2 SP1.xls that this bugfix is indeed included in Windows 7 Service Pack 1, so all you have to do is to enable it (assuming you are lucky enough to have Windows 7 SP1 already installed).
As for explanation why this has been done, well we can just guess some ill-advised attempt to prevent legacy application from crashing in the name of backwards compatibility.
For the message itself I don't know, but for the error path, this is because the callback comes from the OS. Then the exception returns to the OS and not to your program or to your debugger. It's same on Linux. In this case you can get a strange error. The solution to resolve that is to use a custom interface or an error callback to return the error to your program caller. The same problem also comes in multithreaded apps where the thread is created by the OS and the exceptions are also returned to the OS and not to your program. The OS knows nothing about your exception handlers.
I am using OpenCV 1 to do some image processing, and am confused about the cvSetErrMode function (which is part of CxCore).
OpenCV has three error modes.
Leaf: The program is terminated after the error handler is called.
Parent: The program is not terminated, but the error handler is called.
Silent: Similar to Parent mode, but no error handler is called
At the start of my code, I call cvSetErrMode(CV_ErrModeParent) to switch from the default 'leaf' mode to 'parent' mode so my application is not terminated with an exception/assertion pop up.
Unfortunately 'parent' mode doesn't seem to be working. I still get the message dialog pop up, and my application still terminates.
If I call cvSetErrMode(CV_ErrModeSilent) then it actually goes silent, and no longer quits the application or throws up a dialog... but this also means that I dont know that an error has occurred. In this case, I think the mode is being set correctly.
Has anyone else seem this behaviour before and might be able to recommend a solution?
References:
cvSetErrMode function reference
Open CV Error handling mode reference
I am going to answer my own question, because after some fiddling around I have worked out what happens.
When you switch to 'parent' mode instead of leaf mode, there is an error handler that gets called cvGuiBoxReport(). cvGuiBoxReport() is the default error handler. It seems that even in parent mode, cvGuiBoxReport() still terminates your application! Oops.
So, to get around that you can write your own error handler, and redirect the error to be handled and NOT terminate the application.
An example error handler:
int MyErrorHandler(int status, const char* func_name, const char* err_msg, const char* file_name, int line, void*)
{
std::cerr << "Woohoo, my own custom error handler" << std::endl;
return 0;
}
You can set up parent mode and redirect your error with:
cvSetErrMode(CV_ErrModeParent);
cvRedirectError(MyErrorHandler);
In a week of servers crashing from uploading corrupt or empty images to our image processing server, here are some thoughts on how I solved the intricacies of OpenCV's error handling. We are using V2.2 in a C++ server.
The problem arises in cv::imread() and cv::imdecode() when the image to be loaded is corrupt (or empty). Normally OpenCV just exits the process with with some error messages, not a good idea when you're running a server which should work all the time.
Reviewing the source code at https://code.ros.org/trac/opencv/browser/trunk/opencv/modules/core/include/opencv2/core/core.hpp I ignored the hint in the source comments for cv::setBreakOnError() and discovered the that following pattern works:
cv::setBreakOnError(true); // Can be set globally
...
...
cv::Mat srcImage = cv::imread(filename, 1);
if (!srcImage.data) throw std::exception("bad image");
cv::imread() will now not exit the process, but passes control to your own exception handling, so you can do with it what you like.
Finding this has saved a lot of heartbreak.