Debugging multitheaded programs - c++

I have been a C programmer for many years and my favorite "debugger" has always been the printf() function - I only resort to visual studio's debugger when absolutely forced and so have never been very proficient in using it. Recently I have had to modify a program from C to C++ (although of course printf still works fine) and and parts of the program are now farmed out in to multiple threads (one for each core on a multicore machine) to make the program run faster. Now i will no doubt come up against awkward multi-thread related bugs like deadlocks and I wonder what debugging methodology I can turn to. Does visual studio (2008) have everything I could reasonably need to help me resolve thread related bugs? Should I take some time out now to learn how to use some third party debugger? Could I solve most problems using my good old printf?
Could I for example write code which, if kept waiting on entry to a critical section would print something like "Thread X waiting to enter ... but blocked because its being used by thread Y"?

Visual Studio supports thread debugging to some extend. Via the Threads Window you can select threads, suspend and resume threads etc. When you switch between threads the Call Stack Window is updated accordingly so you can inspect what each thread is doing. You may also restrict breakpoints to specific threads.
If you want an alternative WinDbg (which is part of the free Debugging Tools for Windows package from Microsoft) offers lots of options as well but with a slightly more esoteric user interface.
As for using printf, there's the problem of synchronizing output. If you don't do it you output will most likely be gibberish. If you do synchronize it you basically change the concurrency of the application, which may or may not affect the problem you're trying to solve.

If you could port your project to Linux, Valgrind (especially the 'helgrind' tool) would do exactly what you ask. http://valgrind.org/

I'm not sure if this is exactly what you are asking, but, To help in debugging, you can write code that gives each thread a "name", so that debug messages printed to the debug window, (or a log file or whatever) include that thread "name" along with whatever other info you prescribe. The code below is in C# but this is available even in unmanaged C++
Thread T = new Thread(RunSchedule);
T.Name = "Scheduler"; // <=== Thread given a name here...
T.Start();

Intel provides several tools to find out threading-related issues: data races, deadlocks, performance penalties. These tools are: Intel Thread Checker, Intel Thread Profiler.

Related

How to freeze a thread in VSCode during C++ debugging

I've been using VSCode to coding for months. It's really awesome! However, I found I'm not able to freeze one thread. All I can do is Pause(all threads) and Continue(all threads). Without freezing a specific thread, it's difficult to debug a multi-threaded program, especially some bugs that will only occur with a particular order.
Does VSCode have this feature in C++ debugging?

stepping through program with debugger takes a long time

When I debug my program by stepping through it, it sometimes takes a long time for the step to finish. This was not happening in the beginning of the project so most likely it is due to something I have added. Could you give me pointers as to how to remedy this. I did notice one of the problems was due to the main thread trying to paint a widget. My application is multi-threaded (1 background thread and 1 main thread) so I am wondering if it has something to do with that. Your comments are appreciated.
With gdb just set scheduler-locking mode to desired behaviour.
In this case: "The step mode optimizes for single-stepping. It stops other threads from "seizing the prompt" by preempting the current thread while you are stepping. Other threads will only rarely (or never) get a chance to run when you step."
A guess: Is your "background thread" pegged at near 100% CPU utilization?
Between lines of of your main thread, while stepping, the debugger is going to allow the background thread to also "step". If the background thread is pegged it can be running a lot more than a few instructions, causing things to appear unresponsive.
Probably if your second thread is doing that much computation continuously it indicates you've got another problem in your application that you need to fix. If you get that thread under control you will probably see your debugger handling things a lot better.
I asked a very similar question regarding visual studio: VS2010 debugger takes an unreasonable amount of time
No real answer came about. You'll find similar questions for past versions of the IDE here as well.

Getting user input in C++ without halting the program

