On Linux, failing to bind the address on Start generates a coredump

[tmds]

When starting Kestrel on a port that is taken an exception is thrown. e.g.:

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

Since this exception is not handled, the runtime calls abort which (normally) generates a coredump (see https://github.com/dotnet/coreclr/issues/17929).

The behavior seems excessive for failing to bind the port. Maybe there should be a try/catch somewhere to turn this into a non-success process exit?
It may not be obvious these coredumps are being generated. And when seeing these dumps on their system, users may get the wrong impression dotnet failed in some bad way.

CC @davidfowl @halter73 @mikem8361

[tmds]

I need to verify if generating the coredumps are default behavior on a Fedora system or whether this is something I configured myself (and forgot about).

[halter73]

Interesting. Unfortunately, not throwing is a breaking change at this point.

[Tratcher]

That try/catch would go in Program.Main, that's where the process lifetime is controlled.

[tmds]

Until last week, I wasn't aware of the coredumps (and I guess probably you weren't either).
The stack (Kestrel/Hosting/template/...) should handle this somewhere in a nicer way.
I think it's fine to improve this post 2.1.

On Fedora, coredumps are enabled by default. The OS also does cleanup to avoid filling the disk.

[tmds]

That try/catch would go in Program.Main, that's where the process lifetime is controlled.

That makes sense. Perhaps it's ok to catch any type of exception and return exitcode 1?
The change would be to update the templates to include a try-catch block in Main?

Can you set a milestone?

[Tratcher]

@davidfowl @DamianEdwards

[DamianEdwards]

I'd be interested to know what other stacks do here. Having specific logic like this in the framework or the template seems wrong due to the (non-destructive) behavior of a single distro. It might be surprsing, but I'm not sure it warrants guarding against.

[muratg]

Moving to discussions based on @DamianEdwards' last comment.

[tmds]

I didn't find time yet to look at other stacks.

due to the (non-destructive) behavior of a single distro

Many distros noop coredumps because their users don't know what to do with them, and they don' t support cleaning them up. That is the distro's choice.

Our choice is whether we end up calling abort or not.
abort is meant for abnormal process termination. This means: the program finds itself in a situation it doesn't know how to handle and terminates immediately. abort is documented to generate coredumps.

imo, we are not in such an abnormal case, the webserver can terminate normally with a non-zero exit code.

[mikem8361]

As far as the runtime’s concerned a unhandled exception is an abnormal process termination. The runtime has always called abort or on Windows TerminateProcess in these cases. All the other distros and Windows don’t generate a core dump by default. /cc: @jkotas

[tmds]

@mikem8361 I'm not sure how you read my comment.

For me, the runtime behaves properly by calling abort when it sees an unhandled exception:

the program finds itself in a situation it doesn't know how to handle and terminates immediately

By

Our choice is whether we end up calling abort or not.

I meant: it is our choice to catch the exception or let it go to the runtime.

[halter73]

Where do you suggest we catch the exception? Do you think that WebHost.Run() should just log and exit gracefully if the server fails to start?

[tmds]

Where do you suggest we catch the exception? Do you think that WebHost.Run() should just log and exit gracefully if the server fails to start?

Yes, a method on WebHost (could be Run or a new one). It should return an int that is used as the return value of Main.

[tmds]

I'd be interested to know what other stacks do here.

When the server is already bound: ruby, node, python show a stacktrace for an unhandled exception and their runtimes call exit with a value of 1.

[tmds]

    public class Program
    {
        public static int Main(string[] args)
        {
            return CreateWebHostBuilder(args).Build().RunMain();
        }

        public static IWebHostBuilder CreateWebHostBuilder(string[] args) =>
            WebHost.CreateDefaultBuilder(args)
                .UseStartup<Startup>();
    }

    public static class WebHostExtensions
    {
        public static int RunMain(this IWebHost host)
        {
            return host.RunMainAsync().GetAwaiter().GetResult();
        }

        public static async Task<int> RunMainAsync(this IWebHost host, CancellationToken token = default)
        {
            try
            {
                await host.RunAsync(token);
                return 0;
            }
            catch
            {
                // Exception is logged by host.
                return 1;
            }
        }
    }

