Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unable to obtain target process exit code on Linux/Mac with CoreCLR debugging services #43731

Open
gregg-miskelly opened this issue Oct 22, 2020 · 3 comments
Labels
area-Diagnostics-coreclr enhancement Product code improvement that does NOT require public API changes/additions
Milestone

Comments

@gregg-miskelly
Copy link
Contributor

Description

On Linux/Mac the exit code of the target process is obtained through waitpid (Linux docs, Apple docs, PAL code that makes use of it). However, unlike on Windows -- if multiple places in a process are calling waitpid, unless the WNOWAIT flag is used (which doesn't seem to exist OSX), then my understanding is that this will prevent other callers from obtaining the exit code.

The debugging services open a HANDLE to the target process (as expected) through the PAL, which means that they may wind up 'owning' the exit code of the target process, but they don't, at least as far as I know, wind up propagating this exit code to the debugger.

The potential fixes I can think of are:

  1. Add a new 'managed callback' interface with another version of the ExitProcess method which provides the exit code to the debugger if the debugging services were able to obtain it.
    -or-
  2. Make changes to the PAL (ex: new fake access right to indicate that waitpid should be used) and opt-into them with the debugging services to avoid 'owning' the exit code. Thus the calling debugger can reliably use waitpid to obtain the exit code.

Regression?

No, this has never worked on Linux/Mac

@Dotnet-GitSync-Bot Dotnet-GitSync-Bot added area-Diagnostics-coreclr untriaged New issue has not been triaged by the area owner labels Oct 22, 2020
@ghost
Copy link

ghost commented Oct 22, 2020

Tagging subscribers to this area: @tommcdon
See info in area-owners.md if you want to be subscribed.

@tommcdon tommcdon removed the untriaged New issue has not been triaged by the area owner label Oct 26, 2020
@tommcdon tommcdon added this to the 6.0.0 milestone Oct 26, 2020
@tommcdon tommcdon added this to Needs Triage in .NET Core Diagnostics via automation Oct 26, 2020
@pavel-orekhov
Copy link

same problem was in netcoredbg
cc @kfrolov @viewizard

@viewizard
Copy link
Member

Yes, we also faced with this issue and temporary added hook for waitpid in netcoredbg code - https://github.com/Samsung/netcoredbg/blob/0809b8aa1a80c88b35a04106fbfeb9f5be42853e/src/debugger/manageddebugger.cpp#L41-L127

@tommcdon tommcdon added the enhancement Product code improvement that does NOT require public API changes/additions label Dec 9, 2020
@tommcdon tommcdon modified the milestones: 6.0.0, Future Mar 12, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-Diagnostics-coreclr enhancement Product code improvement that does NOT require public API changes/additions
Projects
None yet
Development

No branches or pull requests

5 participants