Date: Fri, 13 May 2016 15:32:05 -0400 From: Mark Heppner <freebsd@markheppner.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: <CADXsLJwfiDkD%2BQjgeO6oWeU5Z=9nss8Wr%2BZSmuFSni-SeurxkQ@mail.gmail.com> In-Reply-To: <20160513155754.4534354.1362.6201@gmail.com> References: <CADXsLJxHSLqJ__0xHBytoOzOJOwXDx3dLq8peeWH8QiSYex=HA@mail.gmail.com> <CABx9NuT3mGK72_nSRXv8kk-a5e5O87Z5Y_9dejOoreMNGS303Q@mail.gmail.com> <CADXsLJwAPS-OY-VZ_gqD1hgdGy-FW4Ja8AChuJbiDaRjACYD1Q@mail.gmail.com> <20160513155754.4534354.1362.6201@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
It looks like it happens between revisions 296500 and 297000. That's probably as far as I can narrow it down to since building takes awhile. I'm not sure where to go from this point. Do you know if it's safe to downgrade from the revision I'm at on -STABLE to the -RELEASE version? Thanks for your help, this was my first time using the mailing lists! On Fri, May 13, 2016 at 11:57 AM, Russell Haley <russ.haley@gmail.com> wrote: > This is just of the top of my head, but if you are really keen to find th= e > issue, you can query svn for which files have changed between revisions. > =E2=80=8ENarrow it down and then start diffing files. Author commit notes= will help > too. I don't know svn commands by heart yet. > > I know you didn't ask for it but: this issue is just a bug in my opinion. > If you are really looking for stability tests to run, build 11-CURRENT an= d > test=E2=80=8E. :D > > Cheers > Russ > > Sent from my BlackBerry 10 smartphone on the Koodo network. > *From: *Randy Smith > *Sent: *Friday, May 13, 2016 7:22 AM > *To: *Russell Haley > *Cc: *Freebsd-mono > *Subject: *Re: Sonarr/Mono crash with SIGSEGV on 10.3-STABLE > > 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/MonoRunt= imeProvider.cs >> >> I see that it's doing something with an NLog logger. (_logger =3D 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 () <0x0001= 0> >> > 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.Named= ParameterOverloads,TinyIoC.ResolveOptions) >> > <0x0053b> >> > at TinyIoC.TinyIoCContainer.ConstructType >> > >> (System.Type,System.Type,System.Reflection.ConstructorInfo,TinyIoC.Resol= veOptions) >> > <0x0004d> >> > at TinyIoC.TinyIoCContainer/SingletonFactory.GetObject >> > >> (System.Type,TinyIoC.TinyIoCContainer,TinyIoC.NamedParameterOverloads,Ti= nyIoC.ResolveOptions) >> > <0x0009b> >> > at TinyIoC.TinyIoCContainer.ResolveInternal >> > >> (TinyIoC.TinyIoCContainer/TypeRegistration,TinyIoC.NamedParameterOverloa= ds,TinyIoC.ResolveOptions) >> > <0x000be> >> > at TinyIoC.TinyIoCContainer.Resolve (System.Type,string) <0x0007c> >> > at >> > >> NzbDrone.Common.Composition.Container/<>c__DisplayClass4.<CreateSingleto= nImplementationFactory>b__3 >> > (TinyIoC.TinyIoCContainer,TinyIoC.NamedParameterOverloads) <0x00066> >> > at TinyIoC.TinyIoCContainer/DelegateFactory.GetObject >> > >> (System.Type,TinyIoC.TinyIoCContainer,TinyIoC.NamedParameterOverloads,Ti= nyIoC.ResolveOptions) >> > <0x00035> >> > at TinyIoC.TinyIoCContainer.ResolveInternal >> > >> (TinyIoC.TinyIoCContainer/TypeRegistration,TinyIoC.NamedParameterOverloa= ds,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> >> > >> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> > 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. >> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> > >> > >> > >> > I confirmed this in Virtualbox by installing 10.2 with the same versio= n >> 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?CADXsLJwfiDkD%2BQjgeO6oWeU5Z=9nss8Wr%2BZSmuFSni-SeurxkQ>