Is there a way to do something like DebugBreak() where when that function is hit the debugger breaks, but continue running when no debugger is attached?
I have a lua error handler that presents a user-friendly error message when something goes wrong, but if I'm debugging I want to stop execution as soon as I've detected something wrong.
I don't want to set a breakpoint in the debugger UI. I want a line of code that causes the debugger to break so I can share this breakpoint with co-workers.
You can use IsDebuggerPresent to check for an attached debugger, and then conditionally invoke DebugBreak:
if (IsDebuggerPresent()) {
DebugBreak();
}
Related
Well, I am writing a small application using C++, Qt and some libraries. Some computation is executed when hitting a UI button.
Now I found that after around one minute the application exits reproducibly and reliably without any visible reason. The error seems not happen statistically but deterministically. I guess there is some bug triggering the crash but I can not find any hint where/why this is happening.
Honestly I have never seen such a crash during the last decade, normally I get even a small indication what happened.
I am using GCC 11.3, GDB, Qt Creator on Kubuntu 22.10 Linux. I built a debug executeable and run it. This is what I checked:
Run using debugger, Qt creator console says "...app has finished with exit code 0."
Run without debugger, Qt creator console says "...app crashed."
Run on bash it only says "Getötet" (which is german and means "killed")
No error related application console output or dialogs are generated
Logging component (which logs all signals, intercept-able C++ exit calls, Qt output and more) does not log anything unexpected
Application does not exit by main()-return (debugger break-point is not triggered and corresponding log trace isn't generated)
No signal dialog (like SIGTERM and SIGABRT) is shown
No assertion seems to be triggered (would generate output and would halt the debugger)
I enabled break-on-abort but nothing happens
I enabled break-on-C++-exception but nothing happens
I searched my code for exit calls (especially with a return code of 0) but there is no such call.
After all I have no idea how to debug the issue other than cluttering my entire application with debug messages and check for missing prints.
Any idea what could happening here and why I don't get even the slightest indication for the error reason?
Is there a way to track down the issue using GDB?
I will try the exit break-point...
You should set a breakpoint on the exit_group and exit system calls, like so:
(gdb) catch syscall exit_group
(gdb) catch syscall exit
But I have doubts since my logging component is using on_exit() to capture exits.
There are many ways for an application to exit without passing through exit and without executing any on_exit-registered functions.
Here are some:
_exit(0)
syscall(SYS_exit, 0)
syscall(SYS_exit_group, 0)
Ok, solution was pretty easy. It wasn't any leak or memory error. Also it wasn't an exit call of any kind.
Reason was basically an internal buffer that could grow beyond the size of physically installed memory under some circumstances. That triggered the OS' OOM-Killer process.
Problem didn't produce any immediate error indication but it could have been tracked down by monitoring system resources and by checking the kernel log (that contained corresponding "oom-kill" and "oom_reaper" messages).
I making a WinAPI DLL using CLion and debugging via LLDB debugger (inside CLion). So breakpoints work fine, however, if there's uncaught exception in my DLL target process crashes and debugger doesn't break when it does. But if there's exception in the target process, debugger breaks fine. Is there any workaround?
Did you enable breaking on exception in Run menu - View breakpoints window?
this happens to me often and almost always the culpret is that the section marked Disable until hitting the following breakpoint: is set to Any Exception. simply change that value to None and the debugger will break when an exception is thrown.
i have no idea how or why this setting is changing itself to that value but, whenever it does, exception breakpoints stop working.
I'm having some difficulties determining what is causing a process to exit. I have a breakpoint in some shutdown code that I'm debugging, but, after breaking in the debugger at the breakpoint and stepping once, the whole process exits immediately. Every thread reports an exit code of -1 in the output window. There are a large number of threads in the process at that time, and the code base is quite large, making searching for the culprit difficult.
I've tried installing a std::atexit function, but this doesn't get hit. I've also tried overriding SetUnhandledExceptionFilter, in case it is caused by a crash, and it also doesn't get hit. The project has exceptions disabled (#define _HAS_EXCEPTIONS=0), so I cannot call std::set_terminate or std::set_unexpected.
Is there some other way to determine what is causing the process to exit? Some option to break in the debugger when the process is about to terminate?
Run your app with debugger and read the debug output. If the app terminates because C++ exceptions, or SEH, you’ll read it in the output window.
If you’ll see nothing interesting there, it means your app called ExitProcess/ExitThread/exit, or worse, TerminateProcess/TerminateThread/_exit.
You can put breakpoints on these. Set a breakpoint at startup, launch debugger. Ensure you have debug symbols loaded for relevant DLLs, kernel32.dll for ExitProcess and friends, some other DLL for exit, e.g. ucrtbase.dll. Press “New / Function breakpoint” in the Breakpoints window, type e.g. “ExitProcess”, press OK.
You can also try using gflags tool from Windows SDK.
If you’ll find (by reading Windows Logs > Application) the reason was self exit, you can check “Enable dump collection” in gflags, then you’ll be able to load the dump in WinDBG and get the complete call stack telling you who called what.
Unfortunately, the latest version of the tool is broken beyond repair.
But you can install older Windows SDK. You only need “Debugging tools for Windows” from there, no need to install the complete SDK.
Is it possible to break debugging as TRACE(the debugger message output macro) is called, the message from trace appears on output, but I am unable to break the debugger as it does. (Am using visual studio 2003/windows).
I do not have the source code for this application. I'm simply attaching to the process.
Put a breakpoint on one of your TRACE calls. Do whatever you need to do to make it fire. Step In. Put another breakpoint in that code. Remove your first breakpoint.
Edit: Put a breakpoint on the OutputDebugStringW and OutputDebugStringA APIs in kernel32.dll - it's those APIs that the TRACE macro calls.
In the Breakpoints window, go New / Break at Function, and enter _OutputDebugStringW#4. Repeat for _OutputDebugStringA#4.
I have a Windows application written in C++ that occasionally evaporates. I use the word evaporate because there is nothing left behind: no "we're sorry" message from Windows, no crash dump from the Dr. Watson facility...
On the one occasion the crash occurred under the debugger, the debugger did not break---it showed the application still running. When I manually paused execution, I found that my process no longer had any threads.
How can I capture the reason this process is terminating?
You could try using the adplus utility in the windows debugging tool package.
adplus -crash -p yourprocessid
The auto dump tool provides mini dumps for exceptions and a full dump if the application crashes.
If you are using Visual Studio 2003 or later, you should enable the debuggers "First Chance Exception" handler feature by turning on ALL the Debug Exception Break options found under the Debug Menu | Exceptions Dialog. Turn on EVERY option before starting the debug build of the process within the debugger.
By default most of these First Chance Exception handlers in the debugger are turned off, so if Windows or your code throws an exception, the debugger expects your application to handle it.
The First Chance Exception system allows debuggers to intercept EVERY possible exception thrown by the Process and/or System.
http://support.microsoft.com/kb/105675
All the other ideas posted are good.
But it also sounds like the application is calling abort() or terminate().
If you run it in the debugger set a breakpoint on both these methods and exit() just for good measure.
Here is a list of situations that will cause terminate to be called because of exceptions going wrong.
See also:
Why destructor is not called on exception?
This shows that an application will terminate() if an exceptions is not caught. So stick a catch block in main() that reports the error (to a log file) then re-throw.
int main()
{
try
{
// Do your code here.
}
catch(...)
{
// Log Error;
throw; // re-throw the error for the de-bugger.
}
}
Well, the problem is you are getting an access violation. You may want to attach with WinDBG and turn on all of the exception filters. It may still not help - my guess is you are getting memory corruption that isn't throwing an exception.
You may want to look at enabling full pageheap checking
You might also want to check out this older question about heap corruption for some ideas on tools.
The most common cause for this kind of sudden disappearance is a stack overflow, usually caused by some kind of infinite recursion (which may, of course, involve a chain of several functions calling each other).
Is that a possibility in your app?
You could check the Windows Logs in Event Viewer on Windows.
First of all I want to say that I've only a moderate experience on windows development.
After that I think this is a typical case where a log may help.
Normally debugging and logging supply orthogonal info. If your debugger is useless probably the log will help you.
This could be a call to _exit() or some Windows equivalent. Try setting a breakpoint on _exit...
Have you tried PC Lint etc and run it over your code?
Try compiling with maximum warnings
If this is a .NET app - use FX Cop.
Possible causes come to mind.
TerminateProcess()
Stack overflow exception
Exception while handling an exception
The last one in particular results in immediate failure of the application.
The stack overflow - you may get a notification of this, but unlikely.
Drop into the debugger, change all exception notifications to "stop always" rather than "stop if not handled" then do what you do to cause the program failure. The debugger will stop if you get an exception and you can decide if this is the exception you are looking for.
I spent a couple hours trying to dig into this on Visual Studio 2017 running a 64-bit application on Windows 7. I ended up having to set a breakpoint on the RtlReportSilentProcessExit function, which lives in the ntdll.dll file. Just the base function name was enough for Visual Studio to find it.
That said, after I let Visual Studio automatically download symbols for the C standard library, it also automatically stopped on the runtime exception that caused the problem.