[release/5.0] Get modules information using proc_pidinfo() on macOS #44748
Conversation
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
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 #42888
|
Tagging subscribers to this area: @eiriktsarpalis, @jeffhandley Issue Details
|
mikem8361
requested review from
mikem8361 and
janvorli
and removed request for
mikem8361
|
Thanks a lot @mikem8361 @k15tfu @jeffschwMSFT! I was wondering if this will make the way into .NET Core 3.1 as well. Thanks again |
|
I'm working on 3.1 backport this week. |
|
/cc: @hoyosjs |
|
@k15tfu, @stevo-knievo, @jeffschwMSFT, @hoyosjs, @gregg-miskelly As it turns out, this does not need to be backported to 3.1 or 2.1 because it only affects/fixes "dbgshim" (libdbgshim.dylib on MacOS) which is picked up by Visual Studio/VSCode and shipped with it. |
|
Thanks for the update @mikem8361. I much appreciate it. I experiencing the issue with Jetbrains Rider together with Azure Function projects. I can't debug Azure Function projects (.NET Core 3.1). I'm getting the following error:
Here the issue I opened on the JetBrains side. If I understand you correctly I need to point the JetBrains guys to your previous comment because they need it to fix it on their side. Is that correct? Thanks for your help. Stefan |
|
@mikem8361 Yes. But for native apps trying to create ICorDebug, there is no Now this is not required, and you can simply use the one you found. |
leecow
added
Servicing-approved
|
We strongly recommend that managed debuggers include and shipped dbgshim with their product. It was always our intent that dbgshim ship with debuggers even though it probably wasn't clear. Shipping the dbgshim binaries from the next 5.0.x service release (which will include this PR) will allow the debuggers to work with all the previous runtime versions (5.0.0, 3.1.x and 2.1.x). Some of the reasons are:
|
|
So what is the best way to fix this for something like debugging in Jetbrains rider? just drop in the new libdbgshim.dylib? |
|
@mikem8361 Okay, I got your points. Thank you for the clarification. |
ghost
locked as resolved and limited conversation to collaborators
Backport of #42900 to release/5.0
/cc @mikem8361 @k15tfu
Customer Impact
If affects customers that have newer MacOS versions that have XCode 12 installed and “selected” (meaning it is used to build/natively debug code). This PR fixes the issue by removing the dependency on the XCode tool vmmap command.
Testing
It has been in master for a month or so. Testing by @k15tfu (who submitted the PR) and I assume @stevo-knievo who also asked for 5.0/3.1 back porting
Risk
It is fairly low risk and contained to just managed debugging on MacOS.