I am getting an access violation when my code exits. I am using Qt with Visual Studio 2010. The point where the access violation (0xC0000005) is thrown is on the last bracket, "}" of main. What would cause this?
All the call stack shows is "00d3d6c8()". That's it, nothing else. After web searching I saw some hints that it might be called by using release libraries instead of debug libraries for Qt, but as far as I know I am using the right libraries.
While using the Qt plugin for Visual Studio 2010, you can make a new Qt project, which automatically creates a static variable "ui" with which you can access all the Qt gui elements.
For some reason I had tried to change this to a pointer, and this ended up causing the problem. So I changed it back to a static reference and now my program exits without an access violation. Thanks for the help in the comments!
Related
I am wanting to use Visual Studio's Graphics Diagnostics to debug some shader code, but when I try to "Start Diagnostics", I get an immediate access violation in dxgi.dll. This access violation appears to occur before my program's main function is even entered. I tried adding a Sleep just inside my WinMain function so I could attach a separate debugger, but this code was never hit. I opened one of the DirectX SDK sample programs with the same installation of VS2013 and the Graphics Diagnostics worked fine. I also tried using Graphics Diagnostics on my program on two separate PCs and they both threw the same access violation.
I suspect maybe it has something to do with my project configuration? It seems to be failing to establish a connection between the Graphics Diagnostics debugger and my program before the entry point of my program is called.
Any ideas are much appreciated!
My code is crashing in the Release configuration but not the Debug configuration. It's only doing this as I exit the program as the very last line 'return(0);' executes. I'm working in the Visual Studio development environment and when it crashes, VS studio offers me the option to 'Debug' the code. When I select that, it leads to an error dialog that pops up saying:
Unhandled exception at 0x00007FF851A0512D (msvcp120d.dll) in myapp.exe: 0xC0000005: Access violation reading location 0xFFFFFFFFFFFFFFFF.
When I select to 'break' when this exception occurs, it highlights the following function in the xstring file:
void _Free_proxy()
{ // destroy proxy
typename _Alloc::template rebind<_Container_proxy>::other
_Alproxy;
this->_Orphan_all();
_Alproxy.destroy(this->_Myproxy);
_Alproxy.deallocate(this->_Myproxy, 1);
this->_Myproxy = 0;
}
And, especially, the line '_Alproxy.destroy(this->_Myproxy);' is highlighted as the culprit.
I thought the issue might be that my 'release' code is somehow linking to the 'debug' msvcp120d.dll library since that's highlighted in the 1st dialog that pops up - but that may be just because I start using the VS debugger to ID this problem. But even if that is the problem, I'm uncertain how to tell VS to compile with msvcp120.dll for the Release configuration and msvcp120d.dll for the Debug configuration.
(For the record, I'm generating all my code using the 'Multi-threaded DLL (/MD)' flag in the Release configuration and the 'Multi-threaded Debug DLL (/MDd)' in the Debug configuration)
The kicker is that when the Release version crashes, the process enters a 'suspended' state and I'm unable to fully kill it via task manager. And then I can't even recompile a new Release version without restarting my computer!
I don't know how to isolate this problem. Can anyone advise me on how I might fix this?
Update
The code for this project is quite large - so distilling it to a minimal version that exhibits the same behavior, while usually a valid way to track a bug, would be a pretty big task. I was hoping that there was some method to log the processes and figure out which one is calling msvcp120d.dll #Niall, I generated the dependency graph and it is huge. Without giving away anything proprietary, attached is a global view of the graph.
Dependency graph of entire solution
Is there any tool to track which is calling msvcp120d.dll?
#Niall Thank you! The software at Dependencywalker.com was fantastic. I was able to use it to determine the library causing the problem and track down the error. It turns out that I had previously (months ago, dumbly) set a system path to the debug version of that library. So even though my project was properly directed to link to the release version of the library, at runtime, my executable was linking to the debug version of the *.dll file!
I deleted the path variable and now make sure a copy of the proper *.dll file is in my Release or Debug directory. Then it all runs and shuts down fine.
Thanks to all who provided assistance.
For recent years I've been writing a commercial app with Qt ( from 4.7 to 5.1(now)). And I've been switching between gcc and msvc compiler to test the platform and framework compatibility in casual intervals.
Now, After building the project with Qt5.1-msvc2010 and importing it into the visual studio editor(2013), The project crashes on exit.
After that, I rebuilt and debug it with qtcreator editor but the program crashed on exit again.
This window appears when the project crashes with the qtcreator editor on exit. I assure you there is no "f:\dd" path in my computer!!!
So there is nothing to do with the editors and I think this issue is related to the msvc compiler.
After debugging, it toggles in the destructor of the mainwindow, but there is just "delete ui;".
I'm pretty aware of how a QObject delete their children and I have never delete any GUI component by myself.
This issue confused me since the gcc compiler is more strict than the msvc.
I'll be appreciated for Any guidance or instruction.
Thanks a lot.
It is internal Microsoft CRT (C Run-time Library) code that is generating the error, not your application's code. So the file path ("f:\dd\vctools...") refers to the path of the source file on Microsoft's servers when the debug symbols were created. You aren't going to be able to find it.
What's happening is that the debug version of the CRT contains lots of extra checks, to aid in catching bugs hiding in your programs. In this case, it's detecting an attempt to use an invalid heap pointer (by calling the internal _CrtIsValidHeapPointer function, which is failing).
To fix the problem, you'll need to track down where your code is using the invalid pointer. You can pretty much assume that this error is caused by trying to free/delete memory that is not allocated on the heap. You say that the debugger breaks on the line delete ui;—make sure that ui is actually created on the heap somewhere with new, not automatically created on the stack.
Environment: I have a .NET 4.0 solution that references some Visual C++ projects. Visual Studio 2010.
If I build my solution and run the resulting .exe right from the bin directory, I can reproduce my bug. But if I run it hitting the "play" button in Visual Studio (or if I run the process and attach to it) I can step through the code, and everything works as normal.
For reference, the problem I'm getting is an Access Violation which is most definitely happening the C++ code.
But more broadly, I'm wondering what other reasons there might be that attaching a debugger to a process "fixes" the issue.
MS VS is working like a sandbox. When you are starting app in that sandbox, your program inherits all settings from solution properties (or just VS settings). Make sure, all your options provided for the environment are correct. If that wont solve the problem, please double check those settings and think what can prevent access violation and uncheck/check it.
If you are using external DLL, those from you system and those from IDE may have different version. They, of course, may work in both cases, but also may cause problem like access violation or subcribent out of range, depending what is changed inside those dlls.
If its Windows app, try enabling/disabling LargeAddressAware.
If you are compiling stuff for another machine with different OS, it may happen very often due to changes in memory handling by native OS. Memory can sometimes be multi-blocked, extremely fragmented or even multi-deviced, so compile your program only with compilation especially made for targeted OS/machine
debug mode uses assert() and other stuff directly linked to debugging. If something is wrong in debugging and not in release, it means that it is acceptable by machine but not by debugging insertions. In that case you are screwed but if its not appear to be problem in other debugger, well... problem solved, its debugger issue, espeially if release without debugging options is working.
most tiring method - try to pinpoint access violation address and see inside memory windows to what are you referring.
in other cases, supply us with snippet, so we can tell something more!
#Matt this cant be heap problem, it can happen but its extremely rare.
#Huytard its wont happen, without linked dll's program should't even start.
The correct and short answer. Run Windows Updates.
The correct and long answer.
It turns out my build machine hasn't been updated in a while and was using an outdated version of Visual C++ compiler. There was a bug in the compiler for .NET 4 where static constructors were not getting called first before any other types of constructors (only in Release Mode).
But here's the kicker!
If you run the process in the Visual Studio debugger OR you attach to a remote process. The static constructors DO get called first like they are supposed to! (Hence making the issue completely un-reproducible in a debugging environment -- Even in Release mode) I found the issue by placing message boxes all over the place to determine the code path.
http://connect.microsoft.com/VisualStudio/feedback/details/611716/c-cli-class-static-constructor-not-called-in-release-build
Running the green "play" button will use the IDE's environment
Executing from the directory will use the default environment
My guess is that there are probably some DLL's or dependencies that need to be added (directory paths) to your %PATH% environment variable.
Once you identify the dependencies and double check or something with dependency walker - you can set them in a batch script and then call your application.
For example:
#echo off
set PATH=%PATH%;C:\myLibs
call MyApp.exe
There are a number of errors going on here but I'm sure they are all linked, so first off I'm getting Access violation reading location exceptions at locations (generally near 0x00000000)
but I only get these exceptions in release and not in debug, even if i setup debugging to do so. Also I found where the error happens but when I step over that it goes in to a complete unrelated function that is not called in the line or in any of the functions in that line of code. But when similar code is called it still goes to this unrelated function but doesn't fail. This all only happens in release versions. I know which piece of code is causing the error as if I comment it out its all fine. Also in the watch window in release all the numbers are wrong most of the time, which has never been a problem but it could help also a added some code to it to output the values of variables to a file and the variables are all fine, the pointers are sensible, but when the exception happens it always says their 0x00000020 but when I look at the log they are fine. This is in 32 bit , but on 64 bit windows 7 in c++. Please any help would be good!
Visual Studio's debugger will cause the program to use a debug heap that can hide uninitialized memory if you use the option "Start with Debugging" to start your program, in release or debug. You can try to run your program built in the Debug configuration without the debugger attached, and then use the Attach to Process... option in the debug menu to attach to your executable.
If this doesn't help, I recommend using windbg to debug your program. For help getting started with windbg, take a look at the answers on this question.
Once windbg is configured and symbol paths are set up, you can use the "!analyze -v" option once the program crashes to get a lot of information about the crash automatically.