I'm using a 3rd party library that sends an interrupt from a separate thread in the kernel (RHEL 7.9) to an interrupt handler that I am trying to debug. I'm not able to get gdb (in Eclipse 4.11.0, CDT 9.7) to stop in my interrupt handler. I'm not even able to use std::cout to print out anything inside my handler.
The vendor uses Visual Studios and is able to get the debugger to stop in his interrupt handlers but wasn't familiar enough with gdb or Linux to know if it's possible with gdb.
I've been able to get other interrupt handlers from this same library to work but am having trouble with a specific handler that I'd like to step through so that I can figure out why it's not working properly.
Is there some setting or some step that I'm missing so that I can properly walk through my interrupt handler? Maybe a different technique to try to follow along with what is actually going on inside my interrupt handler?
Edit: I've tried using std::cout to print values I'm interested and outputting to a text file but neither have worked.
Related
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.
I'm trying to make an application that handles crashes on its own. I was able to find out how to handle SIGSEGV (How to generate a stacktrace when my gcc C++ app crashes) - but it seems like the OpenCV error handler comes into action whenever something goes wrong.
This causes my custom signal handler to never execute. Any hints on how to get this working?
Edit: this solution works on linux only
It is possible to replace an action. But using the signal function won't do the job.
You have to use sigaction to replace the previous signal handler. Take a look:
http://man7.org/linux/man-pages/man2/sigaction.2.html
I am building an application for Beaglebone Black using Netbeans running on a PC using remote compilation and debug. The debug has been straightforward up to this point, but I am now trying to sort out my serial comms. My serial code uses a signal to indicate data reception, and Netbeans halts my code to inform me of the signal. It offers 3 options: Discard and Continue, Discard and Pause, Forward and Continue. I want none of these! I want no notification of the signal at all, I want it to be handled by my code.
The options in Project Properties/Debug/Signals are to set them to Ignore (the program no longer responds to them) or Catch (pop up an annoying dialog that breaks my comms protocols). Is there is a way to get Netbeans to just carry on running as it ought to?
Background: I am writing a QA automation platform for an API which outputs formatted results to a specified directory. In addition, I have developed a GUI application for analyzing these results. A user may run the second application trying to analyze test results while our automated build system is running the first application modifying / generating new test data. To avoid thrashing, I have each application acquire file locks when making modifications, and releasing them when they are done. Upon normal program termination, if the running application has acquired a lock on the data directory it is released.
Problem: I need to be able to release the aforementioned file locks when either tool exists prematurely (user pressing CTRL-C, user stopping the application in debugger, or due to buggy API / application logic being tested). To handle this, I have implemented a signal handler using sigaction which handles intercepting fatal signals (tested and working), and have implemented a ctrl-c handler via the Win32 function SetConsoleCtrlHandler. However, I cannot seem to find a way to intercept the event of a user pressing the Stop Debugging button in Visual Studio. I assume this event generates something like SIGKILL / SIGSTOP (which cannot be handled through sigaction) but I would also hope there is some std library or Win32 functionality to intercept this event and perform some cleanup. Do you guys know of a way to handle this event or even what exactly this button does to kill a running application?
If you're using boost, you can use boost::interprocess::windows_shared_memory.
It is guaranteed to be released when the process ends.
Boost is just a neat wrapper around the windows API in this case. It wraps the Windows Named Shared Memory API.
To learn a bit more about FreeBSD and *nix systems in general, I'm starting to look at the binaries from the DEFCON 17 Capture The Flag game. Right now, I'm reversing the tucod binary. Here's some possibly useful information on tucod:
tucod: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), for FreeBSD 7.2, dynamically linked (uses shared libs), FreeBSD-style, stripped
Some other possibly useful information gained from some brief static analysis is that tucod binds on port 0xDEAD (cute, eh?) and if you give it a specific password ("HANGEMHIGH!") it will play a game of hang-man with you.
The problem that I'm encountering is that I'm not hitting my breakpoints in gdb. Specifically, the breakpoint that I'm trying to reach is in the code that handles the client connection. Without breakpoints, the code executes as expected. When I set a breakpoint on that code, the child exits (instead of breaking into gdb, as expected). If I set breakpoints before the server forks off the child, I can hit those fine but after hitting "continue" the child does not continue to process my connection (that is, it won't ask me for a password or play hang-man).
Since the daemon forks when it receives a new connection, I try to tell gdb to follow the child with this command:
(gdb) set follow-fork-mode child
But after single-stepping the instructions after the fork, it appears that this isn't working.
I've tried looking for calls to signal, thinking they implemented a custom SIGINT handler (or similar), but the only call to signal that I can see handles SIGCHLD.
My breakpoint in gdb currently looks like this:
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y 0x080497d0
And 0x080497d0 is the address I want to break on in the client processing code.
I'm sort of new to analyzing software on *nix systems and could use some pointers. How else should I go about troubleshooting why GDB will not hit my breakpoints? Or is there something major I'm just overlooking?
There's a torrent available with all of the game binaries for those interested in seeing the binary first-hand.
Look here for the answer. In short, it looks like GDB supports child debug mode only on HP-UX and Linux.