Get modules information using proc_pidinfo() on macOS #42900
Conversation
|
Tagging subscribers to this area: @tommcdon |
k15tfu
force-pushed
the
fix-issue-42888
branch
from
00572d4
to
f75b25d
Compare
|
The changes look good. I'm sure the changes will fix your issues, but I don't know enough about proc_pidinfo yet to know if it will break our existing scenarios (other MacOS versions, devices etc.). I want to wait a little while to approve and merge until 5.0 is finished and out the door. And maybe our CI tests will get more stable though you will have to rebase on the latest master to get any fixes. |
Previously CreateProcessModules() parsed the output of vmmap command to get modules addresses/paths on macOS, but on some Macs with latest macOS 10.15.6 vmmap hides full paths to some process modules (.dylibs in non-system folders), replacing some parts with *: ``` __TEXT 000000010d8bd000-000000010ddce000 [ 5188K 5188K 0K 0K] r-x/rwx SM=COW /Users/USER/*/libcoreclr.dylib ``` In particular, it breaks the debugger functionality due to invalid path `/Users/USER/*/libmscordbi.dylib`, and error code CORDBG_E_DEBUG_COMPONENT_MISSING is returned. Now we get modules information by iterating over regions using proc_pidinfo() in CreateProcessModules(). Fixes dotnet#42888
k15tfu
force-pushed
the
fix-issue-42888
branch
from
f75b25d
to
0e4f0a3
Compare
|
@mikem8361 Hi! Glad to hear this will be included in 5.0 =) I have just rebased against TOT to see if tests pass now. And would it also be possible to backport this to 3.1? |
|
Actually it won't make it into 5.0. It is too risky change right now (weeks before we release 5.0). We will have to see about 3.1/5.0 service releases. |
|
@mikem8361 Oops, I misread this. 5.0.x still sounds good :) |
|
Hi @mikem8361. Thanks for approving this. So how I can help to get this fixed in 3.1/5.0 service releases? |
|
It may be awhile before anything goes into 5.0 servicing. We are still trying to finish 5.0. For 3.1, the it may also be some time before I can go though all our internal servicing processes. The servicing bar is pretty high.
/cc: @tom McDonald<mailto:Thomas.McDonald@microsoft.com>
|
|
@mikem8361 Kindly reminder. |
|
+1 |
|
/backport to release/5.0 |
|
Started backporting to release/5.0: https://github.com/dotnet/runtime/actions/runs/366608110 |
ghost
locked as resolved and limited conversation to collaborators
Previously CreateProcessModules() parsed the output of vmmap command to get
modules addresses/paths on macOS, but on some Macs with latest macOS 10.15.6
vmmap hides full paths to some process modules (.dylibs in non-system folders),
replacing some parts with *:
In particular, it breaks the debugger functionality due to invalid path
/Users/USER/*/libmscordbi.dylib, and error codeCORDBG_E_DEBUG_COMPONENT_MISSING is returned.
Now we get modules information by iterating over regions using proc_pidinfo()
in CreateProcessModules().
Fixes #42888