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.
Related
I set Qt Creator to break when a C++ exception is thrown:
I then tested it with this code:
try {
throw std::runtime_error("error");
} catch (std::exception &e) {
qDebug("%s", e.what());
}
But it didn't break on throw std::runtime_error("error");. I'm using CDB, not GDB, because I'm using the MSVC Kit.
Edit: There is another question where CDB is working for the OP, even if slowly. So it should work in principle. My configuration is: Qt Creator 3.3.0, compiling with Qt4/MSVC 9.0 (x86), the debugger is CDB 6.2.9200.16384.
Edit 2: This is what I'm getting in the CDB log window (I made a diff between the CDB log with and without the breakpoint):
<bu100400 CxxThrowException
<!qtcreatorcdbext.breakpoints -t 1 -v
<!qtcreatorcdbext.pid -t 2
dATTEMPT SYNC
d*** Bp expression 'CxxThrowException' contains symbols not qualified with module name.
1 breakpoint(s) pending...
*** Unable to resolve unqualified symbol in Bp expression 'CxxThrowException' from module 'C:\Windows\WinSxS\x86_microsoft.windows.common-controls_6595b64144ccf1df_5.82.7601.18201_none_ec80f00e8593ece5\comctl32.dll'.
Full CDB log (in case needed): http://pastebin.com/jhNRy9bE
Edit 3: #HansPassant's explained why it fails in the comments:
Keep in mind that you are using a very old version of MSVC++, big changes at VS2012. The pastebin shows it being out of sync pretty badly, never getting to the DLL that contains __CxxThrowException#8 (MSVCR90D.dll) before the exception is thrown. It is simple with the sxe debugger command, automatic break when any exception is thrown.. Maybe you shouldn't be using QT's UI at all, it looks too gimpy. – Hans Passant 10 hours ago
Just look at the trace, the debugger shows what DLLs it is searching for "CxxThrowException". It never gets to msvcr90d.dll. And the exception is thrown while it is searching for the symbol after which it all ends. Completely out of sync. – Hans Passant 56 mins ago
I'll just write up why this is going wrong, a workaround is going to be difficult to find. The debugger trace in your pastebin tells the tale.
The basic issue is that the communication between the debugger and the QT front-end is rather poor. And in your case it gets out of sync, QT doesn't wait long enough for the debugger to complete the command. QT tries to set a breakpoint on the msvcr90d.dll!__CxxThrowException#8 function, the one that raises a C++ exception in the Microsoft CRT. This function can be present in more than one executable file if the program uses multiple CRTs. A pretty common mishap, caused by building with /MT. And sometimes intentional if you use a well-isolated DLL that you interface with by using COM.
This takes a while as you might imagine, the complaint in the linked question, the debugger has to plow through the symbol information for every DLL that's loaded. It will take especially long if the PDB for the DLL needs to be downloaded from the symbol server and doesn't otherwise get cached so it is available the next time you debug. Not your issue afaict, it does setup the cache location to C:\Users\sasho\AppData\Local\Temp\symbolcache. Go have a look-see to verify that you do see PDBs for the operating system DLLs there.
This operation is tricky, the debugger doesn't give a good signal that it is done searching the DLLs. What the QT should do is verify the debugger feedback against the list of DLLs it obtained. It does not do that, it issues the g command before the debugger is done searching. Could be a timeout that is too short but it actually looks like QT doesn't count on the debugger performing this command in the background. A convenience to a human, not exactly very helpful here :)
There ought to be a way to configure CDB to not perform this search in the background. This is well-hidden, I don't see anything in the debugger.chm help file but it probably wasn't updated in a while. Google doesn't help either. I'd recommend you ask a question about it. Most significantly perhaps is that you have a rather major mismatch in version numbers. The compiler you use is 2008 vintage, the debugger is quite new, SDK 8.0 version, I can't tell what QT version you use.
So a possible workaround is to intentionally use an older version of CDB, one that's more likely to have been tested with the QT front-end version you use. Download the corresponding SDK version, version 6.0 matches the VS2008 time frame. I think the "Debugging Tools for Windows" was still a separate download back then and not yet included in the SDK. Another workaround is to stop relying on the friendly QT front-end and learn to drive CDB from the command prompt. Moderately more useful is WINDBG, uses the same debugging engine but has a GUI interface. Just moderate, it is still mostly prompt driven. You do lose several days of your life learning the commands however. Getting the debugger to break when an exception is thrown is trivial, use the sxe command.
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
I compiled a program using freeglut, optix, cuda and other libraries (some of them dinamically loaded). It compiles and runs without problems in Visual Studio but it crashes if I execute it outside Visual Studio. Both release and debug versions work within VS, they both crash without any information on Windows 8 if I try to execute them directly.
I already included all the necessary DLLs, that didn't work.
What could be the problem?
Most such observations are usually coming from undefined behavior -- using uninitialized variable, dangling pointers/refs, overrunning buffer.
You may try to use Application Verifier, with some luck it might rearrange the used memory enough for you to trigger the problem under debug to help corner it.
Also, when it crashes you should get a prompt to launch VS and inspect the problem -- did it not indicate a hint? What was the immediate cause of the crash and what you had on the call stack there?
You can try comparing the environments between visual studio and the default environment.
Dependency walker should identify any missing DLLs.
Get WinDBG, then File > Open Executable and run the program under WinDBG. When it crashes, you will get some more information. My answer here describes an issue in .net, but the concept applies to native C++ as well.
Visual studio runs executables under "debug" mode, meaning a debugger is present.
What does this mean? If you check out the msvcrt implementation, if the runtime detects a debugger is present (IsDebuggerPresent), then heaps preform differently.
What does this mean? It means buffer sizes are "nudged" upwards, it means memory allocations are wiped clean by default (no need to memset), etc.
This can cause a variety of bugs to manifest, or some more subtle bugs to be hidden.
c++ program terminated with no exceptions or stacktrace
I have a multi threaded application
If one of my threads has an access violation with reading out of bounds on an array (or any seg fault condition) my entire application immediately terminates.
If this happens on my windows counter part using visual studio I get a nice stacktrace of where the error was, and what the issue was.
I desperately need this type of debugging environment to be able to succeed at my project. I have too many threads and too many developers running different parts of the project to have one person not handle an exception properly and it destroys the entire project.
I am running Fedora Core 14
I am compiling with gcc 4.5.1
gdb is fedora 7.2-16.fc14
My IDE is eclipse Juno I am using the CDT builder
my toolchain is the cross GCC and my builder is the CDT Internal Builder
Is there ANY setting for the gdb or gcc or eclipse that will help me detect these type of situations?
That's what's supposed to happen. Under Unix, you get a full
core dump (which you can examine in the debugger), provided
you've authorized them. (ulimits -c—traditionally, they
were authorized by default, but Linux seems to have changed
this.)
Of course, to get any useful information from the core dump,
you'll need to have compiled the code with symbol information,
and not stripped it later. (On the other hand, you can copy the
core dump from your users machine onto your development machine,
and see what happened there.)
You're definitely looking for core dumps, as James Kanze wrote.
I would just add that core dumps will show you where the program crashed, which is not necessarily the same place as where the problem (memory corruption etc.) occurred. And of course some out-of-bounds reads/writes may not exhibit themselves by crashing immediately.
You can narrow the search by enabling check for incorrect memory allocations/deallocations in glibc. The simplest way is to set environmental variable MALLOC_CHECK_. Set it to 2 and glibc will check for heap corruption with every memory allocation/deallocation and abort the program when it founds any problem (producing a core dump, if enabled). This often helps to get closer to the real problem.
http://www.gnu.org/software/libc/manual/html_node/Heap-Consistency-Checking.html
I'm trying to generate a release build for a C++ application that I've written. The application runs fine (debug & release) when you run it from within VS2008; but when you run the executable it crashes nearly every single time.
Now, is there a hack so I can run this application as a standalone application without having to run through all of the code and finding the bug that is causing it?
Thanks in advance.
In short, no.
you will have to find the bug, if it works within VS, then I'd hazard a guess that it is a timing issue, possibly you're overwriting shared thread data, this would be less likely (though still possible to see) inside VS as its being run in a debug environment which slows it down a bit.
If you want help finding your bug, then tell us more. Otherwise, build your release with debug symbols (pdbs), install DrWatson as the system debugger and run it standalone. When it crashes DrWatson will create a minidump file, load this into WinDbg (my favourite) and you'll be able to see exactly where your bug is (it'll even tell you that the dump contains an exception and show you it by default. You need to add your source code path and path to your symbols in WinDbg to get it to do this correctly).
Then you will also know how to diagnose crashes when the app is run on-site too.
Are you loading external resources? If you are check that your relative paths are correct in the C++ program.
One possibility is that your program uses uninitialized heap data. Launching a program from the debugger enables the NT debug heap, which causes the heap allocator to fill new memory blocks with a fill pattern, and also enables some heap checking. Launching the same program from outside the debugger leaves the NT debug heap disabled, but if the program was linked against the debug version of the C runtime, then the CRT debug heap will still be enabled.
A much less likely possibility is that your program requires SeDebugPrivilege to be set in its process token. The debugger enables this privilege in its process token, which has the side effect that all programs launched from the debugger inherit this privilege. If your program tries to use OpenProcess()/ReadProcessMemory()/WriteProcessMemory() and doesn't handle errors correctly, it's conceivable that it could crash.
There are a few possibilities. Besides what has already been mentioned, running an app from Visual Studio will execute in the same security context as the Visual Studio instance. So if, for instance, you are working on Vista, you might be hitting an unhandled security violation if you're trying to access protected files, or the registry.
What if you build a debug version and run it standalone? Does it crash? If so, you can usually break into the debugger from there and get a call stack to see what the malfunction is.
From the details you've given, it sounds like there may be a library issue. Are you running the program on the same computer? If not then you'll also have to deploy the appropriate libraries for your application. If you are running on the same computer but outside of the dev environment, ensure that your application can see the appropriate libraries.
Best way i have found to debug in release is to create a crash dump when an crash happens and the dump then allows me to load debug symbols on my dev computer and find out whats going on. More info here: http://www.debuginfo.com/articles/effminidumps.html
You can also go to file => open in Visual Studio and open the .exe, so you are not starting it under the debugger per se. Not sure if it will help.
http://blogs.msdn.com/saraford/archive/2008/08/21/did-you-know-you-can-debug-an-executable-that-isn-t-a-part-of-a-visual-studio-project-without-using-tools-attach-to-process-296.aspx