Leading on from the answer to another question about bugs in the Delphi IDE, does anyone know if there is a way to improve the multi-threaded debugging functionality of the IDE, or if not, at least why it is so bad on occasion?
When you have multiple threads within a program, stepping through the code with F7 or F8 can often lead to either very long pauses, or the whole IDE just locks ups. This is especially apparent when you leave or enter a method or procedure. The debugger always seems to be fine for single threaded applications.
PS. The version I'm using is 2007
From my experience multi threaded debugging is much nicer using Vista and Delphi 2009 than XP with Delphi 2007.
First, the ide is significantly more stable.
Second, in Delphi 2009 on vista the debugger can show you where deadlocks are occurring.
If you have to use Delphi 2007, I would strongly recommend debugging your code in a single threaded unit test if possible, then using your by now tested code in the main program. ;)
When the application itself has not deadlocked, try to be very aware of which thread you're in. Keep the thread list up in the debugger, and consider using named threads.
There are times when it will be impossible to interactively debug an application which itself deadlocks. When this happens, you can use tools such as WinDbg and Adplus in order to work with memory dumps. Yes, this is a lot harder than using the interactive debugger, but it beats having no debugger at all. There are sample applications, demos, and instructions, on Tess Ferrandez's blog. I would start with this page. The labs are .NET-centric, but don't let that keep you away; the ideas are the same.
When I want to debug a multithreaded operation I often use a log file (that I analyse after the application has run) instead of the interactive Debugger.
For example with the function 'OutputDebugString'. The output comes in the event log of Delphi. If you start your program outside of Delphi, you can use DebugView from SysInternals to display the log. Take care to add the Thread-ID to each output (GetCurrentThreadID).
Be aware that there could be a thread switch just before writing to the log. But at places where several threads interact you will probably have a critical session (or another synchronization object) so that it should be a problem.
Yes, debugging a multithreaded application is a hassle. Because you are constantly swapping from one thread to another.
Another Idea that I have never tried because I've just thought about it: if you are interested in debugging one thread and just want to avoid being disturbed by the other threads, it might be possible to suspend some threads temporaly.
Process Explorer from SysInternals offers a possibility to suspend and resume threads (in the tab called "Threads" in the properties of a process). But as I said I've never tested it until now.
Related
I'm designing an application for an asphalt batch mix plant, using a thread to run the mixing process, several timers to read system states and perform control actions.
If "Hyper-Threading" features is disabled, the application will run smoothly, everything is OK; or it will bring up a dialog grumbling that memory access is invalid and abort immediately after click "OK".
Don't know why? Maybe something wrong with IDE version, since Delphi 5 was released at 10th August 1999; maybe the thread unit in Delphi 5.0 cannot deal with new CPU technology?
Maybe memory management has some bugs, maybe the thread mode is not suitable for new era?
I want to upgrade the IDE, but since there are many many years pasted, I have no idea which would be the best choice,
Delphi 7? Delphi 2007(which support OmniThreadLibrary)? RAD Studio XE6/7? Hope someone will help.
The most plausible explanation is that your program has a bug related to threading. You happen to get away with the flaw in your code when hyperthreading is disabled, but enabling it is sufficient to make the error in your code manifest.
Threading bugs are just like this. They will manifest if threads execute specific code in a particular order, with respect to the other threads. And the relative ordering is unpredictable. Which is part and parcel of parallel computation. Code that is broken can appear to be correct when running under one environment, but then fail under another. Whilst it is tempting to blame the tools, always check in the mirror first.
Changing development environment is not the solution. What you need to do is to find and then fix the error in your code. Getting a good stack trace will help, and I can recommend a tool like madExcept for that.
my understanding about debugging process and debuggers is that when a breakpoint gets hit, all other threads gets frozen. However one of my colleague said that this option is configurable meaning that somewhere in Visual Studio options you can configure that other threads (where there is no breakpoint) continue to work as normal although the thread with breakpoint get frozen. I couldn't find any such settings in visual studio plus my colleague does not remember where he saw that setting although he seem pretty confident that this option exists.
Can someone confirm if its even possible to have other threads running while one thread gets frozen due to breakpoint? Also if there is such a setting, please let me know where to find it.
The debugger always freezes all threads when a breakpoint hits. You have however do have control over what happens to threads when you press F5 to continue execution. You can use the Freeze toolbar button available in the Debug + Windows + Threads debugger window to prevent a thread from continuing when you press F5. Use the Thaw button to re-enable it.
I'm not familiar with VS, but I know gdb support non-stop mode since version 7.10, so I think it is possible to do like this with VS.
Here is the summary: "For some multi-threaded targets, GDB supports an optional mode of operation in which you can examine stopped program threads in the debugger while other threads continue to execute freely. This minimizes intrusion when debugging live systems, such as programs where some threads have real-time constraints or must continue to respond to external events. This is referred to as non-stop mode."
You can search 'non-stop gdb' for more details.
I don't know if this is possible but frankly if it is, it shouldn't be. Yes it is theoretically possible to break one thread while the others keep running, but keep in mind that with this there is the potential that one of the running threads will try to interact with the frozen thread. this causes all kinds of problems with your current frozen thread. I suspect the debugger was designed with this in mind, so there isn't a setting that allows this. If someone else knows differently please let me know because i find myself curious as well
Taken as given that multi-threaded applications are debugging hell and should be avoided at all costs...
Is the requirement to display of a progress bar a sufficient reason to enter multi-threaded land?
Specifically, let's say a C# windows forms .NET 3.0 application needs to download a 100MB file. Is it right to multi-thread (via a BackgroundWorker component) to do the download on that thread so that the UI thread is free to update a progress bar showing progress?
Sorry if this question is a bit fuzzy. I've not done anything multi-threaded before.
You have not said anything about what language are you using; in C#, for instance, you could use WebClient with DownloadFileAsync and DownloadProgressChanged
While this is a multi-threaded program, I consider it as low complexity program.
When you're creating a GUI application, the main problem with doing everything on the UI thread, is that it might freeze your application while for example waiting for I/O. So if you don't have anything that might freeze the application for long enough to annoy the user (and that time is very subjective of course), then go ahead with single threaded applications. But otherwise, I guess the question is how much you value the user experience.
What are the possible ways to debug deadlocking threads in a MT program, other than gdb?
On some platforms deadlock detection tools may help you find already observed and not yet observed deadlocks, as well as other bugs.
On Solaris, try LockLint.
On Linux, try Helgrind or DRD.
If you're using POSIX, try investigating PTHREAD_MUTEX_ERRORCHECK.
I've always invested some time into writing or grafting on a flexible logging facility into projects I've worked on, and it always paid off handsomely in turning difficult bugs into easy ones. At the very least, wrapping locking primitives in functions or methods that log before and after logging, and display the object being locked and the thread that's doing the locking always helped me to zero in on the offending thread in a matter of minutes - assuming that the problem can be reproduced at all, of course.
Loading the program under a debugger is actually a pretty limited method of determining what happened once a process deadlocks, since all it can give you is a snapshot of how badly you messed up, rather than a step by step explanation of how you screwed up, which I find a lot more helpful.
Or get the Intel Thread Checker. Fine work.
We have a monitoring application built on swt and running on linux. we have few buttons and a dynamic part that changes as we click on these buttons. The problem is that if some ones click too rapidly the cpu could reach 100% and hanging forever. We observed this rapid cpu spikes only on Ubuntu Linux where as windows it runs without on itch. We are sure that our app does repainting whenever we click (we have dynamic part) the button and that's by design. The problem is not alone with the dynamic part. One solution is to ignore rapid clicks.
We are wondering if we can ignore rapid Button clicks to avoid cpu spiking all the way to 100%. If that doesn't work we may have to redesign the dynamic part which we prefer as last option. suggestions/comments are greatly appreciated.
Another solution is to increase your memory with -Xms512m -Xmx512m
It sounds like the application is simply deadlocking. Are you using threads?
Check to see if the repaint is indeed the root cause of the application hanging. Also check to determine which thread it is in using:
Thread.currentThread()
If it is the main thread, then something is inherently wrong; it could be a problem in Java itself. If it is a thread, make sure that it isn't waiting for another thread to finish synchronizing.
I have the same problem in Ubuntu. But on OpenSuse, it seems a lot better.
Things you can try:
Set the anti alias and advanced option of the GC, like:
gc.setAntialias(SWT.OFF);
gc.setTextAntialias(SWT.OFF);
gc.setAdvanced(false);
And check if you are using the commercial graphic driver (i.e. from NVIDIA or ATI) and not the open source driver.
Try this or use pstack or lsstack. When the app runs a long time (or hangs) is when it's begging you to just take a look and see what it's doing.
Many people have experienced performance problems (i.e. very high CPU consumption) with SWT applications on Gtk+ when updating widgets too often. The actual cause seems to be Gtk+.
Although a bit outdated, here's a throughout explanation of such performance problems.
You could try replacing your SWT components with embedded Swing ones and check whether the problems is still reproducible.