runtime: Unexpected coredumps
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.
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Comments: 16 (16 by maintainers)
.NET Core’s behavior is different from other stacks when it comes to unhandled exceptions.
ruby,node,pythonshow a stacktrace for an unhandled exception and their runtimes call exit with a value of1.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