Sonarr/Mono crash with SIGSEGV on 10.3-STABLE

[Randy Smith]

I just checked with a copy of 10.3-RELEASE and it works fine. The version
of 10.3-STABLE I'm on is r298222 (April 18), so I guess I can at least
narrow it down between those two revisions of 10.3. From what I can tell,
10.3-RELEASE was copied from stable/10 at 296371, correct? How can I further
narrow down which revision the problem started at? Should I just try
different versions of the stable branch until I find where it happens? If
it helps, I've been testing this with FreeBSD, using ZFS.

On Thu, May 12, 2016 at 8:34 PM, Russell Haley <russ.haley at gmail.com> wrote:

> 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 at 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 at freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-mono
> > To unsubscribe, send any mail to "freebsd-mono-unsubscribe at freebsd.org"
>