Diagnostics.Process on OSX should try harder to provide ProcessName

[JamesWTruher]

It seems like the ProcessName should be more than an empty string. On OSX this is pretty egregious as the first couple 100 processes don't have a name. Providing the path to the executable could be a very reasonable fallback. (or perhaps pbi_name has this already?)

I know that proc id 0 is the exception to this rule, but still ProcessName should be useful.

[danmoseley]

Thanks for the report. Any interest in proposing a PR?

[wfurt]

I did quick check and the output is lame as @JamesWTruher mentioned. It seems like we are failing on

            Interop.libproc.proc_taskallinfo? info = Interop.libproc.GetProcessInfoById(pid);
            if (info.HasValue)

So the problem seems to live deeper in Interop/libproc.

cc: @aik-jahoda

[the-exodus]

I did quick check and the output is lame as @JamesWTruher mentioned. It seems like we are failing on

            Interop.libproc.proc_taskallinfo? info = Interop.libproc.GetProcessInfoById(pid);
            if (info.HasValue)

So the problem seems to live deeper in Interop/libproc.

cc: @aik-jahoda

It seems like you've generated the interop for libproc from really old headers. You need to sudo to get all the task info, and the proc_bsdshortinfo struct (which is what you can fill as low-priv) doesn't seem to be generated.

[aik-jahoda]

@the-exodus I'm not sure what you mean by we are generating interop from old headers. Can you please explain it more? There is no related native code in corefx there is pinvoke only. Are you referring to managed constants and structs definition?

[aik-jahoda]

I tested native proc_pidinfo and proc_name. Both behave the same on the system pids. It requires sudo to be able to obtain the process info.

The proc_name uses proc_pidinfo under the hood and the app should have admin privileges to be able to obtain system process information.

So far the current behavior looks good for me as it respects the OS. The fallback to the path should be implemented on a different layer as a path is not the name.

[the-exodus]

@the-exodus I'm not sure what you mean by we are generating interop from old headers. Can you please explain it more? There is no related native code in corefx there is pinvoke only. Are you referring to managed constants and structs definition?

Sorry, I totally failed at English there. Anyway, I assumed you had generated the type definitions etc from the header files. The proc_bsdshortinfo type was added a few years ago, and since I didn't see it in the corefx-code I assumed you had been using older headers.

The bsdshortinfo doesn't have name, stats, etc, as you can't query that info for other user's processes. It has everything you CAN get though, which is better than the nullref you get after getting access denied :)

[aik-jahoda]

@the-exodus the bsdshortinfo works fine. Thank you for pointing to this API.

[danmoseley]

@aik-jahoda sounds like you have a sketch of a fix?

[aik-jahoda]

I did a c example which demonstrate the functionality. We need to implement C# interop on our side.