I have CLion installed with presumably default configuration. I think something is wrong with it, because I can't see exceptions. For example, this code:
int main(){ throw 5; }
Prints only Process finished with exit code 0
Why doesn't it print the exception?
Why does it print 0 instead of 1?
For comparison:
int main(){try { throw 5; } catch(int x) { std::cout << x << '\n'; }}
This prints 5, so it looks like code is correctly run and the exception is correctly thrown. It's just hidden by CLion somehow.
Edit: This is not a duplicate of "not seeing any console output". I made extremely clear in my question that I was indeed seeing console output for prints. My issue concerns exceptions specifically, not console output generally.
In your first piece of code you have not caught the exception, so it is handled by the default handler. You therefore have no control over the return code from the executable. Operation is as expected.
If you would like CLion to display the exception you can configure it to do so. Note that this will only apply when CLion is debugging your executable, outside of CLion your executable will continue to behave as you have already seen.
Go to run then view breakpoints.
Go to exception breakpoints and when any is thrown.
To display the stack trace when the exception is thrown check stack trace
If you would like your program to stop for your intervention, check enabled and when thrown.
Make sure to use Run/Debug and not Run/Run to launch your program.
Related
I am throwing an exception throw std::exception("dummy") (as a test) which is not being caught anywhere.
Without ProcDump attached this immediately crashes the process as it should.
When I attach ProcDump with -e to a debug build, ProcDump properly detects the unhandled exception, creates a crash dump, and exits.
But the program continues executing as if the exception has never been thrown.
I could manually crash the process after ProcDump exits but I really don't like the idea that code continues to run after a crash that is supposed to be fatal even if it is just for a few ms.
What causes this? How can I make sure that my program crashes (and the crash dump properly represents the point of the crash)? Is this an issue with ProcDump or with how I am using it?
Here is a minimal example to reproduce this:
#include <iostream>
int main() {
char c;
std::cin >> c;
if (c == 'e')
throw std::exception("dummy");
std::cout << "clean exit" << std::endl;
return 0;
}
I've tried it with m$ clang-cl and msvc. I've tried every single ProcDump switch even vaguely relevant to my issue in all possible combinations with multiple binaries.
I don't have a good answer, unfortunately. It looks that there is a bug in procdump. You may report it on the Sysinternals forum or contact Mark Russinovich (#markrussinovich) or Andrew Richards (#arichardmsft). I can confirm that it happens when you attach to the process, for example, procdump -e prog. It behaves as expected when you run the app under procdump (procdump.exe -e -x . prog.exe). Procdump runs as a debugger attached to a process, so it might 'swallow' exceptions. Of course, it should not, but the API allows it to do so.
As an alternative, before procdump gets fixed, you may consider using minidumper (I contributed to it in the past). It does not have as many command-line options as procdump, but the -e option works as expected, for example, MiniDumper.exe -ma -e2 12824.
Internally, minidumper has a very similar design to procdump and also implements a debugger engine. Here is the line handling the exception event:
https://github.com/goldshtn/minidumper/blob/master/MiniDumper/Debugger.cs#L106.
Try using the -k option on ProcDump.
There is something strange happening when I try to debug application. Simply the debugger does not stop on breakpoints when I set breakpoints in catch portion of try-catch block.
Here is an example.
try {
throw std::overflow_error("test");
} catch (...) {
qDebug() << "caught"; // HERE, I SET BREAKPOINT ON THIS LINE
}
It prints the "caught" on screen when exception occurs but it does not stop on this line. (If you ever wonder; Yes, I'm building app in Debug mode and running in Debug mode)
Am I suffering from lack of fundamental knowledge about how gdb works? (I mean maybe it does not stop because breakpoints in catch portion does not work)
Any help would be greatly appreciated.
Thanks.
To catch an exception in IDE, you need issue gdb commands directly in gdb console.
Here's link how to get into gdb console in Qt Create IDE:
Accessing gdb console in Qt-Creator
Once you're the type
catch throw
to stop when your program throws an exception or
catch catch
to stop in the catch block.
If you need to catch a specific library exception, read this thread: GDB: How to break when a specific exception type is thrown?
for people using LLDB,
# set on both throw and catch
breakpoint set -E C++ -h true
# or on catch
b __cxa_begin_catch
# or on throw
b __cxa_throw
while will set breakpoints on throw and catch.
#ben sen, I guess any opinization may result in such a behavior. There are many ways how those options can be specified (via environment variables aka CFLAGS or via IDE options to the project), but they all result to some particular -O option given to the compiller command line. Even if nothing is given at all, please check what is the default optimization for your compiller. My proposal would be to explicitely give -O0 to the compiller and check that no other -O options are supplied.
I'm doing c++ at my job for the first time in years and am trying to track down a problem. I wrote code that goes out and enumerates the processes running on a machine and returns performance metrics. My problem is that some sort of unhandled error occurs and in the debug window I get a message saying the program has exited with code 0. Here is the code in the main function
int _tmain(int argc, _TCHAR* argv[])
{
while(nRun == 1)
{
try
{
WriteHeartBeat();
DoProcessLoop(dwTotalRAM, nCheckPause, oPMeter, cFileName, oProcess, oCPUUsage, nProcCount, ddsCaps2, lpDD);
CopyPerfFileToDest(cFileName);
nRun = 1;
tEnd = time(NULL);
}catch(...){
AddToLog("Error in Main Function");
}
}
AddToLog("App Stopped");
return 0;
}
The program runs for a long time but after a while it just comes back saying it exited with code 0 but that "App Stopped" line is never printed into the log. Does anyone know what kind of error I could have or what issue could be occuring? Is that try catch block sufficient enough to catch any error that could occur or is there something else I could do. Any help you could offer would be really appreciated.
EDIT: The log file should get 3 entries from here if it exits correctly. They are "Doing Process Loop" for the the "DoProcessLoop" Function, "Copying File" for the "CopyPerfFileToDest" function and the "App Stopped" if it stops correctly. When I make it stop correctly myself I get all 3 lines, when it is stopping incorrectly I only get "Doing Process Loop" in the log and then it exits with code 0. The error must be in there. I was curious if there is a generic error trap I can do to catch any all errors.
This can happen if one of functions called from _tmain called exit(0):
http://www.cplusplus.com/reference/clibrary/cstdlib/exit/
http://msdn.microsoft.com/en-us/library/6wdz5232.aspx
Sometimes files are not flushed right so if the AddToLog function defers writing to a file right before exit then it might not write out the value. You can debug the program to see if something strange is happening, or add a variable like status and set it in your catch function then return it at the end, so you know based on the value if there was an error.
Try changing the return of addtolog with a boolean and surrounding add to log with:
boolean logged=false;
while(!logged){
logged = AddToLog("App Stopped");
}
This should prevent the program from exiting until "App Stopped" is written, which may be the problem.
I want to program a daemon-manager that takes care that all daemons are running, like so (simplified pseudocode):
void watchMe(filename)
{
while (true)
{
system(filename); //freezes as long as filename runs
//oh, filename must be crashed. Nevermind, will be restarted
}
}
int main()
{
_beginThread(watchMe, "foo.exe");
_beginThread(watchMe, "bar.exe");
}
This part is already working - but now I am facing the problem that when an observed application - say foo.exe - crashes, the corresponding system-call freezes until I confirm this beautiful message box:
This makes the daemon useless.
What I think might be a solution is to make the main() of the observed programs (which I control) "uncrashable" so they are shutting down gracefully without showing this ugly message box.
Like so:
try
{
char *p = NULL;
*p = 123; //nice null pointer exception
}
catch (...)
{
cout << "Caught Exception. Terminating gracefully" << endl;
return 0;
}
But this doesn't work as it still produces this error message:
("Untreated exception ... Write access violation ...")
I've tried SetUnhandledExceptionFilter and all other stuff, but without effect.
Any help would be highly appreciated.
Greets
This seems more like a SEH exception than a C++ exception, and needs to be handled differently, try the following code:
__try
{
char *p = NULL;
*p = 123; //nice null pointer exception
}
__except(GetExceptionCode() == EXCEPTION_ACCESS_VIOLATION ?
EXCEPTION_EXECUTE_HANDLER : EXCEPTION_CONTINUE_SEARCH)
{
cout << "Caught Exception. Terminating gracefully" << endl;
return 0;
}
But thats a remedy and not a cure, you might have better luck running the processes within a sandbox.
You can change the /EHsc to /EHa flag in your compiler command line (Properties/ C/C++ / Code Generation/ Enable C++ exceptions).
See this for a similar question on SO.
You can run the watched process a-synchronously, and use kernel objects to communicate with it. For instance, you can:
Create a named event.
Start the target process.
Wait on the created event
In the target process, when the crash is encountered, open the named event, and set it.
This way, your monitor will continue to run as soon as the crash is encountered in the watched process, even if the watched process has not ended yet.
BTW, you might be able to control the appearance of the first error message using drwtsn32 (or whatever is used in Win7), and I'm not sure, but the second error message might only appear in debug builds. Building in release mode might make it easier for you, though the most important thing, IMHO, is solving the cause of the crashes in the first place - which will be easier in debug builds.
I did this a long time ago (in the 90s, on NT4). I don't expect the principles to have changed.
The basic approach is once you have started the process to inject a DLL that duplicates the functionality of UnhandledExceptionFilter() from KERNEL32.DLL. Rummaging around my old code, I see that I patched GetProcAddress, LoadLibraryA, LoadLibraryW, LoadLibraryExA, LoadLibraryExW and UnhandledExceptionFilter.
The hooking of the LoadLibrary* functions dealt with making sure the patching was present for all modules. The revised GetProcAddress had provide addresses of the patched versions of the functions rather than the KERNEL32.DLL versions.
And, of course, the UnhandledExceptionFilter() replacement does what you want. For example, start a just in time debugger to take a process dump (core dumps are implemented in user mode on NT and successors) and then kill the process.
My implementation had the patched functions implemented with __declspec(naked), and dealt with all the registered by hand because the compiler can destroy the contents of some registers that callers from assembly might not expect to be destroyed.
Of course there was a bunch more detail, but that is the essential outline.
I have a Visual C++ 9 Win32 application that uses a third-party library. When a function from that library is called with a certain set of parameters the program crashes with "exception code 0xC000000D".
I tried to attach Visual Studio debugger - no exceptions are thrown (neither C++ nor structured like access violations) and terminate() is not called either. Still the program just ends silently.
How does it happen that the program just ends abnormally but without stopping in the debugger? How can I localize the problem?
That's STATUS_INVALID_PARAMETER, use WinDbg to track down who threw it (i.e. attach WinDbg, sxe eh then g.
Other answers and comments to the question helped a lot. Here's what I did.
I notices that if I run the program under Visual Studio debugger it just ends silently, but if I run it without debugger it crashes with a message box (usual Windows message box saying that I lost my unsaved data and everyone is sooo sorry).
So I started the program wihtout debugger, let it crash and then - while the message box was still there - attached the debugger and hit "Break". Here's the call stack:
ntdll.dll!_KiFastSystemCallRet#0()
ntdll.dll!_ZwWaitForMultipleObjects#20() + 0xc bytes
kernel32.dll!_WaitForMultipleObjectsEx#20() - 0x48 bytes
kernel32.dll!_WaitForMultipleObjects#16() + 0x18 bytes
faultrep.dll!StartDWException() + 0x5df bytes
faultrep.dll!ReportFault() + 0x533 bytes
kernel32.dll!_UnhandledExceptionFilter#4() + 0x55c bytes
//SomeThirdPartyLibraryFunctionAddress
//SomeThirdPartyLibraryFunctionAddress
//SomeThirdPartyLibraryFunctionAddress
//SomeThirdPartyLibraryFunctionAddress
//OurCodeInvokingThirdPartyLibraryCode
so obviously that's some problem inside the trird-party library. According to MSDN, UnhandledExceptionFilter() is called in fatal situations and clearly the call is done because of some problem in the library code. So we'll try to work the problem out with the library vendor first.
If you don't have source and debugging information for your 3rd party library, you will not be able to step into it with the debugger. As I see it, your choices are;
Put together a simple test case illustrating the crash and send it onto the library developer
Wrap that library function in your own code that checks for illegal parameters and throw an exception / return an error code when they are passed by your own application
Rewrite the parts of the library that do not work or use an alternative
Very difficult to fix code that is provided as object only
Edit You might also be able to exit more gracefully using __try __finally around your main message loop, something like
int CMyApp::Run()
{
__try
{
int i = CWinApp::Run();
m_Exitok = MAGIC_EXIT_NO;
return i;
}
__finally
{
if (m_Exitok != MAGIC_EXIT_NO)
FaultHandler();
}
}