Date: Fri, 13 May 2016 10:22:18 -0400 From: Randy Smith <rsmith4204200@gmail.com> To: Russell Haley <russ.haley@gmail.com> Cc: Freebsd-mono <freebsd-mono@freebsd.org> Subject: Re: Sonarr/Mono crash with SIGSEGV on 10.3-STABLE Message-ID: <CADXsLJwAPS-OY-VZ_gqD1hgdGy-FW4Ja8AChuJbiDaRjACYD1Q@mail.gmail.com> In-Reply-To: <CABx9NuT3mGK72_nSRXv8kk-a5e5O87Z5Y_9dejOoreMNGS303Q@mail.gmail.com> References: <CADXsLJxHSLqJ__0xHBytoOzOJOwXDx3dLq8peeWH8QiSYex=HA@mail.gmail.com> <CABx9NuT3mGK72_nSRXv8kk-a5e5O87Z5Y_9dejOoreMNGS303Q@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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@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@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?CADXsLJwAPS-OY-VZ_gqD1hgdGy-FW4Ja8AChuJbiDaRjACYD1Q>