I have a simple Qt program running on Windows XP - its just a data logging program. It reads any data sent to it on the serial port and then it pushes this to the GUI and logs it to a text file.
The thing is, if I run the program for an hour (roughly, sometimes more) it will hang up on me. The GUI locks out and the program stops logging. On the CPU monitor on the performance tab of my task manager, one of my cores always goes straight to 100% when this crash happens and stays there until I close the hung application.
I have literally no experience in diagnosing problems like this - has anyone got any tips on where to start?
Run the application until it freezes and then attach a debugger. Look through the threads and check where each one of them is. This should give some clues on what's going on. For threads that are stopped within framework code an investigation of the call stack should show if your code is involved.
Make sure that you do this on a debug build with all symbols included to get readable results.
Related
My application started life as a c++ Console application in VS2019. Code was provided as part of an SDK. Worked perfect. Great response from the manufacturer USB device. Later, I wanted to graduate is to a GUI application, much as I've been doing in VB and c#. Lo and behold, I managed to reconstruct the application in both Qt and Win32 but I'm running into a situation where the application becomes unresponsive and I have no way to tell what's going on.
In the Console application, I have to execute this code to interface with the device AFTER sending a "TakeMeasurement" command :
if (SDK_SUCCESSFUL(sdkError)) {
printf("\nWaiting for measurement to complete...\n");
while (!isMeasureWait) {
if (isDisConnect) break;
this_thread::sleep_for(chrono::milliseconds(1000));
}
}
This code works like a charm! Ater one or two iteration, the device has completed the measurement and I can get to the data easily.
On the Win32 side, I use the exact same code. Only, once control enters the loop, it never returns.
Any idea how I could diagnose the error? I have the impression that the "timing" is critical, between the exact moment where the Measurement command is initiated to the exact moment the instrument signals that it's done, and the data ready to be picked up.
My naive hypothesis is that, in debug mode on both 'platforms', I must be getting some timing differences? Sadly, I can't get more information from the manufacturer in this regard but I suspect I have a small window of time within which the instrument's response can be acted on? And I begin to suspect that, on Win32, that "time" is too long? Compared to on the Console side?
I was thinking of, perhaps, "measuring" that time, in milliseconds? First, on the Console side, to see what kind of delay "works", and then, to see how the delay compares with the Win32 side.
I may be wasting my time and I sure don't mean to waste yours.
How would I go about getting an idea of time elapsed in a c++ application? I'll take a look around VS2019, they have all kinds of "performance" things that popup at run time?
Any help is appreciated.
I am not sure I completely understand what is going on.
Execution of the thread wait loop was not not the culprit.
I'm not 100% sure but what happens is that, in my 'Export data to CSV TEXT file', if I tried to execute the call to :
SetWindowText(hEditMeasure, wMeasurements);
The application always hung. I placed breakpoints right before the call in the code, to trace execution, and it did not strike me at first but, in VS toolbar, there was a "thread" comboBox? With the value showing = DEVICE.DLL? and to its right, the name of my Export function as the Stackframe. In searching for additional information on the setWindowText function, I came accross the reference to use VM_SETTEXT to send to "different application"? Could it be unknowingly I was sending a message to "another thread", the DLL thread? And that's why it hung? I did not know enough to tell. So I started to move the setWindowText line around, ultimately inside the code that is called by the "Measure" button, and it worked!
I'm not out of the woods yet but I feel I'm making progress. Thank you all for your help and patience.
I am working on a big code base. It is heavily multithreaded.
After running the linux based application for a few hours, in the end, right before reporting, the application silences. It doesn't die, it doesn't crash, it just waits there. Joins, mutexes, condition variables ... any of these can be the culprit.
If it had crashed, I would at least have a chance to find the source using debugger. But this way, I have no clue how to use what tool to find the bug. I can't even post a code sample for you. The only thing that can possibly help is to tap MANY places with cout to get a visual where the application is.
Have you been in such a situation? What do you recommend?
If you're running under Linux then just use gdb to run the program. When the application 'silences', interrupt it with CTRL+C, then type backtrace to see the call stack. With this you will find out the function where your application was blocked.
Incase of linux, gdb will be great help. Another tool that can be of great help is strace (This can also be used where there are problems with program for with source is not readily available because strace does not need recompilation to trace them.)
strace shall intercept/record system calls that are called by a process and also the signals that are received by a process. It will be able to show the order of events and all the return/resumption paths of calls. This can take you almost closer to the area of problem.
iotop, LTTng and Ftrace are few of other tools that be helpful to you in this scenario.
I'm working on debugging a game written in C++ and it recently started hanging on the splash screen when I try to run it in Xcode (in Debug mode). I can't identify any changes in my code that could have caused this, and there aren't any log messages being printed while this hang is happening (something that I know can severely slow down a program). I then opened Instruments and used the time profiler to try and find the source of the problem, but when I ran my program on the time profiler it progressed past the part where it hangs, and ran as expected. Both running and profiling are set to use Debug mode so the build is the same, does anyone know what could possibly cause an issue like this?
More info: I'm using LLVM/Clang as the compiler and LLDB as the debugger. Looking at Activity Monitor during the hang I can see the game is shown as 'not responding' and Xcode is using a lot of CPU activity, despite not printing any log messages etc.. In 'Edit Schemes' the Profile scheme is set to use the Run action's arguments and environment variables.
I'm working on an application that uses multiple threads to process its data. The app is developped in C++ (Intel C++ comp. 9.1) and uses OpenMP. It is a 64 bit app running on Win7.
The problem is that when I run it during day, it runs correctly. But when I run it during night after the screen has been locked, it enters in a forever loop after a few processes.
To be more precise, the app is called many times for different files to process. The calls are done within a batch file (no problem there).
I found that it enters in the forever loop about 2 hours after the lock screen occurs.
I disabled all power saving settings. But nothing changed.
It is not very clear as description but the reason is that I don't have a clue about the source of the problem. I just hope someone among you could have had the same problem (and found a fix!). If you want more details, just let me know.
Any idea? Thanks in advance!
As my tests go on, I installed the same setup (but in release rather than debug version) on another computer. I ran into the same problem after 20 minutes (after the screen lock) with another set of data. I ran the same data on my own computer (which is not locked) and everything was fine.
I'm mystified!
Are you giving a thread priority that is taking control of the application?
Also, I would suggest taking running it through some kind of profiling, such as VTune as it can point out potential odd cases that could be causing an issue for you. (There is a free evaluation that you can try).
I have a real-time program that needs to be operating continuously. When the program is iconned, it seems that it sometimes stops updating and other times will abort when it is restored to the active state. Is there a method of controlling what happens when my program is iconned? I am using Visual Studio 2005.
I'm stealing lothar's comment and presenting it as an answer: You may want to implement your real time program as a windows service. If you need to start and stop it under user control, you can provide a GUI (that does not need to run all the time) to start, pause, continue, and stop the service. As a service, your program is much less likely to be interrupted by the user doing thing on the computer, including things like logging out.