@halter73 this application doesn't terminate when the host throws a bind exception. backtrace looks like the main thread is waiting for the finalizer thread:

(lldb) bt
* thread #1, name = 'dotnet', stop reason = signal SIGSTOP
  * frame #0: 0x00007ffff79c152c libpthread.so.0`__pthread_cond_wait + 508
    frame #1: 0x00007ffff64214e2 libcoreclr.so`CorUnix::CPalSynchronizationManager::ThreadNativeWait(CorUnix::_ThreadNativeWaitData*, unsigned int, CorUnix::ThreadWakeupReason*, unsigned int*) + 354
    frame #2: 0x00007ffff64210c4 libcoreclr.so`CorUnix::CPalSynchronizationManager::BlockThread(CorUnix::CPalThread*, unsigned int, bool, bool, CorUnix::ThreadWakeupReason*, unsigned int*) + 388
    frame #3: 0x00007ffff6425a94 libcoreclr.so`CorUnix::InternalWaitForMultipleObjectsEx(CorUnix::CPalThread*, unsigned int, void* const*, int, unsigned int, int, int) + 1812
    frame #4: 0x00007ffff6425e11 libcoreclr.so`WaitForMultipleObjectsEx + 81
    frame #5: 0x00007ffff609197b libcoreclr.so`Thread::DoAppropriateWaitWorker(int, void**, int, unsigned int, WaitMode) + 1467
    frame #6: 0x00007ffff608c710 libcoreclr.so`Thread::DoAppropriateWait(int, void**, int, unsigned int, WaitMode, PendingSync*) + 80
    frame #7: 0x00007ffff6169d3f libcoreclr.so`CLREventBase::WaitEx(unsigned int, WaitMode, PendingSync*) + 95
    frame #8: 0x00007ffff60fb186 libcoreclr.so`FinalizerThread::FinalizerThreadWatchDogHelper() + 742
    frame #9: 0x00007ffff60fac9f libcoreclr.so`FinalizerThread::FinalizerThreadWatchDog() + 271
    frame #10: 0x00007ffff60c733f libcoreclr.so`EEShutDownHelper(int) + 783
    frame #11: 0x00007ffff60c7bbd libcoreclr.so`EEShutDown(int) + 205
    frame #12: 0x00007ffff6011460 libcoreclr.so`CorHost2::UnloadAppDomain2(unsigned int, int, int*) + 96
    frame #13: 0x00007ffff5fe9d91 libcoreclr.so`coreclr_shutdown_2 + 33
    frame #14: 0x00007ffff67c17f7 libhostpolicy.so`___lldb_unnamed_symbol1549$$libhostpolicy.so + 103
    frame #15: 0x00007ffff67b4370 libhostpolicy.so`___lldb_unnamed_symbol1269$$libhostpolicy.so + 6896
    frame #16: 0x00007ffff67b4b4c libhostpolicy.so`corehost_main + 236
    frame #17: 0x00007ffff6a67cbf libhostfxr.so`___lldb_unnamed_symbol1564$$libhostfxr.so + 207
    frame #18: 0x00007ffff6a7336c libhostfxr.so`___lldb_unnamed_symbol1609$$libhostfxr.so + 5436
    frame #19: 0x00007ffff6a744c5 libhostfxr.so`___lldb_unnamed_symbol1612$$libhostfxr.so + 437
    frame #20: 0x00007ffff6a73a39 libhostfxr.so`___lldb_unnamed_symbol1610$$libhostfxr.so + 1001
    frame #21: 0x00007ffff6a67f0c libhostfxr.so`hostfxr_main_startupinfo + 156
    frame #22: 0x000000000040ac74 dotnet`___lldb_unnamed_symbol30$$dotnet + 1572
    frame #23: 0x000000000040af05 dotnet`___lldb_unnamed_symbol31$$dotnet + 165
    frame #24: 0x00007ffff6cda18b libc.so.6`__libc_start_main + 235
    frame #25: 0x0000000000408a54 dotnet`_start + 41