Unexpected coredumps

[tmds]

I notice my system was creating coredumps for .NET Core processes.

Repro:

using System;

namespace console
{
    class Program
    {
        static void Main(string[] args)
        {
            throw new Exception();
        }
    }
}

Running this will cause a coredump (abort called).

Stack trace of thread 5943:
#0  0x00007fd3108cb660 raise (libc.so.6)
dotnet/coreclr#1  0x00007fd3108ccc41 abort (libc.so.6)
dotnet/coreclr#2  0x00007fd30fe1101c PROCAbort (libcoreclr.so)
dotnet/coreclr#3  0x00007fd30fe0fe2b _ZL14PROCEndProcessPvji (libcoreclr.so)
dotnet/coreclr#4  0x00007fd30fb5c3d8 _Z27UnwindManagedExceptionPass1R16PAL_SEHExceptionP8_CONTEXT (libcoreclr.so)
dotnet/coreclr#5  0x00007fd30fb5c563 _Z24DispatchManagedExceptionR16PAL_SEHExceptionb (libcoreclr.so)
dotnet/coreclr#6  0x00007fd30facc135 _Z8IL_ThrowP6Object (libcoreclr.so)
dotnet/coreclr#7  0x00007fd2969304ce n/a (n/a)
dotnet/coreclr#8  0x00007fd30fb68ff3 CallDescrWorkerInternal (libcoreclr.so)
dotnet/coreclr#9  0x00007fd30fa7817c _ZN18MethodDescCallSite16CallTargetWorkerEPKmPmi (libcoreclr.so)
dotnet/coreclr#10 0x00007fd30fb8b714 _Z7RunMainP10MethodDescsPiPP8PtrArray (libcoreclr.so)
dotnet/coreclr#11 0x00007fd30fb8b9a1 _ZN8Assembly17ExecuteMainMethodEPP8PtrArrayi (libcoreclr.so)
dotnet/coreclr#12 0x00007fd30f9b4922 _ZN8CorHost215ExecuteAssemblyEjPKDsiPS1_Pj (libcoreclr.so)
dotnet/coreclr#13 0x00007fd30f98d6e2 coreclr_execute_assembly (libcoreclr.so)
dotnet/coreclr#14 0x00007fd31039d706 _ZN7coreclr16execute_assemblyEPvjiPPKcS2_Pj (libhostpolicy.so)
dotnet/coreclr#15 0x00007fd310392fb5 _Z3runRK11arguments_t (libhostpolicy.so)
dotnet/coreclr#16 0x00007fd310393656 corehost_main (libhostpolicy.so)
dotnet/coreclr#17 0x00007fd310661d8f _Z11execute_appRKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEP15corehost_init_tiPPKc (libhostfxr.so)
dotnet/coreclr#18 0x00007fd31066bd16 _ZN10fx_muxer_t23read_config_and_executeERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES7_RKSt13unordered_mapIS5_St6vectorIS5_SaIS5_EESt4hashIS5_ESt8equal_toIS5_ESaISt4pairIS6_SB_EEEiPPKc11host_mode_t (libhostfxr.so)
dotnet/coreclr#19 0x00007fd31066ad1d _ZN10fx_muxer_t22parse_args_and_executeERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES7_iiPPKcb11host_mode_tPb (libhostfxr.so)
dotnet/coreclr#20 0x00007fd31066c3a0 _ZN10fx_muxer_t7executeEiPPKc (libhostfxr.so)
dotnet/coreclr#21 0x00007fd310661e15 hostfxr_main (libhostfxr.so)
dotnet/coreclr#22 0x000000000040fd38 _Z3runiPPKc (dotnet)
dotnet/coreclr#23 0x000000000040fec5 main (dotnet)
dotnet/coreclr#24 0x00007fd3108b7f2a __libc_start_main (libc.so.6)
dotnet/runtime#3858 0x000000000040db8a _start (dotnet)

I didn't expect this program to generate a coredump.

[mikedn]

I didn't expect this program to generate a coredump.

Hmm, why not? The program basically crashed due to an unhandled exception.

[tmds]

The program basically crashed due to an unhandled exception.

I understand the rationale for having coredumps for unhandled exceptions.

I noticed these coredumps while doing some ASP.NET Core stuff. When I forgot to close the previous app, the new one would crash with an exception:

System.IO.IOException: Failed to bind to address https://127.0.0.1:5001: address already in use

and generate a coredump because the exception is unhandled.

