From .NET to Mono - A crash while hammering WinForms

Question

Several years ago, I wrote this Roulette application on .NET 1.1 using C# and Visual Studio.net: http://www.lonniebest.com/Roulette/

Since April of 2007, I've been using Ubuntu Linux exclusively, so today I tried to recompile that old code using the MonoDevelop IDE. To my amazement, the code built fine without errors, and I was able to run this Windows Forms application on Ubuntu.

Everything worked fine (at first), when I would spin the roulette wheel one spin at a time. It would even run fine if I told it to spin it 10 times in a row. However, too much higher (in a row) than that, the applications crashes and all I see in the MonoDevelop's "Application Output" pane is:

The application was terminated by a signal: SIGHUP

(In Visual Studio, I'd expect it to direct me to an unhandled exception in my code, but MonoDevelop only seems to display the above output in the "Application Output" pane.)

This application really hammers Windows Forms, it updates numerous form element over and over again with each spin, as fast as can be rendered. If you run it on the .NET version I posted in the link above, you'll see it update all these form elements 100+ times a second. That may not be necessary, but neither is the application as a whole, and that's what I intend for it to do.

Compiled with Visual Studio, and running on Windows .NET, the applications can do millions of spins without ever crashing.

So, what might allow me to get this code more resilient in Mono/Linux, in light of the "SIGHUP" crash above?

I've attached the MonoDevelop Solution to this bug report: https://bugzilla.novell.com/show_bug.cgi?id=688014

One thing I can say about your Roulette... I sure ain't biased.. :-P — Paulo Santos, Apr 16 '11 at 09:43
Plase file a bug report on the Mono tracker and attach your code. — skolima, Apr 16 '11 at 13:23
Have you used the Moma tool? See http://www.mono-project.com/MoMA — sehe, Apr 16 '11 at 19:42
I'm currently looking at your project. I'm suspecting threading conflicts of UI elements. Update later — sehe, Apr 16 '11 at 22:16

score 2 · Accepted Answer · edited May 23 '17 at 11:56

The following proof of concept shows that this is probably promiscuous use of Windows Forms controls from a non-UI thread. This proof of concept is completely braindead, because I didn't exactly want to find out what lines in your 328-line DisplayResults function were the culprit. You can use the links below to alleviate your situation.

Read on the backgrounds here:

The following patch completely removes the symptoms for me.

diff --git a/Roulette/Roulette.cs b/Roulette/Roulette.cs
index d5ede34..ae098ac 100644
--- a/Roulette/Roulette.cs
+++ b/Roulette/Roulette.cs
@@ -402,6 +402,7 @@ namespace Roulette
                        //
                        // TODO: Add any constructor code after InitializeComponent call
                        //
+                       Application.Idle += (sender, e) => DisplayResultsEx();
                }

                /// <summary>
@@ -5135,6 +5136,11 @@ namespace Roulette

                public void DisplayResults()
                {
+
+               }
+
+               private void DisplayResultsEx()
+               {
                        //Display the current result.
                        lblCurrentResult.Text = m_Wheel1.CurrentResult.Name;

I haven't applied your patch yet, but I intend to late tonight. Thanks for taking the time to pin point this for me. I wish I had your debugging skills.I have no clue how you figured this out, but I Appreciate it! — Lonnie Best, Apr 17 '11 at 20:02
I saw the usage of threads, I saw it fail inside DisplayResults and saw that it accesses UI Controls on non-UI thread. Time to check whether all that is threadsafe (documentation to the rescue) :) — sehe, Apr 17 '11 at 20:10

From .NET to Mono - A crash while hammering WinForms

1 Answers1