NLog makes application crash on Android platform

[snakefoot]

NLog version: 4.7.6
Platform: Xamarin Android / .NET Core 1 / .NET Core 2 / .NET Core 3

• What is the current result? Crashing application
• What is the expected result? Not crashing application
• Are there any workarounds? yes roll back to NLog 4.6.2
• Is there a version in which it did work? NLog 4.6.2

• Can you help us by writing an unit test? Nope

• Please post full exception details (message, stacktrace, inner exceptions)

01-04 08:28:53.788 23347 23407 E CRASH   : managed backtrace:
01-04 08:28:53.788 23347 23407 E CRASH   :       #00 (wrapper managed-to-native) System.Diagnostics.Process:GetModules_internal (System.Diagnostics.Process,intptr)
01-04 08:28:53.788 23347 23407 E CRASH   :       #01 System.Diagnostics.Process:GetModules_internal (Microsoft.Win32.SafeHandles.SafeProcessHandle) <0x4f>
01-04 08:28:53.788 23347 23407 E CRASH   :       #02 System.Diagnostics.Process:get_Modules () <0x53>
01-04 08:28:53.788 23347 23407 E CRASH   :       #03 System.Diagnostics.Process:get_MainModule () <0x43>
01-04 08:28:53.788 23347 23407 E CRASH   :       #04 NLog.Internal.PortableProcessIDHelper:.ctor () <0x7f>
01-04 08:28:53.788 23347 23407 E CRASH   :       #05 NLog.Internal.ProcessIDHelper:Create () <0x1b>
01-04 08:28:53.788 23347 23407 E CRASH   :       #06 NLog.Internal.ProcessIDHelper:get_Instance () <0x27>
01-04 08:28:53.788 23347 23407 E CRASH   :       #07 NLog.Internal.Fakeables.AppEnvironmentWrapper:get_CurrentProcessFilePath () <0xf>
01-04 08:28:53.788 23347 23407 E CRASH   :       #08 NLog.Config.LoggingConfigurationFileLoader/<GetAppSpecificNLogLocations>d__14:MoveNext () <0x16b>
01-04 08:28:53.788 23347 23407 E CRASH   :       #09 NLog.Config.LoggingConfigurationFileLoader/<GetDefaultCandidateConfigFilePaths>d__13:MoveNext () <0x643>
01-04 08:28:53.788 23347 23407 E CRASH   :       #10 NLog.Config.LoggingConfigurationFileLoader:TryLoadFromFilePaths (NLog.LogFactory) <0xcf>
01-04 08:28:53.788 23347 23407 E CRASH   :       #11 NLog.Config.LoggingConfigurationFileLoader:Load (NLog.LogFactory) <0x1b>
01-04 08:28:53.789 23347 23407 E CRASH   :       #12 NLog.Config.LoggingConfigurationWatchableFileLoader:Load (NLog.LogFactory) <0x1b>
01-04 08:28:53.789 23347 23407 E CRASH   :       #13 NLog.LogFactory:get_Configuration () <0xe3>
01-04 08:28:53.789 23347 23407 E CRASH   :       #14 NLog.LogFactory:GetLoggerThreadSafe (string,System.Type) <0x1e7>
01-04 08:28:53.789 23347 23407 E CRASH   :       #15 NLog.LogFactory:GetLogger (string) <0x23>
01-04 08:28:53.789 23347 23407 E CRASH   :       #16 NLog.LogManager:GetCurrentClassLogger () <0x2f>
01-04 08:28:53.789 23347 23407 E CRASH   :       #17 VisualPinball.Unity.TableAuthoring:.cctor () </Users/jmillard/git/vpe/VisualPinball.Engine/VisualPinball.Unity/VisualPinball.Unity/VPT/Table/TableAuthoring.cs:86>
01-04 08:28:53.789 23347 23407 E CRASH   :       #18 (wrapper runtime-invoke) object:runtime_invoke_void (object,intptr,intptr,intptr)

See also: https://github.com/freezy/VisualPinball.Engine/issues/277

Bug introduced with: #3261 (Support autoloading NLog.config on single-file-publish).

[snakefoot]

.NET5 changes the issue, so MainModule is no longer needed to handle single-file-publish:

https://www.hanselman.com/blog/how-do-i-find-which-directory-my-net-core-console-application-was-started-in-or-is-running-from

Not sure how external NLog.config loading works on single-file-publish on Net5. Will it recognize an external Nlog.config if the single-file-image contains its own Nlog.config ?

[snakefoot]

@jsm174 You mentioned that NLog 4.7.6 (Net45 build) is working (doesn't lookup process-path). But I guess NLog 4.7.6 (NetStandard2 build) is failing for you ?

[jsm174]

Correct. I just verified.

[snakefoot]

@jsm174 Could you verify if this call is allowed on the Android platform:

var processName = System.Diagnostics.Process.GetCurrentProcess().ProcessName;

It would be very helpful.

[jsm174]

In a Unity component, I added:

    private void Start()
    {
                var processName = System.Diagnostics.Process.GetCurrentProcess().ProcessName;
                Debug.Log("DUMP: " + processName);

The output is:

➜  2020.2.1f1 ./PlaybackEngines/AndroidPlayer/SDK/platform-tools/adb logcat | grep DUMP
01-04 17:47:47.040  8679  8702 I Unity   : DUMP: /system/bin/app_process32

[snakefoot]

Thank you for the verification. Think I have created something that will allow single-file-publish to work on NetCore3.1, but also not crash application on android-platform. See also #4229

[jsm174]

Okay, I will check it out. Assuming I can grab the artifacts from AppVeyor?

FWIW, I just tried adding the LogManager in the Start() method instead of via the static variable, and it worked:

    private void Start()
    {
                var processName = System.Diagnostics.Process.GetCurrentProcess().ProcessName;
                Debug.Log("DUMP: " + processName);

                Logger testLogger = LogManager.GetCurrentClassLogger();
        testLogger.Info("DUMP: testLogger");  

01-04 17:59:15.667  9873  9897 I Unity   : DUMP: /system/bin/app_process32
01-04 17:59:15.812  9873  9897 I Unity   : VisualPinball: CameraTranslateAndOrbit|DUMP: testLogger

[snakefoot]

NLog will stop "scanning" for configuration-files when meeting the first match. If NLog finds an NLog.config-file in the BaseDirectory, then it will stop scanning (And will never try to check the process-directory).

[snakefoot]

@jsm174 Please check if the pre-release nuget-package here resolves crash-issue:

https://ci.appveyor.com/project/nlog/nlog/builds/37107073/artifacts

[jsm174]

That worked!!

I'm going to double-check one more time just to make sure. 😃

[freezy]

@snakefoot thanks a lot for addressing this so quickly, I'm impressed!

[snakefoot]

Would have been easier if the Android-platform didn't explode in your face, but happy that the work-around (for the work-around) is not that ugly to look at. It is a hard world for those trying to cover up that many things are half-finished (Ex. Single File Publish on NetCore 3.1)

Very grateful for the help with verifying that the pre-release build resolves the issue. Now just need to find a good ETA for the 4.7.7 milestone.

[snakefoot]

Closed by #4229

[snakefoot]

https://www.nuget.org/packages/NLog/4.7.7 has been released