I have a seriously nasty bug which I'm not having much uck tracking down. It only manifests itself as the program freezing and windows saying that the program is not responding when I run it without a debugger attached.
When I attach a debugger to the process from within visual studio and step through the code there is nothing untoward, and resuming execution sets the program running again, just fine, no longer frozen.
What type of bug could this possibly be which is dispelled by the very presence of a debugger?
You should look out for any race conditions in your code. Setting breakpoints and stepping through the code might resolve any timing issues where one action has not yet been completed in time, but when you pause the execution, it completes in time.
It might not actually be locked up - it's probably that the code that is executing is running on the same thread as the UI, so it LOOKS like it's locked up. Obviously if you're stepping through the code, you can see that it's actually doing something, but when some process is going on that freezes the UI it often appears to be locked up.
Look for extensive loops or processes that take time to complete, and try running them on a different thread and see if that takes care of it. You can also tell if your app is actually frozen or if it's just running a long process by looking at the CPU usage in the Task Manager.
As a temporary measure, you could try to do something during loops that you suspect may be causing this by doing something to update the UI. For example, in a WinForms application, you can add code to show where you are in the loop by adding a label and modifying the text.
For example:
for (each Employee currentEmployee in myEmployees)
{
lblStatus.Text = "working on " + currentEmployee.FullName;
Application.DoEvents();
}
Updating the UI this way will slow down your app because calls to Application.DoEvents are expensive, BUT it will help to assure your users that the program is not locked up (if you keep it in production) or you could choose to leave it out of the final production version and just use it while developing/testing to see how the processing is going and assure yourself that the app is not locked up.
When I run into an issue where the act of running the debugger seems to change the behavior of my application, I'll fall back to the old sneaker-net debugging method of outputting comments to a file. This will give you great insight into the execution paths of your program and help you to identify where it may be getting stuck.
Sounds like a race condition or deadlock.
The most common affect attaching a debugger has is timing and hence affecting race conditions which exist in the code. This is the first thing I think of when I have a scenario where attaching a debugger changes whether or not the bug reproduces.
Here are a couple of things you can try to work around this problem.
Try launching the process under the debugger vs. attaching
Use WinDbg over Visual Studio. It's a much lighter weight debugger and IME tends to affect the target process less.
One more change in behavior without debugger attached is optimizations are enabled during JIT compile - as result lifetime of variables could be different (smaller) and some objects could be garbage collected earlier (when they are no longer accessible, which could be earlier than end of method). When you attache debugger before JIT happens this optimizations are normally disabled. (see http://naveensrinivasan.com/2010/05/04/net-%e2%80%93-how-can-debugtrue-extend-the-life-time-of-local-variable/)
Advise: Attach debugger AFTER the bug happens and investigate. Collect memory dump and investigate with WinDbg if needed.
Related
I have a complex system with several threads. sometimes i see the application in 100% cpu and force to restart the system. I have no idea which thread caused it and which code caused it.
I need something that will give me the state of each thread in the system (i.e. in which line the thread is now) so i can find which code causes the 100% CPU
(in java you have the thread dump kill -3 which gives you the state of each thread)
Can you help please?
Tess's blog has some great debugging tutorials, including:
.NET Hang Debugging Walkthrough
People have suggested Process Explorer to me before.
You could use the debugger to break and then find out what all threads are doing. (Add the Debug Location toolbar to Visual Studio)
Another option is to remove all thread one by one and find the guilty one.
I have found that in cases like this one of the best tools around these days in Microsoft's intellitrace. This allows for historical debugging & will give you the state of all threads etc. when you break execution.
Unfortunatly its only available in Visual Studio 2010 Ultimate edition, but if this is a really critical issue and you don't have this edition you could always download a 30 day evaluation.
Use VS debugger to attach to your process, and then press the "break" (pause symbol) to break execution. In this state, you can open the Debug window called "Threads" which should give you the state of each thread, and which line they're currently executing. It also helps at this point to give explicit names to your threads when debugging them.
I find that 99% of the time (at least for me) its because I accidentally make a loop infinite when I don't mean to make it so or there should be at least a few milliseconds of sleep before the the loop continues.
You can use profiler like visual vm to better debug the behavior of threads in your application.
How is that setting a breakpoint in my code allows the following code to complete which would fail otherwise.
Here is the problem.
I'm writing an add-on for SAP B1 and encountered following problem.
When I load a form I would like to enter some values into the form' matrix.
But without a breakpoint (set on a method in which loading a form takes place) the part of code that is executed afterward will fail. That part of code is referencing a matrix that is not yet displayed which results in an exception. This is all clear. But why setting a breakpoint "solves" the problem.
What is going on?
I suspect that my breakpoint introduces some delay between loading and displaying my form and part of code that references element of that form but I could be wrong.
Running under the debugger does slow your app and will often hide race conditions even without a breakpoint. When you introduce a breakpoint, it is even more likely to hide race conditions. These kind of problems can be difficult to solve. You might want to introduce some simple logging (e.g. log4net) to see what it is going on without impacting the app so much that you see different behavior. Just keep in mind that even logging can be enough to change things.
Having breakpoints means that every time a module is loaded at runtime Visual Studio scans the module for the positions of possible breakpoints. This must introduce a delay.
Is this a Windows Forms based application? (I'm afraid I know nothing about SAP B1)
Try putting your code into the Load event of the form if it is not already there. Some controls aren't ready to use properly until their handle has been allocated which doesn't happen until the windows message loop has run a few times.
Breakpoints do introduce some delay. A breakpoint is the addition of extra instructions to your programs regular execution. Both hardware and software breakpoints ADD something to the execution of the program (although the amount would widely vary).
http://en.wikipedia.org/wiki/Breakpoint
I've been experiencing a high degree of flicker and UI lag in a small application I've developed to test a component that I've written for one of our applications. Because the flicker and lag was taking place during idle time (when there should--seriously--be nothing going on), I decided to do some investigating. I noticed a few threads in the Threads window that I wasn't aware of (not entirely unexpected), but what caught my eye was one of the threads was set to Highest priority. This thread exists at the time Main() is called, even before any of my code executes. I've discovered that this thread appears to be present in every .NET application I write, even console applications.
Being the daring soul that I am, I decided to freeze the thread and see what happened. The flickering did indeed stop, but I experienced some oddness when it came to doing database interaction (I'm using SQL CE 3.5 SP1). My thought was that this might be the thread that the database is actually running on, but considering it's started at the time the application loads (before any references to the DB) and is present in other, non-database applications, I'm inclined to believe this isn't the case.
Because this thread (like a few others) shows up with no data in the Location column and no Call Stack listed if I switch to it in the debugger while paused, I tried matching the StartAddress property through GetCurrentProcess().Threads for the corresponding thread, but it falls outside all of the currently loaded modules address ranges.
Does anyone have any idea what this thread is, or how I might find out?
Edit
After doing some digging, it looks like the StartAddress is in kernel32.dll (based upon nearby memory contents). This leads me to think that this is just the standard system function used to start the thread, according to this page, which basically puts me back at square one as far as determining where this thread actually comes from. This is further confirmed by the fact that ALL of the threads in this list have the same value for StartAddress, leading me to ask exactly what the purpose is...?
Edit 2
Process Explorer let me to an actually meaningful start address. It looks like it's mscorwks.dll!CreateApplicationContext+0xbbef. This dll is in %WINDOWS%\Microsoft.NET\Framework\v2.0.50, so it looks like it's clearly a runtime assembly. I'm still not sure why
it's Highest priority
it appears to be causing hiccups in my application
You could try using Sysinternals. Process Explorer let's you dig in pretty deep. Right click on the Process to access Properties. Then "Threads" tab. In there, you can see the thread's stack and module.
EDIT:
After asking around some, it seems that your "Highest" priority thread is the Finalizer thread that runs due to a garbage collection. I still don't have a good reason as to why it would constantly keep running. Maybe you have some funky object lifetime behavior going on in your process?
I'm not sure what this is, but if you turn on unmanaged debugging, and set up Visual Studio with the Windows symbol server, you might get some more clues.
Might be the Garbage Collector thread. I noticed it too when I was once investigating a finalizer-related bug. Perhaps your system memory is low and the GC is trying to collect all the time? This was the case in the previously mentioned bug too. I couldn't reproduce it on my machine, but a co-worker of mine had a machine with less RAM where it would reappear like clockwork.
Sometimes, while I am debugging a c# application, I will hit a break point and when I try to continue, step or step into, it just does nothing. The yellow line highlighting the current line goes away, but it never reaches the next line. The app is still frozen like I am on a breakpoint and I can do nothing but hit the stop debugging button and restart. This doesn't happen all the time, but once it starts on an app it seems like it always happens after that for that app. I have found that adding the following code just before the class declaration "fixes" the problem for that app, but am very curious as to why this is happening.
[System.Diagnostics.DebuggerDisplay("Form1")]
Additional details:
I have not noticed any kind of pattern as to what the particular line does when it freezes. Most of the apps I write use threading, so there is a decent chance this is happening within a thread every time.
I've seen stalling problems where the debugger is trying to evaluate the variables shown in the Auto/Local windows. If the evaluation is complicated then it can cause significant stalls.
You can turn the auto-evaluation off through Tools|Options and it does make a big difference.
I have come across with this kind of behavior, though this is my first time.
I have got through this problem, by two ways
Your way of putting this attribute, [System.Diagnostics.DebuggerDisplay("Form1")]
Turning off Tools->Options->Debugging->General->Enable Property evaluation and other implicit function calls.
I am still debugging my code but It seems to me that some of the Autos evaluation is failing (possibly throwing an exception), which is possibly crashing the debugger.
Please let us know if this is also your case.
What sort of code are you debugging?
When you "step into" are you calling your own .NET code, or calling a native library, or an external assembly that you don't have the pdb files for? Either of these situations would cause the debugger to freeze while the external code was executing.
If you debug multithreaded application you might be changing of thread. You can switch between Thread with the "Thread windows" while debugging to be able to see again where the debug yellow line is.
My psychic debugger says that you're missing symbols for something and that VS is hitting the network trying to look them up. Try setting your symbol path to something weird like C:\foo.
dead-lock seems likely in your case. Press the pause button and look at the threads view next time it happens.
I have seen this type of behavior when my DB was being very slow, NHibernate is trying to write to it under the hood, and the whole debugger gets locked randomly when the DB gets pegged.
Other than that I don't know if I can reproduce it now that it's happened (I've been using this particular application for a week or two now without issue), assuming that I'm running my application in the VS debugger, how should I go about debugging a deadlock after it's happened? I thought I might be able to get at call stacks if I paused the program and hence see where the different threads were when it happened, but clicking pause just threw Visual Studio into a deadlock too till I killed my application.
Is there some way other than browsing through my source tree to find potential problems? Is there a way to get at the call stacks once the problem has occured to see where the problem is? Any other tools/tips/tricks that might help?
What you did was the correct way. If Visual Studio also deadlocks, that happens now and then. It's just bad luck, unless there's some other issue.
You don't have to run the application in the debugger in order to debug it. Run the application normally, and if the deadlock happens, you can attach VS later. Ctrl+Alt+P, select the process, choose debugger type and click attach. Using a different set of debugger types might reduce the risk of VS crashing (especially if you don't debug native code)
A deadlock involves 2 or more threads. You probably know the first one (probably your UI thread) since you noticed the deadlock in your application. Now you only need to find the other one. With knowledge of the architecture, it should be easy to find (e.g. what other threads use the same locks, interact with the UI etc)
If VS doesn't work at all, you can always use windbg. Download here: http://www.microsoft.com/whdc/devtools/debugging/default.mspx
I'd try different approaches in the following order:
First, inspect the code to look for thread-safety violations, making sure that your critical regions don't call other functions that will in turn try to lock a critical region.
Use whatever tool you can get your hands on to visualize thread activity, I use an in-house perl script that parses an OS log we made and graphs all the context switches and shows when a thread gets pre-empted.
If you can't find a good tool, do some logging to see the last threads that were running before the deadlock occurred. This will give you a clue as to where the issue might be caused, it helps if the locking mechanisms have unique names, like if an object has it's own thread, create a dedicated semaphore or mutex just to manage that thread.
I hope this helps. Good luck!
You can use different programs like Intel(R) Parallel Inspector:
http://software.intel.com/en-us/intel-parallel-inspector/
Such programs can show you places in your code with potential deadlocks. However you should pay for it, or use it only evaluation period. Don't know if there is any free tools like this.
Just like anywhere, there're no "Silver bullet" tools to catch all the deadlocks. It is all about the sequence in which different threads aquire resources so your job is to find out where the order was violated. Usually Visual Studio or other debugger will provide stack traces and you will be able to find out where the discrepancy is. DevPartner Studio does provide deadlock analysis but last time I've checked there were too many false positives. Some static analysis tools will find some potential deadlocks too.
Other than that it helps to get the architecture straight to enforce resource aquisition order. For example, layering helps to make sure upper level locks are taken before lower ones but beware of callbacks.