From owner-freebsd-mono@freebsd.org  Fri May 13 00:34:50 2016
Return-Path: <owner-freebsd-mono@freebsd.org>
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 <freebsd-mono@mailman.ysv.freebsd.org>;
 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 <freebsd-mono@freebsd.org>; 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 <freebsd-mono@freebsd.org>; 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: <CADXsLJxHSLqJ__0xHBytoOzOJOwXDx3dLq8peeWH8QiSYex=HA@mail.gmail.com>
References: <CADXsLJxHSLqJ__0xHBytoOzOJOwXDx3dLq8peeWH8QiSYex=HA@mail.gmail.com>
Date: Thu, 12 May 2016 17:34:48 -0700
Message-ID: <CABx9NuT3mGK72_nSRXv8kk-a5e5O87Z5Y_9dejOoreMNGS303Q@mail.gmail.com>
Subject: Re: Sonarr/Mono crash with SIGSEGV on 10.3-STABLE
From: Russell Haley <russ.haley@gmail.com>
To: Mark Heppner <freebsd@markheppner.com>
Cc: Freebsd-mono <freebsd-mono@freebsd.org>
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 <freebsd-mono.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-mono>,
 <mailto:freebsd-mono-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-mono/>
List-Post: <mailto:freebsd-mono@freebsd.org>
List-Help: <mailto:freebsd-mono-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-mono>,
 <mailto:freebsd-mono-request@freebsd.org?subject=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 <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"