Deadlock problem

Question

Hello i'm having a deadlock problem with the following code. It happens when i call the function getMap(). But i can't reealy see what can cause this.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Drawing;
using System.Drawing.Imaging;
using System.Threading;

using AForge;
using AForge.Imaging;
using AForge.Imaging.Filters;
using AForge.Imaging.Textures;
using AForge.Math.Geometry;

namespace CDIO.Library
{
    public class Polygon
    {
        List<IntPoint> hull;
        public Polygon(List<IntPoint> hull)
        {
            this.hull = hull;
        }

        public bool inPoly(int x, int y)
        {
            int i, j = hull.Count - 1;
            bool oddNodes = false;

            for (i = 0; i < hull.Count; i++)
            {
                if (hull[i].Y < y && hull[j].Y >= y
                || hull[j].Y < y && hull[i].Y >= y)
                {
                    try
                    {
                        if (hull[i].X + (y - hull[i].X) / (hull[j].X - hull[i].X) * (hull[j].X - hull[i].X) < x)
                        {
                            oddNodes = !oddNodes;
                        }
                    }
                    catch (DivideByZeroException e)
                    {
                        if (0 < x)
                        {
                            oddNodes = !oddNodes;
                        }
                    }
                }
                j = i;
            }
            return oddNodes;
        }

        public Rectangle getRectangle()
        {
            int x = -1, y = -1, width = -1, height = -1;
            foreach (IntPoint item in hull)
            {
                if (item.X < x || x == -1)
                    x = item.X;
                if (item.Y < y || y == -1)
                    y = item.Y;


                if (item.X > width || width == -1)
                    width = item.X;
                if (item.Y > height || height == -1)
                    height = item.Y;


            }
            return new Rectangle(x, y, width-x, height-y);
        }

        public Point[] getMap()
        {
            List<Point> points = new List<Point>();
            lock (hull)
            {
                Rectangle rect = getRectangle();
                for (int x = rect.X; x <= rect.X + rect.Width; x++)
                {
                    for (int y = rect.Y; y <= rect.Y + rect.Height; y++)
                    {
                        if (inPoly(x, y))
                            points.Add(new Point(x, y));
                    }
                }
            }
            return points.ToArray();
        }

        public float calculateArea()
        {
            List<IntPoint> list = new List<IntPoint>();
            list.AddRange(hull);
            list.Add(hull[0]);

            float area = 0.0f;
            for (int i = 0; i < hull.Count; i++)
            {
                area += list[i].X * list[i + 1].Y - list[i].Y * list[i + 1].X;
            }
            area = area / 2;
            if (area < 0)
                area = area * -1;
            return area;
        }
    }
}

EDIT: The "using System.Threading;" was just for some debugging ealyer where we made the thead sleep a bit, i just forgot to remove it.

We added the "lock(hull)" to see if it could fix the dead lock, it diden't. Also the program is not runed with multi threading, so that is not the problem.

I have narroed it down to the error accuring in

if (inPoly(x, y))
    points.Add(new Point(x, y));

The error message

The CLR has been unable to transition from COM context 0x1bb7b6b0 to COM context 0x1bb7b900 for 60 seconds. The thread that owns the destination context/apartment is most likely either doing a non pumping wait or processing a very long running operation without pumping Windows messages. This situation generally has a negative performance impact and may even lead to the application becoming non responsive or memory usage accumulating continually over time. To avoid this problem, all single threaded apartment (STA) threads should use pumping wait primitives (such as CoWaitForMultipleHandles) and routinely pump messages during long running operations.

Answer 1

You are locking on the instance "hull" in getMap() and then when you call getRectangle(); you are attempting to enumerate through "hull".

Answer 2

in this msdn article they explain why it's better to define a variable only used in the lock statement. Clearly it avoids a lot of problem of that kind.

Answer 3

It is a Managed Debugging Assistant warning, relating to using COM servers on a thread. One of the features of COM is that it automatically handles threading for components that do not support multi-threading. It automatically marshals a method call from a background thread to the UI thread so that the component isn't used in a thread-unsafe manner. This is completely automatic, you don't write any code yourself to make this happen.

For this to work properly, the UI thread must be idle so that it can execute the method call. The warning tells you that the UI thread has not been idle for a minute, blocking the call. The most likely reason for that is that the UI thread is blocking, waiting for the thread to complete. That will never happen, it is deadlocked. Or it could just have been busy running code for that minute, never getting around to doing its normal duties, like pumping the message loop. It is not pumping the message loop that trips the warning.

This should be readily visible, the main window of your app should be frozen and display the "Not Responding" message in the title bar. When you use Debug + Break All, Debug + Windows + Threads and switch to the UI thread, then look at the call stack, you should see the place where the UI thread is deadlocked. Fix it by not making the UI thread wait on the thread or by avoiding using the COM component on a worker thread. If it is completely inappropriate (shouldn't be) then you can turn off the warning with Debug + Exceptions.

That's the technical explanation for the warning. The boring one is that there was a bug in the RTM version of Visual Studio 2005. Something wrong with the debugger, it tended to trip the MDA while single stepping or inspecting variables. That got fixed in Service Pack 1, be sure to download and install it if you haven't done this yet.