Date: Thu, 12 May 2016 17:34:48 -0700 From: Russell Haley <russ.haley@gmail.com> To: Mark Heppner <freebsd@markheppner.com> Cc: Freebsd-mono <freebsd-mono@freebsd.org> Subject: Re: Sonarr/Mono crash with SIGSEGV on 10.3-STABLE Message-ID: <CABx9NuT3mGK72_nSRXv8kk-a5e5O87Z5Y_9dejOoreMNGS303Q@mail.gmail.com> In-Reply-To: <CADXsLJxHSLqJ__0xHBytoOzOJOwXDx3dLq8peeWH8QiSYex=HA@mail.gmail.com> References: <CADXsLJxHSLqJ__0xHBytoOzOJOwXDx3dLq8peeWH8QiSYex=HA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Okay, so reading the tea leaves: TinyIOC determines that the system is running against Mono and tries to load NzbDrone.Mono. The class NzbDrone.Mono.RuntimeProvider then blows up in the constructor. The file is here: https://github.com/Sonarr/Sonarr/blob/develop/src/NzbDrone.Mono/MonoRuntimeProvider.cs I see that it's doing something with an NLog logger. (_logger = logger). SO the issue could be: - Something to do with the call to base(serviceProvider, logger) ? - A filewatcher issue? I know there has been/are issues with using the native file watcher component (uses kqueues). In a custom build of MonoDevelop I had to turn off native file watcher and use the "Managed File Watcher". Perhaps in the base constructor NLog is doing something with filewatchers? I have also seen Monodevelop try and copy files from /tmp to another directory. If you are using PC-BSD or (FreeBSD with ZFS), then it blows up because the native "move" doesn't work across different filesystems. I had to write a custom function that caught the exception and then performed an actual copy, then delete style move (yuck!). Upon inspecting the FreeBSD 10.3-RELEASE notes I see that there was a small change made to kqueues, but it doesn't seem significant. I also noted that you stated you were using 10.3-STABLE which is technically still a development branch. Perhaps reviewing the release notes may give you some insight? https://www.freebsd.org/releases/10.3R/relnotes.html My money is on a filewatcher as the culprit. HTH Russ On Thu, May 12, 2016 at 9:15 AM, Mark Heppner <freebsd@markheppner.com> wrote: > I was able to run sonarr-2.0.0.3953 on mono-4.2.3.4 on 10.2-STABLE. After > upgrading to 10.3-STABLE, the program now crashes with this stacktrace: > > > > [Info] Bootstrap: Starting Sonarr - /usr/local/share/sonarr/NzbDrone.exe - > Version 2.0.0.3953 > [Info] AppFolderInfo: Data directory is being overridden to > [/usr/local/sonarr] > Stacktrace: > > at <unknown> <0xffffffff> > at (wrapper managed-to-native) > System.Diagnostics.Process.ProcessName_internal (intptr) <0xffffffff> > at System.Diagnostics.Process.get_ProcessName () <0x00047> > at (wrapper remoting-invoke-with-check) > System.Diagnostics.Process.get_ProcessName () <0xffffffff> > at NzbDrone.Common.EnvironmentInfo.RuntimeInfoBase.InternalIsProduction > () <0x00080> > at NzbDrone.Common.EnvironmentInfo.RuntimeInfoBase..cctor () <0x00010> > at (wrapper runtime-invoke) object.runtime_invoke_void > (object,intptr,intptr,intptr) <0xffffffff> > at <unknown> <0xffffffff> > at NzbDrone.Mono.MonoRuntimeProvider..ctor > (NzbDrone.Common.IServiceProvider,NLog.Logger) <0x00024> > at (wrapper dynamic-method) object.lambda_method > (System.Runtime.CompilerServices.Closure,object[]) <0x0012c> > at TinyIoC.TinyIoCContainer.ConstructType > (System.Type,System.Type,System.Reflection.ConstructorInfo,TinyIoC.NamedParameterOverloads,TinyIoC.ResolveOptions) > <0x0053b> > at TinyIoC.TinyIoCContainer.ConstructType > (System.Type,System.Type,System.Reflection.ConstructorInfo,TinyIoC.ResolveOptions) > <0x0004d> > at TinyIoC.TinyIoCContainer/SingletonFactory.GetObject > (System.Type,TinyIoC.TinyIoCContainer,TinyIoC.NamedParameterOverloads,TinyIoC.ResolveOptions) > <0x0009b> > at TinyIoC.TinyIoCContainer.ResolveInternal > (TinyIoC.TinyIoCContainer/TypeRegistration,TinyIoC.NamedParameterOverloads,TinyIoC.ResolveOptions) > <0x000be> > at TinyIoC.TinyIoCContainer.Resolve (System.Type,string) <0x0007c> > at > NzbDrone.Common.Composition.Container/<>c__DisplayClass4.<CreateSingletonImplementationFactory>b__3 > (TinyIoC.TinyIoCContainer,TinyIoC.NamedParameterOverloads) <0x00066> > at TinyIoC.TinyIoCContainer/DelegateFactory.GetObject > (System.Type,TinyIoC.TinyIoCContainer,TinyIoC.NamedParameterOverloads,TinyIoC.ResolveOptions) > <0x00035> > at TinyIoC.TinyIoCContainer.ResolveInternal > (TinyIoC.TinyIoCContainer/TypeRegistration,TinyIoC.NamedParameterOverloads,TinyIoC.ResolveOptions) > <0x000be> > at TinyIoC.TinyIoCContainer.Resolve (System.Type) <0x0007f> > at TinyIoC.TinyIoCContainer.Resolve<T_REF> () <0x00032> > at NzbDrone.Common.Composition.Container.Resolve<T_REF> () <0x00041> > at NzbDrone.Host.Bootstrap.GetApplicationMode > (NzbDrone.Common.EnvironmentInfo.IStartupContext) <0x000c9> > at NzbDrone.Host.Bootstrap.Start > (NzbDrone.Common.EnvironmentInfo.StartupContext,NzbDrone.Host.IUserAlert,System.Action`1<NzbDrone.Common.Composition.IContainer>) > <0x001c6> > at NzbDrone.Console.ConsoleApp.Main (string[]) <0x000a2> > at (wrapper runtime-invoke) <Module>.runtime_invoke_void_object > (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. > ================================================================= > > > > I confirmed this in Virtualbox by installing 10.2 with the same version of > mono and sonarr listed, started sonarr successfully, then upgraded to 10.3, > and was unable to start sonarr. I reported the issue on the sonarr forums, > but to me, this seems more like an issue with mono on FreeBSD. > _______________________________________________ > freebsd-mono@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-mono > To unsubscribe, send any mail to "freebsd-mono-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CABx9NuT3mGK72_nSRXv8kk-a5e5O87Z5Y_9dejOoreMNGS303Q>