From owner-freebsd-mono@freebsd.org Fri May 13 00:34:50 2016 Return-Path: Delivered-To: freebsd-mono@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 556E2B34CF5 for ; Fri, 13 May 2016 00:34:50 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 03EB21BFD for ; Fri, 13 May 2016 00:34:50 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by mail-vk0-x22b.google.com with SMTP id s184so118599051vkb.3 for ; Thu, 12 May 2016 17:34:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=TMfWju24E5ji2EFwCglqqBB2fMpxDyzBR0p6VwD+8so=; b=id9BWg6A+pb6ZOa7hoT55tKSOpSOjBtAISugjR+3InOSrui/s+RdLX059EtgPaVreK eXdgSBlQ698hdN/FPr0iWvHauOcudi7hTtOVdOIKPd9uxVpuznbyyk5AIc9Kq7x2ovgY Wum5Y1rjAdfYef6f7hw3RKlaUSEKw3c6cwx6Iv1R3kyqPmtpgzEI8v4kSKdvrJCjPYul wYVAESQLiqiI//CTU8tSnVnYjdaZAytvA/e3yXh7muCI3Dn/1oCM2jfqIlNHB0M/dGlA 6XD8Aiz3VxMIOjNoIZitvsFHeItna38FjMiayyC7tvkRsa3/qQ+LSGKJIyrChOhJYmlL eJSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=TMfWju24E5ji2EFwCglqqBB2fMpxDyzBR0p6VwD+8so=; b=Ez/ac6KrRP33/MDZ0Z9a1pHctqhzOv7G/3eq83CDIZAKkHtVhEDt1vNllWPceTSit2 xyXF9b59NRaqXeMMhUArInypceE36To/fn6h6Klto4PDHqa2R6ppnUp2Sf8XIrTYY5oN qVRWxcP3WmHih9Z56xLtFoqMbyrxDzHS926e9v3BnKZpRMcuINmwHUosFIpVKPErky+X vqp20qGUKsCgxunrDtqwEYv09ytrNQbBT6BHXny1usypJ9deHwGBh+iTG+mlwEGuvLn8 0LqeFw3jqtoQtjVr+31bj2hFYdW6J+8IiEJ7Js1ho32kN4TtZMFTLJAhDqk6tXZJTm1o rcLQ== X-Gm-Message-State: AOPr4FWP3bn9ii15k+BLs5wTveEOUaL1wxrIbrgQBMit8CltfW5omKRRDrWQHv6J5SlsJylj96eJEi55Qpopsg== MIME-Version: 1.0 X-Received: by 10.31.74.69 with SMTP id x66mr6189764vka.145.1463099688982; Thu, 12 May 2016 17:34:48 -0700 (PDT) Received: by 10.31.61.1 with HTTP; Thu, 12 May 2016 17:34:48 -0700 (PDT) In-Reply-To: References: Date: Thu, 12 May 2016 17:34:48 -0700 Message-ID: Subject: Re: Sonarr/Mono crash with SIGSEGV on 10.3-STABLE From: Russell Haley To: Mark Heppner Cc: Freebsd-mono Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-mono@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mono and C# applications on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2016 00:34:50 -0000 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 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 <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 <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.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 () <0x00032> > at NzbDrone.Common.Composition.Container.Resolve () <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) > <0x001c6> > at NzbDrone.Console.ConsoleApp.Main (string[]) <0x000a2> > at (wrapper runtime-invoke) .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"