[Mono-list] mono swallows threadpool exceptions
trampster at gmail.com
Wed Jul 21 06:50:35 EDT 2010
And I found the bug.
Which is over a year old.
This one is not in an obscure part of the framework like my serial
port bug so it should be fixed quickly??
On Wed, Jul 21, 2010 at 10:21 PM, Daniel Hughes <trampster at gmail.com> wrote:
> Ok I think I have it:
> tells us that since .net 2.0 the runtime does not swallow threadpool
> exceptions. So that means that the mono implementation is wrong.
> On Wed, Jul 21, 2010 at 9:51 PM, Daniel Hughes <trampster at gmail.com> wrote:
>> upon further reading this appears to be the correct behavior. Although
>> it does not seem to be what is happening in .net I will need to do
>> more investigation it seems.
>> On Wed, Jul 21, 2010 at 9:16 PM, Daniel Hughes <trampster at gmail.com> wrote:
>>> In trying to port our application to run on mono I have discovered
>>> that mono is silently swallowing exceptions. This is a really big
>>> deal, we expect these exceptions to bubble up and kill the
>>> There is not even any indication that an exception has occurred it is just lost.
>>> public static void Main (string args)
>>> Action action = () =>
>>> throw new Exception("this should Kill the process but doesn't");
>>> ThreadPool.QueueUserWorkItem(_ => action());
>>> Console.WriteLine("wrongly still running");
>>> The implications of this could be catastrophic. Imagine some code
>>> which performs a check, finds bad data and throws an exception.
>>> However mono swallows that exception so instead of the program closing
>>> it carries on running and uses the bad data. This results in sensitive
>>> data being lost. Or in our case a radio being bricked.
>>> Can someone explain why mono is doing this and if their is some
>>> setting / environment variable I can change to make unhandled
>>> threadpool exceptions terminate the process as is expected.
More information about the Mono-list