CC @davidfowl

[mikem8361]

Yes, the runtime is behaving exactly as designed. An unhandled managed exception will call abort() generating a core dump if enabled.

[mikem8361]

Maybe this issue is more about an specific part of .NET Core (i.e. ASP.NET) and maybe it needs a try/catch somewhere.

[tmds]

Maybe this issue is more about an specific part of .NET Core (i.e. ASP.NET) and maybe it needs a try/catch somewhere.

I'll create an issue in the appropriate repo.

Yes, the runtime is behaving exactly as designed. An unhandled managed exception will call abort() generating a core dump if enabled.

I understand the rationale, still the behavior came as a surprise. I think it's worth mentioning this explicitly in the docs.

How does Windows behave in this case? Is there some event logged? Coredump created? Is there a way to control this?

[mikem8361]

Whether a core dump is generated is dependent on your Linux configuration. Usually you have to explicitly add something like this to /etc/sysctl.conf kernel.core_uses_pid = 1 kernel.core_pattern = /tmp/core-%e-%s-%u-%g-%p-%t fs.suid_dumpable = 2 run “sudo sysctl -p” and then in the shell the app is run in run “ulimit -c unlimited”. Once Linux is configurated to generate dumps any program or app (not just .NET Core app) that executes a abort() will generate a core dump. FYI, .NET Core does have it’s own mechanism to generate mini-dump like core dumps automatically but it is also completely opt-in: https://github.com/dotnet/coreclr/blob/master/Documentation/botr/xplat-minidump-generation.md On Windows, generating a mini-dump depends also on how it and WER is configured (I don’t know the details though).

[tmds]

I need to check if Fedora generates coredumps by default or if this is something I configured (and forgot about). I'll do a clean install in a VM somewhere next week.

[danmoseley]

Seems we can close this @tmds?

[tmds]

@danmosemsft I don't think it's desirable to have coredumps by default, so I want to check the behavior on Fedora. I think we should also cover this in official docs (if it isn't already). For ASP.NET Core behavior, I've created a separate issue.

[tmds]

On Fedora, coredumps are enabled by default. The OS also automatically removes old coredumps to save disk space.

It's important we improve the docs so devs know how .NET Core behaves in case of unhandled exceptions.

[mikedn]

@tommcdon You probably meant to assign @mikem8361 😁

[tmds]

Based on what I said earlier, I think this can be converted to a 'documentation' issue.
Does someone have a suggestion on where to document this?
I'm happy to contribute/review the documentation.

[tmds]

.NET Core's behavior is different from other stacks when it comes to unhandled exceptions.
ruby, node, python show a stacktrace for an unhandled exception and their runtimes call exit with a value of 1.

I understand the rationale for calling abort on unhandled exceptions.
Maybe we should make this opt-in on non-Windows platforms (using an envvar) and behave similar to the other stacks by default.

@mikem8361 wdyt?

CC @halter73

[mikem8361]

.NET Core uses abort() (or TerminateProcess on Windows) when an unhandled exception occurs which is consistent behavior access all our supported platforms. It is just that the Fedora Linux distro has a default default (or your Fedora configuration does) whether is generates a core dump or not. We support 10 other Linux distros/versions that most of them don't. We obviously can't change the default now after releasing 1.x, 2.0 and 2.1 with this behavior.

Adding an environment var for just this distro doesn't seem like solution when you can turn off core dump generation in Fedora just as easy as "ulimit -c 0". Also, the Fedora 28 docker image we use for building doesn't seem to have the /etc/sysctl.conf set to generate dumps so I think it is how your fedora VM is configured by default.

/cc: @janvorli , @jkotas

[tmds]

Fedora uses systemd-coredump to manage coredumps. It is the default configuration. Maybe other distos are also using this or considering to adopt it.

How the platform behaves for unhandled exceptions sets an expectation for the developers. With the current behavior, devs should catch exceptions and convert them to non-zero exit codes. The asp.net core templates are not doing this and probably that is not exceptional.
With the other platforms, the developers get this by default.

[tmds]

I'm closing this because this is not likely to change.

Given this issue, I'm a fan of the System.CommandLine UseExceptionHandler which provides a way of converting Exceptions to non-zero exit codes: https://github.com/dotnet/command-line-api/blob/a58aa11718049db7a9e49a65cd52db4bfb42e38f/src/System.CommandLine/Invocation/InvocationExtensions.cs#L134.