OSX、Process.Start 上的 Mono 有时会抛出无法处理的本机包装器异常
Mono on OSX, Process.Start sometimes throws native wrapper exception that is unhandleable
所以我在 OSX 上的 Mono 3.12.0 中有一个控制台应用程序 运行。有时,我的意思是,也许每执行 100 次或更多次 CleanupPriorToApplicationStart()
,我就会得到下面的堆栈跟踪,并且调用清理方法的父线程死亡;基本上 Process.Start 必须包装本机代码,并且本机代码会引发异常,至少我认为这是正在发生的事情。但是这个过程仍然存在,所以它不是一个完整的 exit(),这使得很难知道什么时候发生并纠正它。清理方法的日志消息中的异常处理程序永远不会在那里出现,因此无论出于何种原因,单声道运行时都没有将此本机异常包装在 .NET/Mono 异常中,因此可以对其进行处理。这是预期的吗?有没有办法在不删除我的线程的情况下捕捉到这种行为?
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);
}
这是控制台的输出
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:
更新:
由于一些谷歌搜索,我想强调的是,在调用 Cleanup 方法之前,我明确调用了垃圾收集 GC.Collect();
原来垃圾收集绝对是罪魁祸首。我将 CleanupPriorToApplicationStart()
调用移至开始 GC 之前,并且不再看到这些偶发错误。
在我看来像是一个错误。我在 FreeBSD 10.1 上遇到了同样的问题 运行 mono 3.12.1_1。当 GC 在错误的时间发生时,你会再次被咬。
我升级到 mono 4.0.1.28,但无法重现我的问题。
它也可能会解决您的问题。
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.
=================================================================
所以我在 OSX 上的 Mono 3.12.0 中有一个控制台应用程序 运行。有时,我的意思是,也许每执行 100 次或更多次 CleanupPriorToApplicationStart()
,我就会得到下面的堆栈跟踪,并且调用清理方法的父线程死亡;基本上 Process.Start 必须包装本机代码,并且本机代码会引发异常,至少我认为这是正在发生的事情。但是这个过程仍然存在,所以它不是一个完整的 exit(),这使得很难知道什么时候发生并纠正它。清理方法的日志消息中的异常处理程序永远不会在那里出现,因此无论出于何种原因,单声道运行时都没有将此本机异常包装在 .NET/Mono 异常中,因此可以对其进行处理。这是预期的吗?有没有办法在不删除我的线程的情况下捕捉到这种行为?
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);
}
这是控制台的输出
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:
更新:
由于一些谷歌搜索,我想强调的是,在调用 Cleanup 方法之前,我明确调用了垃圾收集 GC.Collect();
原来垃圾收集绝对是罪魁祸首。我将 CleanupPriorToApplicationStart()
调用移至开始 GC 之前,并且不再看到这些偶发错误。
在我看来像是一个错误。我在 FreeBSD 10.1 上遇到了同样的问题 运行 mono 3.12.1_1。当 GC 在错误的时间发生时,你会再次被咬。
我升级到 mono 4.0.1.28,但无法重现我的问题。 它也可能会解决您的问题。
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.
=================================================================