CODEWITHSUNDEEP
c#multithreadingmacosmonoprocess.start
Richthofen
Richthofen

Reputation: 2086

Mono on OSX, Process.Start sometimes throws native wrapper exception that is unhandleable

So I have a console application running in Mono 3.12.0 on OSX. Occassionally, and I mean, maybe once every 100 or more executions of CleanupPriorToApplicationStart(), I get the stacktrace below and the parent thread that calls the cleanup method dies; basically Process.Start must wrap native code and that native code throws an exception, at least that's what i think is happening. The process stays around though, so its not a full exit(), which makes it really tough to know when this happens and correct it. The Exception handler in the cleanup method's log message never makes it out there, so for whatever reason the mono runtime isn't wrapping this native exception in a .NET/Mono exception so it can be handled. Is this expected? Is there a way to catch this behavior without my thread getting taken out?

    protected override void CleanupPriorToApplicationStart()
    {
        try
        {
            ResetAppleMailDefaultWindowSize();
        }
        catch (Exception ex)
        {
            logger.Warning(ex, "{ApplicationName} Default Window Size reset FAILED with message", ApplicationName);
        }
    }

    private void ResetAppleMailDefaultWindowSize()
    {
        logger.Debug("{0} resetting Default Window Size", ApplicationName);
        var info = new ProcessStartInfo("defaults", " write com.apple.mail 'NSWindow Frame Torn Off Window' '13 630 1024 768 0 0 2560 1417'");

        var p = new Process {StartInfo = info};
        p.Start();
        p.WaitForExit(6.Seconds());

        logger.Debug("{0} Default Window Size reset", ApplicationName);
    }

Here is the output from the console

DEBUG - "Mail" resetting Default Window Size
Stacktrace:

  at <unknown> <0xffffffff>
  at (wrapper managed-to-native) System.Diagnostics.Process.Process_free_internal (System.Diagnostics.Process,intptr) <0xffffffff>
  at System.Diagnostics.Process.Dispose (bool) <0x0013f>
  at System.Diagnostics.Process.Finalize () <0x00018>
  at (wrapper runtime-invoke) object.runtime_invoke_virtual_void__this__ (object,intptr,intptr,intptr) <0xffffffff>

Native stacktrace:

UPDATE:

Because of some googling, i'd like to emphasize that before the Cleanup method is called, I am explicitly calling Garbage Collection GC.Collect();

Upvotes: 4

Views: 280

Answers (2)

LukeSkywalker
LukeSkywalker

Reputation: 341

Looks like a bug to me. I had the same issue running mono 3.12.1_1 on FreeBSD 10.1. You'll get bitten again when GC will happen at the wrong time.

I upgraded to mono 4.0.1.28 and could not reproduce my issue. It might solve your problem too.

Stacktrace:

 at <unknown> <0xffffffff>
 at (wrapper managed-to-native) System.Diagnostics.Process.Process_free_internal (System.Diagnostics.Process,intptr) <0xffffffff>
 at System.Diagnostics.Process.Dispose (bool) <0x00199>
 at System.ComponentModel.Component.Dispose () <0x00018>
 ...
 at (wrapper dynamic-method) object.lambda_method (System.Runtime.CompilerServices.Closure,object,object) <0x00082>
 at ServiceStack.Host.ServiceRunner`1.Execute (ServiceStack.Web.IRequest,object,TRequest) <0x00450>
 at ServiceStack.Host.ServiceRunner`1.Process (ServiceStack.Web.IRequest,object,object) <0x000cc>
 at ServiceStack.Host.ServiceExec`1.Execute (ServiceStack.Web.IRequest,object,object,string) <0x0012a>
 at ServiceStack.Host.ServiceRequestExec`2.Execute (ServiceStack.Web.IRequest,object,object) <0x00076>
 at ServiceStack.Host.ServiceController/<>c__DisplayClass11/<>c__DisplayClass13.<RegisterServiceExecutor>b__10 (ServiceStack.Web.IRequest,object) <0x00040>
 at ServiceStack.Host.ServiceController.ManagedServiceExec (ServiceStack.Host.ServiceExecFn,ServiceStack.IService,ServiceStack.Web.IRequest,object) <0x001c3>
 at ServiceStack.Host.ServiceController/<>c__DisplayClass11.<RegisterServiceExecutor>b__f (ServiceStack.Web.IRequest,object) <0x0023a>
 at ServiceStack.Host.ServiceController.Execute (object,ServiceStack.Web.IRequest) <0x000e2>
 at ServiceStack.HostContext.ExecuteService (object,ServiceStack.Web.IRequest) <0x00076>
 at ServiceStack.Host.Handlers.ServiceStackHandlerBase.ExecuteService (object,ServiceStack.Web.IRequest) <0x00019>
 at ServiceStack.Host.RestHandler.GetResponse (ServiceStack.Web.IRequest,object) <0x00091>
 at ServiceStack.Host.RestHandler.ProcessRequestAsync (ServiceStack.Web.IRequest,ServiceStack.Web.IResponse,string) <0x00729>
 at ServiceStack.AppHostHttpListenerBase.ProcessRequestAsync (System.Net.HttpListenerContext) <0x0030c>
 at ServiceStack.Host.HttpListener.HttpListenerBase.InitTask (System.Net.HttpListenerContext) <0x0008f>
 at ServiceStack.AppSelfHostBase/<>c__DisplayClass2.<ListenerCallback>b__1 () <0x0001e>
 at Amib.Threading.Internal.WorkItemsGroupBase/<>c__DisplayClass1.<QueueWorkItem>b__0 (object) <0x00019>
 at Amib.Threading.Internal.WorkItem.ExecuteWorkItem () <0x00115>
 at Amib.Threading.Internal.WorkItem.Execute () <0x00065>
 at Amib.Threading.SmartThreadPool.ExecuteWorkItem (Amib.Threading.Internal.WorkItem) <0x000af>
 at Amib.Threading.SmartThreadPool.ProcessQueuedItems () <0x006aa>
 at System.Threading.Thread.StartInternal () <0x0007e>
 at (wrapper runtime-invoke) object.runtime_invoke_void__this__ (object,intptr,intptr,intptr) <0xffffffff>
...
=================================================================
Got a SIGSEGV while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.
=================================================================

Upvotes: 1

Richthofen
Richthofen

Reputation: 2086

It turns out Garbage Collection was definitely the culprit. I moved my CleanupPriorToApplicationStart() call to before I started the GC and have no longer seen these sporadic errors.

Upvotes: 0

Related Questions