I have a C++ program that captures videos, and I would like to be able create a command-line program to update its frame rate, image format, etc on the fly.
How can I do this without halting the entire program? I need it to be able to wait for user input, but still capture videos at the same time. I know this will probably involve some kind of multi-threading, which I am entirely new to. Some suggestions/links would be nice.
Than you all,
Are you developing this for a specific platform or does it need to be platform independent?
If you are developing for windows you should look into the win32 API. specifically beginthread or _beginthreadex on msdn
I'm not too familiar with *nix development but pthreads i believe would do the trick and can be used in Windows and *nix
Another option would be to use the BOOST libraries. BOOST can be used on Windows and *nix systems. Below is a link to the BOOST Thread documentation.
http://www.boost.org/doc/libs/1_44_0/doc/html/thread.html
I find BOOST Threads a lot easier to use than WIN32 Threads and at the same time you're not tied down to a specific platforms API.
Create a thread to handle video, whilst using the main thread to wait for input. Thread creation depends on platform, and can be a little overwhelming to those who are new. You will need a mutex on variables that can be altered through the command line, and you'll need to look up of how to make your code "thread safe".
In the days before multi-threading it was possible to solve this as well by regularly peeking into the keyboard buffer from time to time. I mention this just as an alternative to opening the multi-threading box which often gives you more than you bargain for.
EDIT: I read now a bit more carefully what you want to achieve, having a console program to update another program with new settings. I think what you then need is for the programs to communicate with one another. Look at boost::interprocess for that.

Waiting with a crash for a debugger?

When an assert fails or there is a segmentation fault, it would be very convenient that one of the following happens:
Program ask whether to run a debugger.
Program waits with crashing until debugger is attached.
Program leaves something (core dump?) that we can resume execution from this point and investigate.
The question is quite general due to variety of platforms, languages and debuggers.
I'm asking about C++ and I guess that Windows (VS), Linux (gdb), Mac (gdb?) solutions would be most useful for community. I'm interested in Linux + gdb.
On Linux (and probably OSX and other unixen), you can allow programs to leave a coredump with the ulimit utility.
Here's a quick howto.
On Windows there is DebugBreak() (and IsDebuggerPresent()), which is one of the options of what can happen when an assert fails.
On MacOS there are similar API calls (Debugger() or SysBreak()).
I don't know much about Linux, but AFAIK a failed assertion on Linux will cause a coredump, which can be looked at in the debugger.
On Linux, Basically when something horrible happens, your program receives a signal, There is a default behavior for the program if you do not 'mask' this signal, but you can usually 'mask' it to do something else, such as opening the gdb. You can find how to mask and a lot more from here, specifically here.
Regarding the assert, you can easily create your own version of assert, to do whatever you want.
Unfortunately, my response only extends to Windows but it would make sense that Linux would also have some way to signal a debugger.
Any machine with Visual Studio installed on it should have Just in Time debugging enabled. This essentially means that the debugger does not have to be running when a process encounters a fatal exception.
Just in Time debugging is enabled through a registry key. Check out the link above for additional details.
If your looking to capture a process snap, for review later, then this is generally accomplished via Adplus.vbs (attended) or DebugDiag (unattended). Adplus is available through the Debugging Toolkit for Windows, but DebugDiag is a separate download.
Additionally to ulimit suggested by gnud, it could be a good idea to use a crash reporter: http://code.google.com/p/google-breakpad/w/list
I've implemented such a functionality as a LD_PRELOADable library in https://github.com/l29ah/waitgdb
Basically it handles debug-worthy signals and stops the process sending it SIGSTOP so you can attach your debugger later.

Debugging multithreaded applications [duplicate]

This question already has answers here:
Analyzing Multithreaded Programs [closed]
(7 answers)
Closed 9 years ago.
I have an application written in C++ and MFC which is multithreaded running on windows. Occasionally I do get some complaints such as deadlocks or an unhandled exception which is caused because of these threads. Normally I use visual studio (if the problem is reproducible) or else use the WinDbg to analyse the dump files generated. Is there any better way of doing this? Can I use some other tools to do this?
I would recommend the Intel Thread Checker if you have enough budget for it. It does a great job of analysing running programs and alerting you to possible race conditions.
Check out the demonstration video for more info.
I haven't gotten to use it yet, but the Relacy Race Detector sounds pretty useful for tracking down some classes of threading issues.
If you're deadlocking on CRITICAL_SECTIONs, you can use the !locks debugger extension in WinDbg to find out which thread owns a held lock, then use the kb command to look at that thread's callstack.
Multithreaded system are complex and location of blockages is not made only with appropriate tools. To find the cause of the deadlock you can put a record of the lock / unlock in a table map. When starting an "action lock" you save in the table, when unlock ocours delete the record from the table. At the end of a cycle you can log the state of the table or expect a particular event to do this.
Build this implementation in a dll, so you can use it in other projects too.