dotnet run - Notify user of segmentation fault

[elfalem]

I have a program that contains a memory access error leading to a segmentation fault in Linux (the actual error occurs in dynamically linked C code).

When I run this program as dotnet MyProgram.dll, a Segmentation fault error is shown. I believe this is printed by the Linux shell.

When I run the same program with dotnet run, it terminates when it reaches the segmentation fault error. However no sort of error message or exception is printed. It would be helpful for debugging if the user is notified somehow of the error.

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[marcpopMSFT]

Moving to runtime as a possible apphost issue

[ghost]

Tagging subscribers to this area: @vitek-karas, @agocke, @VSadov
See info in area-owners.md if you want to be subscribed.

Issue Details

---

I have a program that contains a memory access error leading to a segmentation fault in Linux (the actual error occurs in dynamically linked C code).

When I run this program as dotnet MyProgram.dll, a Segmentation fault error is shown. I believe this is printed by the Linux shell.

When I run the same program with dotnet run, it terminates when it reaches the segmentation fault error. However no sort of error message or exception is printed. It would be helpful for debugging if the user is notified somehow of the error.

Author:	elfalem
Assignees:	-
Labels:	area-Host, untriaged
Milestone:	-

[mangod9]

Moving to host for now since the runtime is correctly bubbling up the seg fault, but dotnet run might not be showing it correctly?

[elinor-fung]

Using just the host/runtime properly shows the error:

• through dotnet: dotnet MyProgram.dll
• through apphost: MyProgram

The issue is only when going through the SDK command:

• dotnet run

It seems like the SDK commands do some redirection for the processes it launches - dotnet run launches a new process for the actual app - either through dotnet or apphost. Maybe the fact that the app is seg-faulting means that redirection doesn't get to showing the error message?

[baronfel]

@elinor-fung do you what stream the segfault is written to?

[elinor-fung]

Hm, apparently it is the shell's standard error, not the program's standard error.

[baronfel]

Interesting - so do you think that to establish correct behavior dotnet run should trap the SIGSEGV signal for the child process and try to replicate it or something? Perhaps we could trap it and print a nicer message, something like:

> dotnet run
The child process crashed with a segmentation fault. You may be able to replicate this failure by running
  dotnet <path to dll> <any other args>
>
    

[KalleOlaviNiemitalo]

Add APIs in .NET Runtime:

 namespace System.Diagnostics {
     public partial class Process {
         // existing APIs
         public int ExitCode { get; }
         public DateTime ExitTime { get; }

+        // WTERMSIG(wstatus), translated if recognized.
+        // As in PosixSignalRegistration, this is either
+        // a negative value for a recognized signal,
+        // or a platform-defined positive value.
+        // Zero if the process did not exit because of a signal,
+        // and always on Windows.
+        public PosixSignal ExitPosixSignal { get; }
+
+        // WCOREDUMP(wstatus).
+        // true if the signal that killed the process
+        // caused a core dump.  Always false on Windows.
+        public bool ExitCoreDumped { get; }
     }
 }

 namespace System.Runtime.InteropServices {
     public static partial class Marshal {
         // existing API
         public static string GetPInvokeErrorMessage(int error);

+        // strsignal.  Named with "description" rather than
+        // "message", for consistency with sigdescr_np.
+        public static string GetSignalDescription(PosixSignal signal);
     }
 }

Then use those in .NET SDK, to make dotnet run detect why the child process terminated, and write the description to stderr in a similar format as shells would.

Somewhat related: dotnet/runtime#63532, dotnet/runtime#59746, dotnet/runtime#50527.

Alternatively, if dotnet run were changed to use POSIX execve to execute the application in the dotnet process (instead of spawning a child process), then the shell would see the exit signal and tell the user about it. But this wouldn't work in dotnet watch.